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

On 10/17/2014 06:39 AM, Simon Budig wrote:

Elle Stone (ellestone@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

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.

Kind regards, Elle Stone

On 10/17/2014 07:00 AM, Simon Budig wrote:

Elle Stone (ellestone@ninedegreesbelow.com) wrote:

On 10/17/2014 06:39 AM, Simon Budig wrote:

Elle Stone (ellestone@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.

In point of fact, I never used "spectrally based reproduction" as an argument against "sRGB as PCS". But if you do want "same slider moves" to produce "same results", I think spectral data might the thing to look at.

*GIMP* is an *RGB* image editor.

We have been discussing the advisability of babl/GEGL/GIMP using unbounded sRGB for editing RGB images that were originally in another RGB color space of the artist's choosing.

RGB working space data is determined by the profile chromaticities. Change the chromaticities and the channel data itself changes.

sRGB is a singularly ill-advised choice for working with RGB data from interpolated camera raw files.

Kind regards, Elle Stone

On 10/17/2014 07:08 AM, Øyvind Kolås wrote:

On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone 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

On 10/17/2014 08:32 AM, Øyvind Kolås wrote:

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

That project isn't using unbounded sRGB. I will guess that as a web application, all image editing is limited to sRGB images. Web browser color management is iffy, at best. So sRGB is still the safest choice for the web.

FYI, I'm not interested in continuing this discussion with Pippin.

Twice it seemed that unbounded sRGB would be abandoned and that "sRGB-only" would be reserved for only those very few and easily identified RGB editing operations that really only could work in the sRGB color space.

In my opinion, babl/GEGL/GIMP together make a great combination. The only thing I'm objecting to is Pippin's desire to shoehorn into the mix unbounded sRGB for RGB image editing.

Right now I use three side-by-side babl/GEGL/GIMP installations for image editing, one each for the three different RGB working spaces that I use regularly (guess what, one of them is for sRGB).

For each installation I changed the hard-coded Y values to match the Y values of the intended RGB working space (the GIMP hard-coded sRGB Y values are not correct, being D65 unadapted values). And I disabled the babl TRC flips.

I don't ever use the XYZ-to-LAB conversion. Nor do I use the YCbCr/YIQ/color-temperature and so forth code. So all I needed to change to get accurate RGB editing operations was the hard-coded Y values.

I have already posted a bug report and a write-up on how to fix GIMP color management, containing a (hopefully) complete list of all hard-coded sRGB and NTSC parameters: http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html https://bugzilla.gnome.org/show_bug.cgi?id=737778

I have tried to explain the problems shoehorning unbounded sRGB into the babl/GEGL/GIMP code base will cause.

But unless some of the developers want to start a branch that won't use unbounded sRGB, I think it's time to stop the conversation.

Unfortunately I don't know how to ferry UserRGB Y values to the places in the babl/GEGL/GIMP code that currently use hard-coded sRGB Y values. Otherwise I would submit a patch. But I did submit code for retrieving UserRGB Y and XYZ values.

Kind regards, Elle Stone