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…
I still see some problems with the “Saturation eq” filter: some areas turn grey even with all sliders set to “0”.
The image I have used for this test is here.
That’s because you used the buggy version of CImg.h. You need to make sure you are doing a make clean before compiling the plug-in, otherwise the file CImg.h won’t be updated.
You are absolutely right! I have updated CImg.h, re-generated the AppImage and updated the links in the “Community software” page…
@David_Tschumperle do you know which is the minimum required tile padding at a given radius for the new sharpen [texture] filter?
I’d love to include it as a native filter in PhotoFlow, as part of the available sharpening options…
Well, the padding will depend on the Radius parameter of the sharpening filter.
I’d say something from 1.5*radius to 3*radius should be OK.
EDIT: Good news by the way 