[Gimp-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 10/12/2014 06:46 AM, Øyvind Kolås wrote: 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. Exactly. People with wide gamut monitors would be pretty upset if their images were squeezed through sRGB before being sent to the screen. Converting to sRGB before converting to the monitor's profile would limit what is seen on the screen to the *overlap* between the sRGB color gamut and the LCD monitor profile's color gamut. Many LCDs, even many widegamut LCDs, can't display all of sRGB. See "Can the entire sRGB color gamut be displayed on today's LCD monitors?" http://ninedegreesbelow.com/photography/srgb-bad-working-space-profile.html Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On Sun, Oct 12, 2014 at 3:01 PM, Simone Karin Lehmann wrote: >> 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? This depends on how good GIMPs integration with the desktop CM is/will be, whether it is possible to opt the canvas and some other bits of the UI out of the sRGB assumption of the CM and pass uncorrected data through to the front buffer of the GPU for display. The reason for wanting to opt out only sub-rectangles rather than full windows, is to ensure that colors of buttons and other ui bits is the same in all applications. Without doing this one easily introduces color casts and more. For instance Gnome Color Manager does; or at least used to, do this global correction of the front buffer towards being sRGB by altering the vCGT - gamma lookup tables in the GPU itself - with a little bit higher precision than 8bit. When fullscreen color management is done like that, for all pixels of the display - we do not even have a chance to opt out. When it is done with shaders and the possibility of masks for opting regions out, which are features that kwin/compiz have implementations of, the situation is different. GIMP needs to be able to adapt to various of these circumstances. Including the situation where nothing else on the system is doing color managment and the values GIMP provide for output gets passed through without anything else tweaking them. /Øyvind ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 : On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone 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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
> Am 12.10.2014 um 12:46 schrieb Øyvind Kolås : > > On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone > 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? Simone ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone 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). ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
