You have made an excellent filter: "Specific saturation"
Is it possible to make a filter like this, but works on shadows, midtones and highlights separately?
(as in “Color grading” filter from John Lakkas)
Is this a good or bad idea?
Yes it’s possible, a pity I’ll have little spare time for the next few weeks
The simplest method wouldn’t take long to make, might squeeze it in somehow!
Thank you for your answer. For me it isn’t simple. I’m learning, very, slow. I searched other filters with shadows, midtones and highlights. But there are no “simple” filters I can “easily” combine with your filter. I understand it has no high priority for you. But I’m patient and in the meantime I can study a bit.
I noticed a difference between the outputs of GMIC and GMIC on GIMP. I am guessing that it is because GIMP handles images/layers differently. It is more apparent when you run multiple commands in succession. Might be a non-issue but as a new user I found this interesting.
That’s interesting. What kind of differences ?
There shouldn’t be a lot of difference I think. What I see mainly is that the CLI tool displays image in a ‘normalized’ way (all values are re-strectched in [0,255] for visualization), so it may visually differ, mainly with more contrasts with the CLI version (but if you save the images as files, it should be the same, as the normalization is applied only for visualizing images).
I wonder which version of gimp? If you’re in 8bit per channel, you lose information from G’MIC to gimp after each filter is run (G’MIC is 32bit float). So the more filters you use in sequence the more the result diverges…
Good point. I am using 2.8.18 but I should be using 2.9.5? What else should I be mindful of to achieve parity?
2.9.x has been working well for me and can handle 32 bits.
How do I add G’MIC 1.8.0pre to GIMP 2.9.5 (portable from Partha)?
PS This seems to work:
Opened G’MIC in GIMP.
Download external data.
Left you a longer answer at GIMPChat, but the short answer is, both G’MIC and GRIP are working fine together and the favorites imported and work fine, David. Thanks a heap.
Just posted this at GIMPChat. This could be a feature, but, if you open up GRIP, it resets your presets in G’MIC and vice/versa (so if you changed any of the sliders in either one and then open the other one, it will reset the sliders as I mentioned). If you stay within the plugin universe (i.e stay in GRIP for instance) then the sliders will keep their position as you left them for the preset that you worked with. Just a head’s up.
Minor issue (not exactly a bug) that seems to affect 1.8 pre and 2.0 pre x64 gimp - the update file is rewritten to disk each time the plugin interface is launched.
Also noticed something about retinex - seems odd to do a sum of logs when it amounts to log of the product, i.e. it could just be 3 * log([input]) - log([G1] * [G2] * [G3]). Maybe there’s some other reason I haven’t thought of.
Thanks Andy, I’ll try to fix that ASAP.
I could swear the update file overwrite was fixed for a while, but it seems to be back now! Sorry if you haven’t actually looked at it yet, I might be imagining things…
On another note, I had a thought about the old gimp <-> G’MIC zero opacity handling bug. Instead of trying to deal with the output not being written in fully transparent areas, it might be better to always “sanitise” the input when previously transparent regions might be revealed.
Example: with -remove_opacity, set other channels to 0 where the opacity was 0 beforehand.
Another choice is to do that automatically with every gimp input: where opacity = 0, set all channels to 0. There are downsides to that though and it’s a relatively rare problem.
Of course all this would be moot if they just fixed the actual bug
- 05/29/2017 : Final release !
You may retire, then.
Not before the final release of version 2.0.1
Will there be a manjaro build? The one I have is an outdated pre-release version but I know it’s extra work. This version is a great step forward for G’MIC, thanks to all involved
Maybe Kdenlive could be second in line? =)