On 30 August 2012 01:01, Elle Stone <l.elle.stone@xxxxxxxxx> wrote: > 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? 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 _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
