I’m happy to announce the release of a new version (numbered 1.7.7) of the G’MIC image processing framework. As always, I encourage upgrading to this new version as soon as possible . Particularly this time, as we found (and fixed) two critical bugs in colorspace conversions RGB->HSL and RGB->HSI in the previous stable version.
This version is backward-compatible with the previous one (1.7.6), meaning that all new filters added in this version have been also backported for users of the previous stable version.
What is G’MIC?
G’MIC is a full-featured open-source framework for image processing. It provides several different user interfaces to convert/manipulate/filter/visualize generic image datasets, ranging from 1d scalar signals to 3d+t sequences of multi-spectral volumetric images, thus including 2d color images.
[gimp] New filter Details / Sharpen [texture] implements a new image sharpening algorithm based on the rolling guidance filter to separate and enhance texture part of an image.
[web] Default downloads of pre-compiled binaries now links to the pre-release of the incoming version (not the case for the source .tar.gz package). G’MIC is considered as stable enough now to propose the cutting-edge development versions to the users by default.
Bug fixes:
[core] Fixed two critical bugs in color conversion commands -rgb2hsl and -rgb2hsi. These commands were not working correctly in version 1.7.6.
[core] Fixed small bug in command -bilateral : wrong result was returned when std_variation_r==0 and ‘std_variation_s!=0’ (or if guide was a constant image).
I did some quick experiment with the Sharpen [texture] filter, and it seems to give really high-quality results, much better than USM and also better that RL deconvolution… great job David!
The default channel is set to Lab [lightness], and I was wondering how this is computed. Do you assume input sRGB data?
Maybe it is time to consider adding proper color management to CImg/G’MIC… I am ready to devote some time to that, and even if it will take 6 months or more to get it working I think it is still a valuable objective.
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.
. Particularly this time, as we found (and fixed) two critical bugs in colorspace conversions 
