GNOME.org
 

Re: [Gimp-developer] Some blend modes break in unbounded mode sRGB

On 04/13/2014 12:16 PM, Teo Mazars wrote:

HSL, HSV are defined relative to the RGB color space the image
happens
to be in, which I think is what you mean by "non-absolute" color
spaces.

So if you use LCMS to convert from an RGB color space to HSL or HSV,
then the resulting HSL/HSV values depend entirely on the source RGB
color space. Changing the source color space changes the resulting
HSL/HSV colors. I don't think there's any LCMS code for naive CMY
where
C=1-R, M=1-G, etc, but if there were, it also would produce different
results depending on the source RGB color space.
Regarding programming in the ability for the user to specify chromaticities, and/or hard-coding in specific RGB color spaces like ProPhotoRGB, why not just remove *all* the chromaticitiy-specific (mostly luminance-calculating) code and replace it with appropriate calls to LCMS? 


However, if you use the BABL code to convert to HSL, HSV, etc, the
resulting values are only correct if the image has the sRGB
chromaticities. The same is true for converting to Gray, YCbCr, etc.


Exactly, babl only knows about absolute color spaces so far, and
non-absolute ones are hard-wired using sRGB, which is wrong.
The conversion to CIELAB is also hardwired to use the sRGB (unadapted) chromaticities, currently also to clip a and b channels: 

MAKE_CONVERSIONS (u16_ab, -128.0, 127.0, 0x00, 0xffff)
This means some real colors are clipped upon conversion to CIELAB (real violet blues, real blue greens, real yellow greens, greens, and orange yellows).
See http://brucelindbloom.com/index.html?LabGamutDisplayHelp.html, section on integer encoding of CIELAB.
The current code also clips to 100.0 on the L* axis, which means if one is using unclipped RGB data for HDR values, they also will be clipped upon conversion to LAB: 

MAKE_CONVERSIONS (u16_l, 0.0, 100.0, 0x00, 0xffff)
LCMS can make unbounded mode conversions to CIELAB, without clipping the data. The BABL code also could be rewritten to do unbounded mode floating point conversions to CIELAB. I made a quick stab at it, but haven't yet figured out all the moving parts.
In any event, converting from any source color space to unbounded mode sRGB and then to CIELAB theoretically should give the same results as converting from the source color space directly to CIELAB. The same would be true of conversion to XYZ. 



About the general topic, the point would be that babl's RGB format
should have arbitrary chromaticities instead of fixed ones? Not sure about
implications of that... Operations should be then able to request some
data about the color space given, like coordinates of primaries, and
use them instead of the traditional [0.0,1.0]³.
Operations should still be able to know absolute values, and to request
either a perceptual or a linear light color space with those chromaticities.
If I am not completely off, how this should be done is unclear to me.
Sometimes I think there might be some confusion over what it takes to edit an image in a linear gamma color space. *All* you really need is a high bit depth image editor and the linear gamma color space of your choice.
You don't *need* all the background "stuff" that BABL/GEGL/GIMP has programmed in to guide code to use or not use "gamma corrected" or "perceptually uniform" RGB values. All that background "stuff" presumes the image color space has the sRGB TRC. You could eliminate that code and just open an image that's already in a linear gamma color space.
If *all* the BABL code that converts back and forth between the sRGB TRC and linear gamma were simply removed, along with *all* the BABL/GEGL/GIMP code that currently codes choices and paths between gamma-corrected and not gamma-corrected operations: 

*The code would be simpler.
*The user could *choose* to use a linear gamma color space with the chromaticities of his or her choice. Or they could *choose* to edit in the more perceptually uniform color space of their choice.
I'm not merely speculating about the code simplification. I keep a copy of BABL/GEGL/GIMP modified to eliminate the background conversions, just so I can edit my linear gamma images in my linear gamma color space of choice. Every now and again I take a stab at eliminating some more code, just to see how far I can take it.
One remaining issue in my modified BABL/GEGL/GIMP is the hard-coded sRGB luminance values. I took the easy route and replaced the sRGB values with the luminance values from my custom RGB working space. But the right way to deal with this issue is to use LCMS to retrieve the color space chromaticities.
Having said all that, the BABL conversions back and forth between sRGB TRC (almost perceptually uniform) and linear gamma provide the obvious advantage of being able to allow the user to choose to switch at will between "gamma" corrected and linear RGB values. All the user would need is a color space that has the sRGB TRC, along with whatever chromaticities the user wants.
Except right now some operations (for example Unsharp Mask, Scale, Gaussian blur) are programmed to "always" gamma correct, which takes choice away from the user and also prohibit editing an image that is already in a true linear gamma color space. 



Also, I am under the impression that it conflicts slightly with the
"each operation ask for the color space it needs" idea.
I am confused as to why this choice of whether to operate on linear RGB data or more perceptually uniform RGB data should be taken away from the user and hard-coded into BABL/GEGL/GIMP.
It seems to me that the better approach would be to write some good documentation and allow the user to make his/her own choice about whether to operate on "gamma" corrected RGB values or not.
What if the user really wants to operate on data that isn't "gamma corrected"? What if the user really wants paint strokes to have dark edges? What if they do want gray rather than yellow between red and green when they do a Gaussian blur, for some specific artistic intent or because that's what they've always done?
Choice is good. Right now there is some very limited user choice about what to gamma correct and what to not gamma correct. I think the choice should extended to *all* operations.
Back to the hard-coded BABL conversions between linear gamma and the sRGB TRC. Those conversions do serve the very nice purpose of allowing the user to switch back and forth between working with linear data and perceptually uniform data.
As currently coded those conversions can be used with *any* color space chromaticities, as long as the source color space has the sRGB TRC, which profiles are easy to make. 


A proposed course of action:
1. Leave the BABL conversions back and forth between linear and the sRGB TRC.
2. Distribute commonly used ICC profiles with the same TRC that the BABL conversions are using (the sRGB TRC, but it might just as well be gamma=2.2 or lstar). RawTherapee already allows to output in a color space with the ProPhotoRGB chromaticities and the sRGB TRC. 

3. Keep the GIMP distinction between "GAMMA" and "LINEAR" precision.

4. "Gamma" correct *all* operations that are done using LINEAR precision.
5. Remove *all* "gamma" corrections from operations that are done using GAMMA precision. 

4 and 5 together give the user three choices:
* They can open a true linear gamma image and edit it at GAMMA precision (sounds confusing, but that's what would be required). But they won't benefit from the option to switch back and forth between linear and "gamma" corrected RGB values.
*Or they can open an image in a perceptually uniform color space, keep it at GAMMA precision, and not have anything at be "gamma" corrected.
* Or they can open an image in the color space of their choice, as long as the TRC for that color space is the TRC that BABL is using, currently the sRGB TRC, and then have the option to switch back and forth between operations done in linear and perceptually uniform RGB values.
6. Write up the code that calls on LCMS to retrieve chromaticities from the image color space to take the place of hard-coded sRGB Luminance values.
7. Write up documentation explaining to the user how everything all hangs together. 


Anyway, that's my proposed solution. I can help with items 6 and 7.

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