Regarding legacy code/deprecated functions: On 8/29/12, Jon Nordby <jononor@xxxxxxxxx> wrote: > Also, any legacy code paths that are still in place before the > GEGLification might cause conversions to sRGB. I don't know exactly > which parts those are in the current codebase, but anything that uses > the deprecated pixel manipulation functions are likely candidates. I > note that the lcms plugin still uses these interfaces, and I suspect > that is what is causing the implicit (and unwanted) conversions you > are seeing. On 8/29/12, Simon Budig <simon@xxxxxxxx> wrote: > Basically all of the plugins (including your lcms port) use the old > pixel-region API for accessing the image data. This also means that they > don't specify a proper working format, this even could be the reason for > all kind of potentially useless conversions. Earlier to day I found Mitch's blog post: http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/ - which coheres nicely with what both of you are saying about the "old" vs "new" way of accessing pixel data. So it looks like my next step is to replaced the deprecated functions in the lcms plug-in. So I will start doing exactly that. It was the next step anyway, but I was feeling very discouraged about the whole babl/babl/util.h thing. Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby <jononor@xxxxxxxxx> wrote: > On 29 August 2012 19:03, Elle Stone <l.elle.stone@xxxxxxxxx> wrote: >> Why does the /babl/babl/util.h code get executed from fast-float.c, >> float.c, model-rgb.c, model-gray.c, and several other files, resulting >> in endlessly performed conversions between linear and regular sRGB TRC >> in the background of all image processing? >> > > Rendering to to screen / the windowing system is done using sRGB. So > anything that causes canvas updates when the image itself is not in > sRGB will trigger such conversions. Could you explain more about what you mean by "rendering to the screen is done using sRGB"? What about the actual monitor profile? Back in the day, a decent CRT monitor could easily be calibrated to match the sRGB color space, because sRGB was based on the display characteristics (tone curve, primaries, "dial-a-white-point" and 0 black point) of the CRT monitor. (See "All the Colors, Some of the Colors, the Colors of Daylight": http://ninedegreesbelow.com/photography/all-the-colors.html). Today's LCD monitors are not well-characterized by sRGB. It is not just a matter of the LCD monitor native white point not being D65. The phosphors are different, which means the primaries are different, which means the color gamut is different. And unlike a CRT, with an LCD you can't get (0,0,0) displayed to the screen (the sRGB black point assume "zero light" can be sent to the screen). Which means you cannot really calibrate your monitor to use the sRGB TRC. (See "sRGB — Not So Good for LCD Monitors": http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html and "Image Display Technology": http://www.marcelpatek.com/LCD.html.) A wide gamut monitor profiled in its native state would be an even worse fit to sRGB, though compared to a regular LCD, a wide gamut LCD monitor can achieve a much closer calibration to sRGB, IF one chooses to give up the extra color gamut. But why would you want to give up all that extra color gamut goodness? My own LCD "native state" monitor profile covers 93% of the sRGB color space, but the sRGB color space covers only 84% of my monitor profile color gamut. If I calibrated my monitor to match sRGB as closely as possible, I would end up with a monitor profile color gamut that is actually smaller than sRGB, at the additional price of less smooth tonal transitions - a very bad move, it seems to me. So to repeat my question, how does "rendering to the screen . . . using sRGB" cohere with using an LCD monitor that is not well-described by the sRGB color space profile? Kindest regards, Elle -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
