Re: [Gimp-developer] Three questions about opening an image and converting it to linear light RGB

Thanks! for taking time away from LGM to answer my questions about the planned workflow. I understood most of what you said, but I have some questions about a few points:

On 04/02/2014 04:38 PM, Michael Henning wrote:
The following is the planned color workflow, as I understand it.

On Wed, Apr 2, 2014 at 9:31 AM, Elle Stone
<ellestone ninedegreesbelow com> 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

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

My understanding is that the image will be converted not to the linear gamma sRGB but rather to the regular sRGB with its not quite gamma=2.2 TRC. Otherwise the babl "gamma" correction code wouldn't seem to make much sense.

So I'm puzzled by the gegl linear gamma sRGB profile. What's the gegl linear gamma sRGB profile for?

In other words, in the future work flow, will the image be converted to the regular sRGB color space? Or to the linear gamma sRGB color space?

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.

Right now, at floating point precision, using LCMS to convert to a V4 sRGB profile - whether linear gamma=1.0 sRGB or regular sRGB with the parametric curve - does not clip. I've tested extensively this both at the command line and using GIMP. See

On the other hand, converting to any sRGB profile with a point curve (even a straight line substitute for a linear gamma curve) does clip. To work in unbounded mode the destination profile TRC must allow for unambiguously calculating values >1 and <0.

Also converting using integer precision clips.

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).

Do you mean the ability to choose linear precision vs gamma precision? I think I have this figured out:

Currently linear precision "gamma" corrects most operations including the layer blend modes (all of them?), but not, for some odd reason, drawing a gradient.

Currently gamma precision doesn't "gamma" correct the layer blend modes, but does "gamma" correct blur, sharpen, and scale.

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.

By "other color spaces" do you mean converting the image sRGB values to CIELAB, HSV, HSL, CMY(K), YCbCr, etc, as programmed in files in the babl/extensions folder?

The other interpretation would be that you mean "other color spaces like ProPhotoRGB, etc, but I don't think that's what you mean, nor is that what Pippin meant when he used the same phrase, yes? no?

This is transparent to the

I'm not sure how to interpret "transparent to the user".

Do you mean "the user will be fully aware of what's going on"?

Or do you mean exactly the opposite - "the user won't even know it happened"?

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
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?


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.

It makes sense that integer precision would clip. I was asking specifically about converting from a wider gamut color space to sRGB using floating point precision, so the out of gamut RGB values don't clip but rather are carried along as RGB values <0 and/or >1.

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).

I know about the "gamma" issues. For example, at present, if you blur, sharpen, or scale an image that's actually in a true linear gamma color space, regardless of whether you choose "linear" or "gamma" precision, the operation happens incorrectly because the image RGB values are "gamma" corrected before the blur, sharpen, and scale operations take place. As the image color space gamma is already linear, the "gamma" correction produces noticeably odd results (with "scale" you have to use the right image to see the odd results - I converted the brasseur image to linear gamma before scaling).

Once we change
gimp's UI for the new color workflow, this should be much easier to do

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

   -- drawoc

So if I understand correctly, the planned 2.10 "convert to sRGB before image editing" can be tested two more or less equivalent ways:

1. By using default babl/gegl/gimp: Convert the image to the regular sRGB color space with its odd almost gamma=2.2 TRC, at 32-bit floating point precision, and choose "linear" precision and edit the image.

2. By using a modified version of babl/gegl/gimp that has all the babl "gamma" correcting code disabled: Convert the image to a true linear gamma sRGB color space, with the gamma=1.0 TRC, and edit the image.

In both cases the result will be "as if" the image had been edited in a true linear gamma sRGB color space, yes?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]