Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/11/2014 08:52 PM, Jon Nordby wrote: Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. Is the above correct? Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. The same applies for most UI toolkits/APIs integrating with color management; the implementation that is unmanaged (or all!) content is to be presented in the framebuffer as sRGB and the desktop color management to compensate towards the monitor profile. Applications like GIMP, image viewers and similar - should be requesting that rectangular parts of the UI (image viewing areas and similar) be excepted from these conversions. Ideally we would be dealing differently with, no desktop CM and no display profile, no desktop CM (but have a display profile), desktop CMM without ability to opt out regions, and desktop CM with the ability to opt out regions. sRGB goes even deeper in cairo, where all API entry points where individual colors are specified for stroking/filling/gradients is specified as floating point sRGB (with the TRC as well). Buffers we get from cairo for doing things like text rendering are 8bit sRGBA with sRGB TRC and pre-multiplied alpha. An annoyance for GEGL is that cairo is limited to 8bpc in its rasterization of vectors (by using a clever implementation choice; which makes things fast - but tricky to adapt for 8bit.). Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB. Mostly everyone else tries to assume sRGB for consistency - when color management is considered hard; babl aims to make it easy and fast for GEGL to continue integrating with such code. /pippin (btw, babl/docs/roadmap.txt has been slightly updated). ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/12/2014 09:01 AM, Simone Karin Lehmann wrote: Am 12.10.2014 um 12:46 schrieb Øyvind Kolås pip...@gimp.org: On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB. so that means, that specifying a monitor profile in GIMP’s preferences other than sRGB will result in displaying wrong colors. Or am I wrong? I didn’t know that. On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable the choice of a monitor profile in GIMP at all, as long as cairo assumes SRGB? In reality, it is not the case that images in GIMP must be converted to sRGB before they can be displayed on the screen. There is no such conversion in the entire babl/GEGL/GIMP code base. If there were, there would be precious little reason for letting the user set a monitor profile. I wasn't agreeing with what Jon Norby said. I was asking if I understood him correctly. Sorry for causing confusion! Best regards, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] babl roadmap
The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight. But if the devs are determined to pursue this course to the bitter end, here are some suggestions regarding white_reference: //begin quote . . . permitting at least linear formats with other chromaticities is highly desirable, this will be fixed by allowing to specify named RGB spaces, possibly like this: void babl_define_named_rgb_space ( Babl *babl, const char *name, double red_xyz[3], double blue_xyz[3], double green_xyz[3], int white_reference, /* could be _XYZ[3] instead of d50/d65/d60; but this is likely sufficient */ double trc_gamma /* makes sense to have it even if not initially used */ );//end quote Short version: You might want to specify white_reference using XYZ[3] instead of using int. You probably want *two* variables: 1. the color space specifications reference white. 2. the ICC profile illuminant. The variable names might be white_reference and profile_illuminant. The D50 profile illuminant tag that's in LCSM and ArgyllCMS profiles has these XYZ values: (0.96420288, 1., 0.82490540). The XYZ values for the D65 sRGB color space specification reference white are (0.950455927, 1.0, 1.089057751). These values are converted from xyY as given in the sRGB color space spec. Long version: 1. Different profile specifications, standards bodies, etc. specify slightly different XYZ/xyY values for D50, D65, etc. And sometimes CMMs and profile makers make up their own D65 values for no apparent reason (http://ninedegreesbelow.com/photography/linux-icc-profiles.html#variants - scroll down to the table labelled Selected D50 and D65 profile white point xyY values). 2. The ICC spec D50 illuminant values are (0.9642, 1.0, 0.8249). These aren't rounded to four places values. These are the actual values given in the ICC spec. 3. ICC profile illuminant XYZ values as found in actual profiles are hexadecimal-rounded. When converted back to decimal, the actual D50 illuminant XYZ values from an LCMS or ArgyllCMS profile are: (0.96420288, 1., 0.82490540). 4. The next release of the ICC specifications likely will allow illuminants other than D50. So assuming LCMS also will support this new functionality, at some point the function babl_define_named_rgb_space will need to directly retrieve the profile illuminant XYZ values. 5. In an ICC profile, the original color space XYZ values have been adapted *from* the color space reference white *to* the ICC profile illuminant. See http://ninedegreesbelow.com/photography/srgb-color-space-to-profile.html 6. In an ICC profile color-managed image editor, you use relative colorimetric conversions between RGB working spaces, so the original color space reference white (for example, D65 for sRGB) is completely irrelevant. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
