On 8 November 2012 21:29, Elle Stone wrote:

I was hoping that by removing all the deprecated functions the problem with high bit depth color conversion being subverted by the background TRC conversions would be resolved, but it wasn't. I am unsure how to procede, although I have pinpointed exactly where in the Gimp code the Babl functions are called (it's not in the lcms plugin code) and which particular Babl functions are being called.

Has your work on replacing the deprecated functions found its way into git master?

In the existing "image color space to monitor color space" code, the image RGB values are converted to 8 bits *before* the RGB values are sent to the code that converts from the image color space to the monitor profile. Which means the monitor display of linear gamma color space images has severely posterized deep shadow detail (the image itself isn't damaged, just the monitor display of the image).

I've been tracing the "image color space to monitor color space" code execution path, looking for a place to intervene to give the color-space-to-monitor-space lcms profile conversion 16-bit integer or 32-bit floating point values instead of 8-bit values. It turns out that the relevant "image color space to monitor display space" code is spread out over quite a few gimp, babl, and gegl c-code files, and makes heavy use of Cairo-related functions.

I looked into this code a bit earlier. Here is one way of approaching it: * Change the lcms-based conversion (modules/display-filter-lcms.c) from being a generic display filter to be something that takes a GeglBuffer in and blits into a cairo_surface_t. * Change the display filter interface to accept a GeglBuffer instead of a cairo_surface_t. As gimp_color_display_convert_surface is public API, it should probably become a stub and be marked as deprecated. New interface could for instance be called "gimp_color_display_convert_buffer"
* Adapt all the display filter operations (modules/display-filter-*.c) to the new interface and to working on 32bit floating point. If any of the operations are no longer useful, now would be the time to drop them.
* In the use of the display filter stack (in gimp_display_shell_render), first let the filter stack operate on the GeglBuffer from the projection (or possibly a copy), and then pass it to the lcms-based color conversion, and then pass that to cairo.

In the longer term, one can consider making the display filters GEGL operations and the display filter stack a GEGL subgraph.

Hello Elle!

On Thu, Nov 8, 2012 at 9:29 PM, Elle Stone wrote:

I apologize for the long delay in posting an update. Alas, the only enlightenment I have found during that long delay is that to make further progress I will need help from someone well-versed in Gimp/Babl/Gegl/Cairo code.

I think that is an good idea and I can see four ways to get this happen:

1. Linux Color Management Hackfest 2012 in Brno, Czech Republic http://www.freedesktop.org/wiki/OpenIcc/Events/Hackfest/2012 There you could meet Øyvind Kolås (Pippin)

2. Libre Graphics Meeting 2013 in Madrid, Spain http://libregraphicsmeeting.org/2012/2012/06/lgm-2013-dates-and-venue/ This is the best place to meed more then one Gimp Developer.

3. Fly to a developer. Afaik most Developers are in Europe.

4. Invite an Developer to your place.

My last information is, that the Gimp project has money to sponsor the flights so don't hesitate to ask.

Kindest regards, Tobias

On Thu, 2012-11-08 at 15:29 -0500, Elle Stone wrote: [...]

In the existing "image color space to monitor color space" code, the image RGB values are converted to 8 bits *before* the RGB values are sent to the code that converts from the image color space to the monitor profile.

And here I am with 11 significant bits in colour specifications according to the video card, and 10-bit colour on the monitor, and 32-bit (10+10+10+2 alpha) visuals in X11...

On Fri, Nov 9, 2012 at 5:13 PM, Liam R E Quin wrote:

On Thu, 2012-11-08 at 15:29 -0500, Elle Stone wrote: [...]

In the existing "image color space to monitor color space" code, the image RGB values are converted to 8 bits *before* the RGB values are sent to the code that converts from the image color space to the monitor profile.

And here I am with 11 significant bits in colour specifications according to the video card, and 10-bit colour on the monitor, and 32-bit (10+10+10+2 alpha) visuals in X11...

There have been no claims that the current code does something reasonable yet; at the moment I am at the color management hackfest in Brno, among other things arguing for GIMP and other high fidelity applications needs to not go through yet another 8bit -> 8bit LUT with additional quantization problems. :)

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
@hodefoting
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sat, 2012-11-10 at 15:17 -0500, Elle Stone wrote:

On 11/8/12, Jon Nordby wrote:

Has your work on replacing the deprecated functions found its way into git master?

No. With Mitch's help I did made a patch file (which might be out of date by now, as Gimp keeps changing): http://ninedegreesbelow.com/temp/gimp-lcms-deprecated.html#patch

Indeed :) I cleaned up that patch to match GIMP's coding style, fixed some little things, and attached it to:

https://bugzilla.gnome.org/show_bug.cgi?id=662739

Let's continue the patching and patch discussion in this bug. I also added a comment on the patch there.

* Change the lcms-based conversion (modules/display-filter-lcms.c) from being a generic display filter to be something that takes a GeglBuffer in and blits into a cairo_surface_t. * Change the display filter interface to accept a GeglBuffer instead of a cairo_surface_t. As gimp_color_display_convert_surface is public API, it should probably become a stub and be marked as deprecated. New interface could for instance be called "gimp_color_display_convert_buffer"
* Adapt all the display filter operations (modules/display-filter-*.c) to the new interface and to working on 32bit floating point. If any of the operations are no longer useful, now would be the time to drop them.
* In the use of the display filter stack (in gimp_display_shell_render), first let the filter stack operate on the GeglBuffer from the projection (or possibly a copy), and then pass it to the lcms-based color conversion, and then pass that to cairo. --
Jon Nordby - www.jonnor.com

I'm looking forward to taking another look at the monitor display code path. Your suggestions sound very helpful.

It does, but it's clearly step 2 (or step n). IMO we should first get the lcms plug-in right so the data GIMP is dealing with is correct in the first place.

When I started looking at Gimp color management I had no idea how very complicated Gimp code is. The light began to dawn as I tracked down the functions that are involved in sending image data to the monitor. Then I traced the function calls from the time Gimp is started until main.c hands control over to Glib (g_main_loop_run). Glib?

I have a sense of how Gimp and Gegl, and Gimp and Babl, interact. Would some kind soul be willing to provide a quick overview of the relationship between Gimp and Glib? And between Gimp and Cairo? I realize that Cairo sends the image data to the screen, but what is the advantage of using Cairo?

GLib and GTK+ were originally developed inside GIMP and then split out to be independent packages ages ago. GTK+ is the user interface toolkit, GLib is a whole framework of cross-platform utility functions, featuring stuff like lists, hash tables, the main loop and tons more.

Cairo is how GTK+ and GIMP render everything for GUI display, its advantage is that before we used wrappers around stone age X11 API which is complete and utter legacy. Cairo is vector based and proper.

For more detailled explanations, google and #gimp IRC are your friends, I haven't seen you on IRC in a long time anyway :)

Regards, --mitch