Yes it does, as the filter has been mainly designed to work on current stable version of GIMP (2.8), which inputs sRGB data to the plug-in.
Not sure there are much to do. Beware, CImg is a generic image processing library, so it doesn’t really care about what kind of data your image represents. Image values may be color of course, but anything else too. So, I don’t believe adding color management in a general-purpose image processing library is useful at all (we discussed about this with @Elle already).
It’s a part of CImg for now, but we can easily add it as a G’MIC command if necessary, with additional parameters for better color management. What kind of addition parameter do you need ?
In fact, it is not a question of commands and parameters… to my mind, color management is part of the image properties.
To correctly interpret an image buffer, you need to know the width, height, bit depth, number of channels … and the associate colorspace (RGB, Lab, CMYK, …) and color profile.
So commands like “convert to Lab” (or whatever is the G’MIC command for that) could read the color profile of the input image data, do the proper conversion, and attach to the new image data the Lab profile.
So, to be honest, I’m not sure this is the role of G’MIC to care about color management. Basically, the spirit behind CImg/G’MIC, is that they manipulate images as array of values, nothing more. All algorithms are somehow “blind” concerning the meaning of these values. The exceptions are for colorspace conversions functions like CImg<T>::RGBtoLab() for instance (i.e. command -rgb2lab in G’MIC). Those functions assume the input data you pass are e.g. RGB colors.
But at the end, it’s the role of the user to know what is the meaning of the values he manipulates. Feed CImg/G’MIC with any kind of values you want, and you’ll get a result for sure. But keep in mind what you sent, because there are absolutely no ways CImg/G’MIC knows anything about it. What I mean, is that the structures in CImg/G’MIC do not have fields like datatype or colorspace or annoying things like that
Image processing algorithms work with mathematical quantities, and are mostly blind about what these quantities represent. As I said, the only exception is for colorspace conversion, where I admit there could be maybe more control (so more parameters), e.g. having the choice to choose the illuminant for Lab conversion. But this concerns only a very reduced set of available algorithms, so I’d prefer to add new useful parameters to them instead of having a ‘global’ approach where a color profile is associated to an image.
Sorry Andrea, but yes @iarga made me discover those two bugs I really need to fix.
The sources for 1.7.7 are already available, pre-compiled binaries are coming too in a few minutes.
My point here is that there is nothing like “RGB colors”, because an RGB triplet has no meaning without knowing the associated colorspace (sRGB, Rec.2020, ACES…). So, in the example of CImg<T>::RGBtoLab(), either you take into account the colorspace of the input RGB values in the Lab conversion, or you assume that the input data corresponds to a specific colorspace (sRGB, I guess).
In the latter case, I would suggest, et least for the GIMP plug-in, to introduce an explicit conversion of the input GIMP data to sRGB, and a conversion back to the GIMP working colorspace when the G’MIC plug-in returns the result image…
That’s it, I assume the input data to be linear RGB colors with the classical illuminant D50, for the Lab conversion.
That’s exactly what I’ve done in the GIMP plug-in (for 2.9). When I retrieve the image buffer from GIMP, I ask it to provide the pixel data in the sRGB format. And I put it back in sRGB as well.
Looking at the gmic .def file, I see that every time you call -rgb2lab you also have a call to -srgb2rgb, so I assume that what you call RGB is in fact sRGB with linear gamma, right?
Could you point me to the place where this is done in the plug-in code? I remember having seen some sRGB conversion in the past, but it seemed to be commented out in the code…
No what I call RGB is usually linear RGB, not the same as sRGB.
My RGB->Lab function requires linear RGB as input.
For instance, here : https://github.com/dtschump/gmic/blob/master/src/gmic_gimp.cpp#L1872
Each time the plug-in connect with GEGL to input or output data, it request the buffer format to be R'G'B'A which implies an automatic conversion from/to sRGB, whatever the current color mode selected in GIMP is.
Ok, so I guess the most correct formulation of the input data for Lab conversion is “RGB data with linear gamma encoding and sRGB primaries”.
Are you 100% sure about that? Because as far as I know, GEGL also assumes that the pixel data is encoded with sRGB primaries… so if the GIMP image is in ProPhotoRGB with gamma=1.8, I am not at all sure that asking a buffer in R'G'B'A format will result in an actual conversion from ProPhoto to sRGB.
No, I’m definitely not sure. But, that is what I’ve understood after discussing with mitch on IRC.
If that’s not true, by the way, I’m wondering why GEGL allows to choose the desired color format then. Mitch told me that the necessary conversion was done automatically, so I didn’t have to manage this by myself.
create an empty image in gimp, in the built-in sRGB color space and floatong-point precision
fill it with pure red
convert the image to prophoto; the red channel will now be lower than the maximum
run the gmic plugin on this image, and check the channel values. If the red channel is not equal to 255, it means that the RGB values are still in prophoto, i.e. that no conversion to sRGB was performed by GEGL
I can do this test myself, but only in few hours from now…
Yes that would be interesting.
In any case, I think is the plug-in should have a way to get a kind of ‘normalized’ sRGB data to feed the G’MIC library, then convert it back after the processing, in some way. So, I don’t really think color-managed functions should appear in the G’MIC core.
So I did the exercise that I proposed, and my conclusion is that GEGL does not apply a conversion to sRGB when asking for R'G'B'A format.
The attached screenshot shows a pure red in sRGB colorspace, converted to “ACEScg with the sRGB gamma encoding”. I have then run the G’MIC plugin on the ACEScg image, and applied the “Curves” gmic tool to be able to visualise the histogram of the RGB channels.
What version of GIMP 2.9 did you use ? Is it the so-called color-managed version of Elle Stone ?
In that case, I know she has disabled some sRGB<->RGB conversion code in it, so maybe this can make a difference.
Also, I was speaking specifically about the sRGB<->RGB conversion, and in case of the color profile you are using here, I guess this is not this kind of conversion occuring (but rather a ‘simple’ matrix applied).
So, yes maybe there are some ways to retrieve a more precise sRGB input for the plug-in, by doing the inverse color profile conversion before getting the image data.
No, I am using the standard version from GIT, the same that is included in the AppImage packages I am providing.
Well, the point under discussion here is the fact that by asking a buffer in R'G'B'A format you expect to get pixel values in sRGB, but this is not the case. If the “Precision” mode of the gimp image is set to “Perceptual gamma (sRGB)”, and the gimp image is not monochrome, asking for the R'G'B'A format will give you the gimp pixel values without any conversion.
Here is another example. I started from a sRGB image filled with 50% gray, and converted it to ACES with gamma=1.0 (linear). Note that the “Precision” flag is not modified by GIMP, and it stays as “Perceptual gamma (sRGB)” even if the working colorspace is linear. Then I have ran the GMIC plug-in on this linear gamma image, and opened the curves tool to see the channel histograms.
As you can see, the channel values are well below 50%. This means that asking for a R'G'B'A format does not always apply a conversion from linear to gamma-encoded. In order to this to work, the user has to explicitly set the “Precision” to “linear light” from the GIMP menus.
Now here is what happens if the GIMP image is in ProPhotoRGB with gamma=1.8. The image is not linear, therefore “Precision” should stay as “perceptual gamma (sRGB)” even if the gamma encoding is not sRGB. So GMIC will get the image data in gamma=1.8 encoding, because the conversion to R'G'B'A format will do nothing:
Now, when you call -srgb2rgb you will linearise the RGB data assuming the sRGB encoding, and therefore the linearisation will not be correct…
Given the results above, I think this is mandatory to get a better reproducibility of the GMIC filters independently of the GIMP colorspace.
If you want, I have some code to offer, as I have been facing the same problem in my PhotoFlow plug-in. So I can fork your github repository and send you a pull request when I have something usable, if you agree…
