Re: [Gimp-developer] [Gegl-developer] babl roadmap
On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries In other words, you will make a list of all operations that don't work in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. As a maxim for guiding GIMP development, consistent results for the same property values / slider positions reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code. With respect, 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] babl roadmap
On 10/14/2014 08:50 AM, Simon Budig wrote: for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB. There is one fundamental difference between XYZ as the real PCS and sRGB as PCS (those are scare quotes; the terminology sRGB as PCS is misleading at best): Worked out step by step: It takes one matrix multiplication to get from UserRGB to XYZ. The required matrix A is contained in the UsrRGB ICC profile colorants. It takes a second matrix multiplication to get from XYZ to sRGB. The required matrix C is the inverse of the matrix contained in the sRGB ICC profile colorants. A and C are both defined in terms of XYZ. Once you have matrix A for getting from UserRGB to XYZ and matrix C for getting from XYZ to sRGB, you can concantenate the two multiplications into one matrix multiplication. This is because matrix multiplication is associative: C*(A*B) = (C*A)*B, where B is the UserRGB RGB values that will be converted to sRGB (linearized RGB data is assumed). One matrix multiplication or two, you still get to the same place. But the required one matrix to multiply first has to be *calculated* using *two* matrices, both of which are defined in terms of the real PCS, which is XYZ. Then you have to store the result of C*A in memory for future use. Pippin wants to go through sRGB as PCS to get to XYZ. In a sane color-managed editing application, it takes one matrix multiplication to get from UserRGB to XYZ, using matrix A. In Pippin's sRGB as PCS, first you convert from UserRGB to sRGB using the matrix that's the product of C*A, that you've previously stored somewhere in memory. Then you convert from sRGB to XYZ using the inverse of C. Two conversions. Which of course can in turn be concantenated into one multiplication and also stored in memory for future use. Kind regards, 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] babl roadmap
On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries In other words, you will make a list of all operations that don't work in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. As a maxim for guiding GIMP development, consistent results for the same property values / slider positions reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code. No I am explaining how we will start out making these changes for engineering reasons. How to follow a process that doesn't destabilize and destroy what we already have. While your back-seat driving, asking about detailed choices of side-roads 4 weeks from now on our road-trip is not very productive when we're not even sure we'll be in the country of those roads you want us to take – or if we will have swapped the hummer for a jeep. ___ 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] babl roadmap
In the current babl/GEGL/GIMP code base, I counted five files that contain functions that require a conversion from RGB to XYZ: 1. gimp/plug-ins/common/decompose.c 2. gimp/plug-ins/common/compose.c 3. gimp/app/core/gimpimage-convert-type.c 4. gegl/operations/common/image-compare.c 5. gegl/operations/common/noise-cie-lch.c These five files use the babl file: babl/extensions/CIE.c The babl/extensions/CIE.c code calculates the sRGB to XYZ matrix M, starting from the D65 unadapted sRGB color space red, green, blue, and white xy values. Calculating M from xy values is a fairly complicated process. Study the equations on http://brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html and make sure to read note 2, which says Be careful that reference whites are used consistently. For example, sRGB is defined relative to a D65 reference white and ICC profiles are defined relative to a D50 reference white. Mismatched reference whites must be accounted for elsewhere, typically by using a chromatic adaptation algorithm. In an ICC profile D50-adapted color-managed workflow, you don't use the unadapted D65 sRGB M (that the babl code calculates) to get from sRGB to XYZ. In an ICC profile color-managed workflow, you don't need to calculate the D50-adapted M for a matrix RGB working space, because you can read M directly from the ICC profile colorants. There are two ways to fix the conversion to XYZ code in babl/extensions/CIE.c: 1. babl/extensions/CIE.c can be rewritten to use D50-adapted M retrieved directly from the UserRGB ICC profile colorants. Then convert to XYZ. 2. Or else you can use sRGB as PCS, which allows you to rewrite the code in babl/extensions/CIE.c to use hard-coded D50-adapted sRGB M. In this case: i. Upon opening an image, first retrieve M from UserRGB (call this matrix A). ii. Then retrieve M from sRGB and calculate the inverse (call this matrix C). iii. Then calculate C*A and store this information in memory as D. iv. Then convert from UserRGB to unbounded sRGB using the matrix D. v. Then convert from unbounded sRGB to XYZ using the hard-coded D50-adapted sRGB M. In an ICC profile color-managed workflow, sRGB is just another ICC working space profile. It doesn't need special treatment. The right way to fix the babl conversion to XYZ is to rewrite babl/extensions/CIE.c to use M taken from the UserRGB ICC profile colorants. And forget about sRGB as PCS. There may be a problem somewhere in the GIMP code for which sRGB as PCS might be a solution. Converting to XYZ is not one of those problems. Kind regards, 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] babl roadmap
Unfortunately for hard-coded sRGB as PCS, the ICC profile specifications are a moving target. Right now the ICC profile illuminant is always D50. But in the next planned release of new specifications, things will change: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. iccMAX is a radically different approach which builds on ICC v4 but enables a far more flexible means of connecting devices, data, materials, observers and illuminants. //end quote I would ask every babl/GEGL/GIMP developer who cares about GIMP as a high end ICC profile color-managed image editor to read the rest of the page that I just linked to, and maybe think long and hard about whether you really want to limit yourself to babl color management based on hard-coded D50-adapted sRGB as PCS. D65 unadapted sRGB is based on CRT technology that is no longer in widespread use. Rec.2020 is the up and coming new display device standard. D50-adapted ICC profiles are based on profile specifications that revolve around increasing outdated print-based technologies. Print-making technologies have changed, and today the output device is just as (or more) likely to be a display screen. The ICC is moving forward (and let's hope they also fix a few issues that V4 introduced). Tying GIMP to sRGB as PCS is a dead-end move. Kind regards, 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] babl roadmap
Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] babl roadmap
On 10/17/2014 06:39 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. Kind 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] babl roadmap
On Fri, Oct 17, 2014 at 12:47 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø ___ 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] babl roadmap
Elle Stone (ellest...@ninedegreesbelow.com) wrote: On 10/17/2014 06:39 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. I know. Which is why your previous mail could have had the very same text and the following sentence as the conclusion: Tying GIMP to RGB based editing is a dead-end move. Which is exactly the dead end you have been advocating a lot in the recent discussion. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] babl roadmap
On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? ___ 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] babl roadmap
On 10/17/2014 07:08 AM, Øyvind Kolås wrote: On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? I did not ask people to study spectral color management. I did ask people to realize that the ICC profile specs are changing. In particular, D50 will no longer be the only profile illuminant. The point of this endless discussion is that unbounded sRGB is a singularly bad way to forcibly recast the user's RGB data for RGB image editing. The code for converting to unbounded sRGB isn't yet in place. At present, to get right results from babl/GEGL/GIMP, it would suffice to replace hard-coded sRGB Y and XYZ with UserRGB's Y and XYZ, and correct the babl code that converts to XYZ. And of course it should be easy for the artist to switch at will between perceptually uniform and linear RGB. For the very few RGB editing operations that really must be done using the sRGB primaries, write special code as appropriate and label the operations in the UI as sRGB only so the user knows what's happening. The babl roadmap lays out a plan to complicate the existing code, apparently only to turn around and straighten it out again. With respect, 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] babl roadmap
On Fri, Oct 17, 2014 at 1:39 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 07:08 AM, Øyvind Kolås wrote: On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? The point of this endless discussion is that unbounded sRGB is a singularly bad way to forcibly recast the user's RGB data for RGB image editing. The code for converting to unbounded sRGB isn't yet in place. The babl roadmap lays out a plan to complicate the existing code, apparently only to turn around and straighten it out again. What you see as complicating the existing code is normal when one does something known as refactoring, the roadmap documents the road towards the goal – and isn't even a complete roadmap since we don't know all we will know when we are further along on it. http://en.wikipedia.org/wiki/Code_refactoring GIMP is not the only project using GEGL; nor is it the only user interface on top of GEGL. GEGL pipelines need to be able to deal with arbitrary counts of RGB spaces; which also GIMP need for having multiple project use open and doing cross project copy-paste, clone etc. One of the other GEGL UIs is this http://libregraphicsworld.org/blog/entry/artificial-intelligence-designs-websites-uses-open-technology-stack /Ø ___ 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] babl roadmap: How do you know which images are sRGB images?
On 10/14/2014 07:16 AM, Øyvind Kolås wrote: On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/13/2014 06:36 PM, Elle Stone wrote: So again, upon opening an image, how do you plan to detect whether the image is an sRGB image or not? Will you compare MD5 checksums? Will you consult the profile descriptions? Will you examine the profile colorants and TRCs? Most likely examination of profile colorants/TRCs since that is what ICC or other color profile meta-data aware image loaders needs to provide down to babl anyways. You did pick the only plausible answer: check the colorants and TRCs. In many circumstances it is desirable to to treat almost sRGB as sRGB and consider deviance from the real standard a mistake in labeling; for instance if it is a low bitdepth image containing dithering - at other times assuming that the slight off profile has been applied as is earlier in the production pipeline might be desirable. For most users, for most purposes, you as developer can probably decide for the user that slight off means close enough. The trouble is you don't know whether slight off is a mistake or intentional. The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants. The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved. And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK. 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] babl roadmap: How do you know which images are sRGB images?
Elle, It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. - Theodore Roosevelt Time for you to stop making vaguely patronising remarks and make an actionable suggestion, or leave this. Hugs and positivity, Ed -Original Message- From: Elle Stone Sent: Friday, October 17, 2014 4:43 PM Cc: gegl-developer-list ; Gimp-developer Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know which images are sRGB images? On 10/14/2014 07:16 AM, Øyvind Kolås wrote: On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/13/2014 06:36 PM, Elle Stone wrote: So again, upon opening an image, how do you plan to detect whether the image is an sRGB image or not? Will you compare MD5 checksums? Will you consult the profile descriptions? Will you examine the profile colorants and TRCs? Most likely examination of profile colorants/TRCs since that is what ICC or other color profile meta-data aware image loaders needs to provide down to babl anyways. You did pick the only plausible answer: check the colorants and TRCs. In many circumstances it is desirable to to treat almost sRGB as sRGB and consider deviance from the real standard a mistake in labeling; for instance if it is a low bitdepth image containing dithering - at other times assuming that the slight off profile has been applied as is earlier in the production pipeline might be desirable. For most users, for most purposes, you as developer can probably decide for the user that slight off means close enough. The trouble is you don't know whether slight off is a mistake or intentional. The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants. The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved. And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK. 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 ___ 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
