Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?

[Elle Stone <l elle stone gmail com>]

Regarding legacy code/deprecated functions:
On 8/29/12, Jon Nordby <jononor gmail com> 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 budig de> 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 gmail com> wrote:
> On 29 August 2012 19:03, Elle Stone <l elle stone gmail com> 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