The following is the planned color workflow, as I understand it. On Wed, Apr 2, 2014 at 9:31 AM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
