linear color transfer in gmic ?

wow.that’s a good surprise at breakfast.will try that asap.thank you so much David.

The commands here are not used within fills. There are evaluated even before the fill command starts, because they are called outside the fill string double quotes, so they are substituted in the fill argument before it starts.

The shadows and gamut clipping should be put under control somehow in there. Luminance details got lost.

The command transfer_pca just transfers the covariance matrix and mean vector from one image to another one.
I guess that it’s not enough by itself to say it transfers colors. Additional commands may be used to fine-tune the result.

@David_Tschumperle, thank you for this filter.

I have the following error:

This happens also with "Transfer Colors [Histogram], not with the other two transfer_colors filters.

@iarga, that is really worrying. Looks like the recently introduced store commands does not work as expected for you, and I plan to use it more and more in the future.
We really have to find what is going on.

May I PM you next week, to make you tests some custom builds of the plug-in ?

Works fine and dandy for me using Krita 4.3 Pre-Alpha and G’MIC 2.8.2.

@David_Tschumperle, yes you may.

The error is in GIMP 2.8

in GIMP 2.10 (samj) it works:

Works for me. I have GIMP 2.10.12. (BTW, I am getting the same preview problem as afre_softlight where the preview is cropped and shifted. What happens depends on the preview space given relative to the images’ dimensions. I think it happens when the top input layer is smaller than the bottom one. Reset zoom usually corrects it.)

When you get the error with GIMP 2.8… How did you install the G’MIC plug-in there ?
Using the installer from the official http://gmic.eu site ? or from another source ?
It’s important to know that the bug appears on the version distributed on the official site, because we can ensure the compilation has been done properly.

I always use the zip, so I used this:

[ ] gmic_gimp2.8_win64.zip 2020-01-09 19:17 33M

OK, I’ll test this on my Windows VM, but not before next monday.

1 Like

I did a fresh install of GIMP 2.8 on another (win 10 64) PC. also fresh install of G’MIC with exe and zip, both same error.

with GIMP 2.10.14 and the latest G’MIC for GIMP 2.10 on this PC, no problems, everything worked as expected.

Legitimate question, should G’MIC drop support for GIMP 2.8? There’s no reason to use it when GIMP 2.10 exists. But, then again I do not use GIMP.

That’s a good question.

I don’t think so, at least until I cannot build the G’MIC plug-in for GIMP 2.8 anymore.
Right now, I’ve a working compiling environment for GIMP 2.8 (kindly set up by @samj),
and it doesn’t cost anything to get the plug-in working for GIMP 2.8.

I did the same, and I have also the error. That’s interesting, because I will be able to do my own tests and try to see what is going on.
Hopefully, the bug will be fixed one day or another :slight_smile:

1 Like

I think I’ve found it!
Just uploaded a new installer and the corresponding .zip, for 2.8.2_pre, here : https://gmic.eu/files/prerelease/ (for Windows only).
@iarga, could you please test the updated version and tell me if that fixes the issue for you ?

I also think you found it!

This fixes the the issue for me, thank you David.

That’s pretty cool :slight_smile:
I guess I’ll have to release version 2.8.2 soon, because this issue probably happens for all users of GIMP 2.8 and G’MIC 2.8.0+.

But…:pensive: now in GIMP 2.8, this happens:

original image:


After “Transfer Colers [PCA]” (with lenna from wikipedia as above), after aplying “OK”, the output is this:

In the preview, this didn’t happen as you saw in my last post.

And after filter-refreshin GIMP 2.10.9 (samj) I get nice results (precision 8 bit integer:


Thats a big difference.