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

[Jon Nordby <jononor gmail com>]

On 30 August 2012 01:01, Elle Stone <l elle stone gmail com> wrote:
> 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?

Cairo, the library used for rendering to the screen in GTK and GIMP
expects its input as sRGB*. See app/display/gimpdisplayshell.c for
example of how we use this library. The Babl format "cairo-ARGB32" is
short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected,
pre-multiplied alpha. The LCMS plugin is used before this step to do
the conversion with the actual monitor profile.

* It is unclear to me how strict this expectation is as this is not
documented anywhere in Cairo. Perhaps someone here can shed some more
light?

> 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?

An RGB30 (10 bits per channel) image format was added in Cairo 1.12
earlier this year. I don't know if any if the display backends used on
Linux, Mac OSX or Windows handles this format yet. It could be the
output it still clamped or converted to 8 bit per channel even on wide
gamut displays. I highly suspect that would be the case on X11.

-- 
Jon Nordby - www.jonnor.com