On Thu, Apr 17, 2014 at 1:08 PM, Elle Stone wrote:

The other day there was an IRC discussion of the possibility of GIMP supporting RGB color spaces other than unbounded mode sRGB.

I was surprised to see in the transcript a statement that GIMP shouldn't support Adobe RGB (1998).

It makes no sense to import opening files with any particular ICC profile, by definition unbounded gamut RGB spaces support storing and manipulating all colors of photo's/imagery of any bounded gamut RGB spaces. What actual color space/pixel format is being used for manipulation is a separate concern from how color data is passed around and actually stored. There are definetely many things to sort out and many things in GIMP that have are straight ports of the old 8bit/component code; keeping track of the _meta_data_ of an original color space/gamut/pixel format raster data originated in - and the ability to to chosen/select operations in that space is something that fits the strongly color managed architecture of GEGL. While doing global overrides of some of the internal pixel formats that are absolutely colorimetrically defined would make it easy to misconfigure the color settings yielding surprising and inconsistent behavior.

Adobe RGB (1998) is important for:

* People preparing images for printing

The default GEGL/babl pixel formats in floating point are unbounded; and personally I think the 16bit formats should be made 4.12 instead 0.16 fixed point to provide adequate headroom/footroom - though with a predominantely floating point based processing doing this might not be a huge win.

* People who save Adobe RGB (1998) camera jpegs

Exporting to any particular bounded RGB gamut; as well as proofing whether colors are within a gamut should in no way be hampered.

* People who want or need a small gamut color space that is nonetheless larger than the very small sRGB.

The usefulness of the extended range in cyan/green; and how many perceptually discernable colors you gain compared to sRGB is questionable.

A summary rejection of Adobe RGB (1998) ignores the needs and accustomed workflows of the many, many photographers who work in the Adobe RGB (1998) color space.

Not having saddle adapters as mandatory attachment mechanisms for car seats ignores the needs and accustomed workflows of horse riders used to maintain and customize their leather saddles.

/pippin

Opinion:

Using, internally, a reference unbounded color space (or two: one linear, one perceptual, with, possibly low precision shadows for speed), and converting in and out of it when an image is imported or exported is a sane choice.

Deviations from the "standard internal color space(s)" should be motivated by the operation being performed, not by the color spaces of the initial and final results (which may or may not belong to the same ones in any case).

There are, no doubt, situations in which alternate internal color spaces could give better results. But catering to these corner cases is likely to cause endless headaches for developers and bring no benefit whatsoever to 99.999% of users.

El jue, 17-04-2014 a las 16:02 +0200, Øyvind Kolås escribió:

On Thu, Apr 17, 2014 at 1:08 PM, Elle Stone wrote:

The other day there was an IRC discussion of the possibility of GIMP supporting RGB color spaces other than unbounded mode sRGB.

I was surprised to see in the transcript a statement that GIMP shouldn't support Adobe RGB (1998).

It makes no sense to import opening files with any particular ICC profile, by definition unbounded gamut RGB spaces support storing and manipulating all colors of photo's/imagery of any bounded gamut RGB spaces.

It makes sense for lots of people's usual workflow. It's what people do now with GIMP and other similar tools. Now, I don't have anything against improved and simplified workflows if they are transparent to users.
The unbounded gamut thing sounds great if it can be implemented without breaking the way users work with their files. And that's my concern (I think Elle's too). For instance, in Elle's example -the yellow flower with hidden detail in the blue channel- there's a valid and common use of extra gamut. Pulling information of channels for creative or technical purposes shouldn't be ruled out.
It's what artists do, not only for creative black and white, but for pulling mattes for compositing, among other uses. And that's just one example.

Our concern (here I'll speak for Elle too, I think she meant the same in her observations) is that way too many things have to be accomodated to work with the unbounded gamut model, both in the application and the users workflow. And in some cases it is uncertain that they will work (I cited the multiply/divide operations giving unusable results)

But if you can guarantee that it's not going to impact on users freedom and expectations, I'll just STFU :-)

What actual color space/pixel format is being used for manipulation is a separate concern from how color data is passed around and actually stored. There are definetely many things to sort out and many things in GIMP that have are straight ports of the old 8bit/component code; keeping track of the _meta_data_ of an original color space/gamut/pixel format raster data originated in - and the ability to to chosen/select operations in that space is something that fits the strongly color managed architecture of GEGL.

I think I understand the idea, and it seems solid... for sRGB, or for images that don't have to go through heavy editing and compositing.

Elle and I have made some tests where the results of working in unbounded sRGB are really different than doing the same in the original colorspace (read colorspace here as primaries only, I'm leaving all the trc conversions out for the sake of simplicity and going straight to the point).
That seems to indicate that several operations have to be modified in order to accomodate with working with unbounded values. And they are operations that would work without modifications in a bounded colorspace, even for HDR images.

In our conversation over IRC you stated that the same out-of-bounds values you have in unbounded sRGB are also a problem in HDR files, but that doesn't seem to be entirely correct. It's true that HDR images can end up with negative and >1, but in those images values above 1 NEVER mean out of gamut colors. It means the saturated primary with more intensity, not for instance "redder than red"
And those >1 values don't seem to be a problem for compositing or editing.
Negative values, on the other hand, are always a problem. But in a scene-referred linear light model, light intensity is supposed to go between 0 and infinity, so it's quite safe to clip something that means "negative light intensity" because it's nonsense. (there are special cases, like the results of convolutions where negative values are still a problem, but they have to be addressed in a different way, as you said).

In the unbounded model, the unbounded values mean out of gamut values, and I think (and the tests I did seem to confirm it) that many operations that are designed to mimic how light works in reality will struggle with those values, because they're not anymore counterparts of light (i.e.: the RGB channels are no longer equivalent to 3 colored lamps with variable intensity)

The math of compositing and color operations seems to have been created around that idea, and using a different paradigm for the contents of thr RGB channels probably requires to rethink an important part of those operations.

The concern and the question is if it's worth it. It seems a titanic effort for something that doesn't necessarily mean a huge benefit.

Anyway, it's my personal perception. Maybe I'm getting all this wrong and my concerns are unfounded. I'm totally open to be proven wrong, it's a good way to learn new things :-)

While doing
global overrides of some of the internal pixel formats that are absolutely colorimetrically defined would make it easy to misconfigure the color settings yielding surprising and inconsistent behavior.

That's true and I've witnessed that hundreds of times during my carreer as a designer. Most of the graphic designers I know (who use Adobe) don't know what to do with the color settings dialog and leave them untouched, or in the worst cases touch it without knowing what they're doing.
But you can't just assume that all users won't know what to do with color profiles.
As I mentioned before in the recent softproofing thread, I'm all for removing some confusing and error prone elements of the color managed workflow, but that should result in something the allows a sane color managed workflow where users have control, not a "transparent" thing where you only select your output bounded color profile and nothing else.

Adobe RGB (1998) is important for:

* People preparing images for printing

The default GEGL/babl pixel formats in floating point are unbounded; and personally I think the 16bit formats should be made 4.12 instead 0.16 fixed point to provide adequate headroom/footroom - though with a predominantely floating point based processing doing this might not be a huge win.

As a person whose work consists in sending files to offset print shops weekly, I tend to agree that the AdobeRBG's gamut gain in green is almost irrelevant, and the gain in cyans is marginal, considering the gamut of the usual output colorspaces. I don't think AdobeRGB is that important for general print, but it's still widely used and some specific models of photographic printers seem to be specially tailored towards the green and cyan extra gamut provided by AdobeRGB.

* People who want or need a small gamut color space that is nonetheless larger than the very small sRGB.

The usefulness of the extended range in cyan/green; and how many perceptually discernable colors you gain compared to sRGB is questionable.

I agree.

A summary rejection of Adobe RGB (1998) ignores the needs and accustomed workflows of the many, many photographers who work in the Adobe RGB (1998) color space.

Not having saddle adapters as mandatory attachment mechanisms for car seats ignores the needs and accustomed workflows of horse riders used to maintain and customize their leather saddles.

Heh, that's not a good argument for something that is more a PR issue than a technical one. People use Adobe. You can't use that argument in a world where people still uses toilet paper :-)

Gez.

(Apologies if I am missing the point.)

What Elle's excellent http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.htmlsuggests to me is that the designer of an operation should choose what color space the operations should internally work in, and convert in and out of it. No more and no less. My impression is that the GEGLized GIMP is structured so that this is feasible without too much work on the operation coder.

I have made this point in another context: Downsample through linear light, for example (unbounded) linear RGB with sRGB primaries or XYZ (unless possibly your sampler is monotone or close to monotone). And preferable upsample through a perceptual colorspace (like Lab or CMC or (unbounded) sRGB).

Elle's examples simply suggest that the "broken" operations do not internally use a good choice of color space, and point to one better choice.

El jue, 17-04-2014 a las 16:48 +0200, Nicolas Robidoux escribió:

Opinion:

Using, internally, a reference unbounded color space (or two: one linear, one perceptual, with, possibly low precision shadows for speed), and converting in and out of it when an image is imported or exported is a sane choice.

It's still not clear (at least for me) what is the impact or the unbounded color values in processing. I'm not pretending I have all the answers, so I'm proposing to discuss it. Elle and I brought a couple of examples where those unbounded values introduce problems, and we didn't get direct answers about them. I think it's not a sane choice pretending that all the cases that don't fit the model are just corner cases. It's quite contradictory to be extremely worried to keep the appearance and behavior of legacy files, and at the same time throw away valid cases of high-end professional editing, labeling them as "corner cases".

Deviations from the "standard internal color space(s)" should be motivated by the operation being performed, not by the color spaces of the initial and final results (which may or may not belong to the same ones in any case).

There are, no doubt, situations in which alternate internal color spaces could give better results. But catering to these corner cases is likely to cause endless headaches for developers and bring no benefit whatsoever to 99.999% of users.

It would be interesting to discuss if those cases are really corner cases. Pulling mattes from green/blue screen shots is really common in VFX, and high end cameras usually have way more color latitude than sRGB, what means that an important part of the gamut needed to pull those mattes would end in the out-of-gamut, hence "unbounded" realm.

We're not talking about details invisible to the eye as in Elle's yellow cone flower example.

Please, don't take this as an attack to the project. I'm just sharing my concerns as a commited heavy user of GIMP and free software. In the end I'll respect your decisions even if I don't agree with them, because you guys are doing all the heavy lifting.

Gez.

On Thu, Apr 17, 2014 at 5:49 PM, Nicolas Robidoux wrote:

(Apologies if I am missing the point.)

What Elle's excellent http://ninedegreesbelow.com/gimpgit/unbounded-srgb-what-works-what-does-not.htmlsuggests to me is that the designer of an operation should choose what color space the operations should internally work in, and convert in and out of it. No more and no less. My impression is that the GEGLized GIMP is structured so that this is feasible without too much work on the operation coder.

The conceptual model for the coder is the same as if the images were converted to floating point XYZ on import; and converted to the coders choice of input and output pixelformats before and after. The smaller set of variation needed for the most frequently performed conversions makes things run faster; in particular since data isn't transformed back to XYZ but on demand changed to the next operations desired format instead of copying where a copy nevertheless would take place in the code.

I have made this point in another context: Downsample through linear light, for example (unbounded) linear RGB with sRGB primaries or XYZ (unless possibly your sampler is monotone or close to monotone). And preferable upsample through a perceptual colorspace (like Lab or CMC or (unbounded) sRGB).

Elle's examples simply suggest that the "broken" operations do not internally use a good choice of color space, and point to one better choice.

The a building block missing for doing this in GEGL with the smallest effort (more effort on the programmer using GEGL) is two GEGL operations using lcms2 for converting to/from arbitrary ICC profiles. One would also want linear versions of the spaces defined by the ICC profile. These two operations would be placed around the steps with overriden working-space. I offer no opinion about how that would be done in the UI. A lower level integration could permit GEGL operation writers to specify wanting "import profile data"; perhaps linearised - the developer of the op could then even offer some choices up for the autogenerated property UI.

Another way to see this list; is as a list of operations that to some degree were broken in GIMP-2.8. Where all operation happen in a globally dictated 8bpc working-space. Possibly sRGB. Most of these are things that should have happened in linear light but didn't. This is what the strong internal color management of annotating all buffers with the datas relation to linear light RGBA which is strictly defined in relation to XYZ fixes. The cleanup and deciding the most reasonably formats for each operation is a work in progress; parts of GIMPs UI surely could be improved in relation to values that currently are just preserved but not visible/actionable.

/pippin