The following is the planned color workflow, as I understand it.

On Wed, Apr 2, 2014 at 9:31 AM, Elle Stone wrote:

Please bear with me while I ask some questions. I'm trying to clarify something that I might be completely confused about. The point of the first two questions is to be able to ask the third question. If I'm confused about the answers to the first two questions, what I'm asking about in the third question won't be possible.

First question:

The phrase "linear light RGB" is used a lot. When the topic is BABL/GEGL/GIMP, does "linear light RGB" mean Pippin's extended sRGB color space defined by the sRGB primaries and the linear gamma tone reproduction curve?

Typically, yes. linear light RGB could potentially refer to other color spaces, but when you hear it in a babl/gegl context, this is almost always what we mean.

Second question:

Is Pippin's extended sRGB/BABL's "linear light RGB" the same as LCMS's unbounded mode sRGB?

In other words, are BABL's "linear light RGB" and LCMS's "unbounded mode linear gamma sRGB" two ways of describing the same thing, namely, after converting from some other color space to linear light RGB, otherwise out of gamut RGB values aren't clipped but rather carried along as RGB values that are less than 0.0 and/or greater than 1.0?

LCMS's unbounded mode can work with a variety of different color profiles, so we construct an icc profile that's the same as babl's linear light RGB when we do conversions.

That's the goal of create_lcms_linear_rgb_profile in https://git.gnome.org/browse/gegl/tree/operations/external/lcms-from-profile.c?id=944719a8ca2ad957f02c4a4bc0eca66c4e7dde7a#n60

Ideally, out of gamut values should not be clipped, but I'm not entirely sure if that works that way right now. We should have that working by 2.10.

Background for the third question:

Right now when using GIMP from git, it's possible to open an image in, for example, the ProPhotoRGB color space, and edit the image while keeping it in the ProPhotoRGB color space. There's no automatic behind-the-scenes conversion to unbounded mode sRGB/extended sRGB/linear light RGB.

I've been assuming that before 2.10 is released this behavior will change. My understanding is that in the future:

1. The user will open an image with GIMP and maker sure the right ICC profile has been assigned.

2. Before actual image editing can begin, the image will be converted to extended sRGB/linear light RGB "behind the scenes" without the user necessarily even knowing that this has happened, though a little warning/user education/notes in the GIMP documentation might explain the sudden appearance of negative RGB values and/or RGB values that are greater than 1.0.

We will need a way for users to change the incoming icc profile on import, just in case it has the wrong embedded profile. There will be some level of user awareness, but I don't know how much.

3. All subsequent image editing will be done in the extended sRGB/linear light RGB color space.

Yes. To clarify this point: Users will have the ability to choose to edit in different bitdepths and (probably) also the option between editing with the layers stored as a linear or a perceptual (sRGB TRC) color space (which only really affects the way layer modes work, along with things that depend on layer modes like painting).

Also, gegl operations can request to do their work in different color spaces, so depending on the operation being performed, the editing may actually happen in other color spaces. This is transparent to the user.

4. Upon exporting the image to disk, the use will be able to convert the image from extended sRGB/linear light RGB to their chosen ICC profile. They won't be forced to export an sRGB image to disk.

I asked almost the same question in a previous email (http://gimp.1065349.n5.nabble.com/Soft-proofing-and-the-GIMP-Display-Filters-and-Color-Management-settings-td42139i20.html). But Pippin made a distinction between "pipeline" and "workflow", and I'm not sure what the distinction might be in practice. So I'm asking again as explicitly as possible:

Will the image be converted to extended sRGB before image editing can begin?

Yes.

Will the user see out of gamut (that is, out of the sRGB color space's gamut) RGB values expressed as RGB values that are less than 0.0 and/or greater than 1.0?

Yes. There is one complication: Users have the ability to choose to edit in different bitdepths, so the integer bitdepths will be clipped.

Here's the third question:

If what I just wrote is an accurate description of the way GIMP will eventually work, can the future workflow can be tested *now* by:

1.Promoting the non-sRGB image to 32-bit floating point

2. Doing an ICC profile conversion *from* whatever ICC profile color space it might be in (perhaps ProPhotoRGB), *to* the GIMP built-in sRGB profile

3. Editing the image as desired

4. Doing an ICC profile conversion *from* the GIMP built-in sRGB profile *to* the desired output ICC profile (perhaps again ProPhotoRGB) and then exporting it to disk.

This is roughly correct. You need to be careful though, because if you do the icc profile corrections in the wrong image mode (linear vs perceptual), or you use the wrong builtin RGB profile (linear vs perceptual), you can easily end up with a gamma of ~2.2 or ~1/2.2 applied to your image on accident (It's really the sRGB TRC, not a gamma of 2.2, if you want to be technically correct). Once we change gimp's UI for the new color workflow, this should be much easier to do properly.

You definitely have the main idea of what's going on, although there are a few small complications that I've pointed out. I hope this helps.

-- drawoc

On 02.04.2014 15:31, Elle Stone wrote:

Please bear with me while I ask some questions.

Hi Elle,

we're currently at Libre Graphics Meeting 2014, so answers might take a bit longer. Please bear with us :)

http://libregraphicsmeeting.org/2014/ https://www.rebelmouse.com/lgm2014/

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

El mié, 02-04-2014 a las 16:38 -0400, Michael Henning escribió:

Will the image be converted to extended sRGB before image editing can begin?

Yes.

Will the user see out of gamut (that is, out of the sRGB color space's gamut) RGB values expressed as RGB values that are less than 0.0 and/or greater than 1.0?

Yes. There is one complication: Users have the ability to choose to edit in different bitdepths, so the integer bitdepths will be clipped.

Does this mean that in float bitdepths a pixel in a layer could have negative RGBA values?
That could break compositing badly if those values are not clipped (and clipping those out-of-bound values would destroy the original gamut, defeating the purpose of the unbounded colorspace transform).

Maybe I'm getting it wrong, could you please clarify that?

Gez.

Does this mean that in float bitdepths a pixel in a layer could have negative RGBA values?
That could break compositing badly if those values are not clipped (and clipping those out-of-bound values would destroy the original gamut, defeating the purpose of the unbounded colorspace transform).

Yes they can, all of the current composition modes will survive this, though I think a couple
may still clip things internally. In general any GEGL operation that takes a floating point
format needs allow values outside of [0.0, 1.0].

Some operations are made worse if you don't allow out of "gamut" values (e.g. blacker than black and whiter than white).

The first example that comes to mind is convolutions that are implemented in a separable way and that have negative coefficients.

I vaguely remember something about resampling with a transparency channel too (which is done correctly in ImageMagick; there is a thread where I question this and then "approve" in the ImageMagick forums).

So: If your operation is made worse by out of "gamut" values, clamp them first thing.

I'm getting questions about negative light values and "values larger than 255" and why one would not clip them at every step of a chain of operations even if the initial input image and final output images are both (say) sRGB.

(Maybe putting quotes around "gamut" was not quite enough to be clear.)

Here are some links that kind of answer the question, right off the top of my head.

http://entropymine.com/imageworsener/clamp-int/

http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=22287

As soon as you do operations such as unsharp-mask, you produce "blacker than black" (negative, say) and "whiter than white" (larger than the upper bound of your color cube, if your color space is a represented by a cube of values, ignoring transparency and CMYK issues for simplicity). Unless your colorspace is large enough (unbounded, say) to fit those "unnatural" colors, you need to decide what to do with them at every step.

Another simplistic example: Suppose you are "rotating" colors (in the sense of performing a rotation of the color values around some anchor color understood as points in 3D space). If you clamp at every step, this operations is not reversible, because the pieces of the cube that stick out after the rotation are lost forever. If you don't clamp, this operation is reversible.

My simplistic example suggests that if you want to modify an image using transformed color coordinates, and want to be able to return to "untransformed" color coordinates losing as little information as possible, you don't want to clamp.

My point: Clamping at every step demonstrably makes things worse, at least some of the time.

Metaphor: imaginary numbers were initially seen as "artificial" means to solving equations in which only "real" numbers appeared: They were not part of the statement of the problem, and they did not appear explicitly in the final answer. People only wanted the "real" solutions to the problem. (Because they're real!)

If, however, you go "The problem is real and the solution is real, so everything in between must be real" and start ignoring the imaginary parts of the real numbers at every step, you'll get the wrong answer quite often.

Conclusion: It's not because colors are not found in the initial image and cannot be displayed in the output that they should be discarded at every step.

-----

I wrote more than I wanted. Hopefully I've made things clearer.

My apologies for being vague: Indeed white is not necessarily at the boundary of the set of values in 3D that are used to represent color values. (It is in sRGB.)

Summary:

It is my very strong opinion that values should not be clamped by default.

If you are writing an operation (a "node") that is broken by negative or values breaks, do not clamp the input and output without carefully considering the possible impact on the entire toolchain.

Very very carefully: Clamping values can have surprising side-effects (as the Blender community apparently discovered through experience).

If it is likely that your operation will be fed, for example, negative values, try to write your operation so it does something sensible with them.

Clamping should be a last resort.

-----

Of course when you are dealing with specific color spaces you may know "what's what" and, for example, that negative values are totally meaningless. This business is almost as messy as dealing with the fact that colorspace handling is colored by "intent".

I wish I had figured out a simple "Always do this and you'll be fine." or "Never do this and you'll be fine".

GIMP is too complex an application for me to be able to make such pronouncements. And this question of "Shouldn't we clamp negative values?" is intertwined with colorspace conversion issues, which is really difficult to get just right in all situations without user intervention.

Layers have meaning, colorspace are linked to intent and purpose, and automating processes based on hidden semantics is not trivial.

Two observations:

- Currently in babl, all integers representations map the used gamut [0.0, 1.0] to [0, MAX_UINT{8, 16, 32}], leaving no room for out-of-gamut values. But this is fixable. - Some operations may need to output non-images data (gradients, arbitrary convolutions, domain changes such as Fourier or Haar, differences, correlations, prefix-sum and whatnot...), some operations may need to take those as input. At some point, it might make sense to properly support such non-image format too. Trying to make them fit in traditional color-spaces, unbounded or not, might be a bad idea. We already encountered such issue many time in GEGL.

Regards,

Téo

I just noticed that I sent my last two e-mails to Nicolas without forwarding them to the list.
I think his replies address these questions, so I'll copy them here. Sorry for the inconvenience. I forgot to hit "reply all".

----

El vie, 04-04-2014 a las 08:53 +0200, Nicolas Robidoux escribió:

Some operations are made worse if you don't allow out of "gamut" values (e.g. blacker than black and whiter than white).

What do you mean with "blacker than black" and "whiter than white" and how those achromatic values can be out of gamut? I get it if you mean that white can go beyond 1.0 (display referred white) in scene referred HDR, but what does "blacker than black" mean? Negative light?
Could you please explain that and give an example of how those values could be produced?

The first example that comes to mind is convolutions that are implemented in a separable way and that have negative coefficients.

I vaguely remember something about resampling with a transparency channel too (which is done correctly in ImageMagick; there is a thread where I question this and then "approve" in the ImageMagick forums).

I'm not sure if this is exactly what you mean, but I remember from Blender that some of its antialiasing filters created negative values in alpha channels.
iirc Blender used to clamp those negative to zero, which was a terrible idea, since in an image with associated alpha those clamped values meant that pixels that needed to be semitransparent became fully transparent. I can't remember if it was fixed (and how) but I do remember that either the negative values or the clamped values in alpha channel introduced compositing artifacts.
It looks safer to avoid negatives in convolutions in the first place.

So: If your operation is made worse by out of "gamut" values, clamp them first thing.

Sometimes it isn't enough for fixing the problem, and in the context of unbounded gamut I think that clamping means clipping gamut, which defeats the purpose of unbounded gamut.

Maybe I'm getting all wrong, so I'd appreciate is somebody clarifies it.

El sáb, 05-04-2014 a las 12:21 +0200, Nicolas Robidoux escribió:

It is my very strong opinion that values should not be clamped by default.

If you are writing an operation (a "node") that is broken by negative or values breaks, do not clamp the input and output without carefully considering the possible impact on the entire toolchain.

Very very carefully: Clamping values can have surprising side-effects (as the Blender community apparently discovered through experience).

If it is likely that your operation will be fed, for example, negative values, try to write your operation so it does something sensible with them.

Clamping should be a last resort.

Not even a last resort. Clamping unbounded values will destroy the excess gamut that the unbounded transform is supposed to keep. Blender works in scene referred linear (from 0 to infinity) and clamping is used to restrict the values to the display-referred limits when the user needs it.
In Blender chromaticity is never out of bounds (unless you explicitly fed a node with an ilegal value, like a negative value), it's just intensity. For instance, if your red channel goes beyond 1.0 it never means "redded than red".

We agree: values should not be clamped. My question question (and I think also Elle's question) wasn't about whether those values have to be clamped or not, but about the impact of values beyond the display referred bounds resulting from the forced conversion to unbounded sRGB.

Gez.

On Mon, Apr 7, 2014 at 4:24 PM, Elle Stone wrote:

I'm still testing the other gimp/app/operations layer blend modes. But probably *all* clamping code should be removed from *all* layer blend modes.

Elle's two cents worth

I would like to mention that the current blending modes were created to replace the old 8-bit ones. I was told they should be as close as possible to the old ones (so you could open images made with t sure how to show both sets of blending modes in the UI.

El mar, 08-04-2014 a las 09:19 +0300, Ville Sokk escribió:

On Mon, Apr 7, 2014 at 4:24 PM, Elle Stone wrote:

I'm still testing the other gimp/app/operations layer blend modes. But probably *all* clamping code should be removed from *all* layer blend modes.

Elle's two cents worth

I would like to mention that the current blending modes were created to replace the old 8-bit ones. I was told they should be as close as possible to the old ones (so you could open images made with t sure how to show both sets of blending modes in the UI.

As a user following the development of GIMP, I think it would be far more interesting if the blending modes and operations work correctly and consistently with the new core.
I'm aware that keeping legacy compatibility is high in the priorities list, but maybe that can be added later. From what you say, it looks like "proper" has to wait. It seems more reasonable if it is the other way around.

At the moment some legacy compatibility seems to be getting in the middle every time you want to try the new capabilities of the program. Clipping and some blending modes is one of those things, and some confusing bits about editing in linear and gamma precisions too.

Gez.