Here is the updated changelog from version 1.6.7 to 1.6.8:
New features:
[all] Added color conversions from/to YIQ colorspace.
[all] New function init() in math parser, used to do initialization work for the parser (variables, etc…) only once, when multiple evaluations are required.
[all] New command -inpaint_gaussian that implements yet another (fast) inpainting method using simple gaussian interpolation of surrounding pixels.
[all] New command -inpaint_patchmatch which implements a multi-scale inpainting algorithm based on the patchmatch method. This command can be used from the GIMP plug-in as well, with entry Repair / Inpaint [multi-scale].
Improvements:
[all] Commands -cut and -threshold run in interactive mode now returns the chosen values into the status.
[all] Improve auto-detection of math expressions that can be safely run in parallel.
[all] New variables interpolation and boundary available in the math parser, to default the corresponding argument values when accessing image pixels.
[all] Reduce stack usage a little bit on Windows.
[cli] When saving animated .gif, the fps argument can now be specified as a float-value (so 0.5 fps = 1 frame every 2 seconds is possible for instance).
The new -select is really a lot more usable, thanks
I have just found a bug in the GIMP plugin, AFAICT. It’s fairly simple: essentially, strings like (200ms) in layer names, when using ‘output:default (replace)’, get the () changed to [].
Since the notation (200ms) is used by GIMP’s animation system (as well as ‘(combine)’ or ‘(replace)’, this effectively stops the animation from working after processing it with GMIC.
The bug appears to apply to anything in ()'s. A simple test case is to create a new image, and rename the layer to ‘foo (bar)’. After running GMIC, the layer name reads ‘foo [bar]’.
I haven’t had a chance to recompile GMIC yet – I’ll make sure to check, once I get the time – but I noticed another bug, related to Color Balance. The preview can be extremely inaccurate.
For example, take this image: http://i.imgur.com/UwlDkoA.png and apply Color Balance with neutral color #321913 . The preview suggests a bronzy reddish result, but actually applying the filter leads to a very green result.
Alternatively you could use neutral color #3EA1D0; in this case the preview appears to be a plain ‘colorized sky blue’ result. But the final result is a dark blue to bright yellow set of colors, with much more contrast than that shown in the preview.
Checking or unchecking ‘stretch colors’ does not affect the bug significantly either way.
EDIT: The preview for ‘color grading’ also seems to be very inaccurate, with settings that look like they have a strong darkening + smoothing effect resulting in only a minor brightening of the picture.
The details equalizer is magnifique…, but there is a problem with the preview. It only works when you have the complete zoomed out picture in the preview window. (that is not the normal zoomed-in preview). I want to use this filter with the normal preview. So that I get what I see. I like the normal zoomed-in preview because then I can see the details. If I now use the normal preview that G’mic gives me for this filter, the results don’t match with what I did in the preview.
So the warning for the inaccurate zoomfactor is also wrong.
I hope you can fix this, because it is a very special filter that is sometimes better then other deconvolution methods I use.
Thanks David, Color Balance indeed appears to be fixed. Color grading appears to be the same as before (ie. preview differs a lot from result)… perhaps you read my message before the edit.
Yes I hadn’t seen your edit. Actually, the color grading filter has been implemented by John Lakkas, and I don’t know if his code can be easily fixed so that the preview matches the final result.
Writing a filter that has a precise preview often requires special attentions. This is definitely not an easy task. I’ll let John manage his own filter sources, as I already manage mine (more than 300 ), and as you can imagine, this is already a lot of work!
I’ll write him a mail about this problem.
Use the Filters->Repeat last command ( I remember it has having shortcut F2 but may be wrong – I have customized my GIMP shortcuts.)
The filter is correctly re-applied (first re-application)
Use the Filters->Repeat last command, again.
the ‘gmic’ progress bar comes up, but the filter is not reapplied (second re-application)
My best guess at the cause of this, is that GMIC is resetting its stored data about the last command that was run – perhaps to the command that is being used to do the repetition?
Some filters destroy the current selection, for no apparent reason. For example, Local Variance Normalization, Freaky Details, Mighty details, Portrait Retouching, Sharpen [deblur, gold-meinel, inverse diffusion], Simple Local Contrast, Spotify, Texture Enhance…
These particular filters also demonstrate another undesirable effect: when an area is selected, the output image is changed to the rectangular bounds of the image. I can understand if that is complicated to manage, I just thought that in these conditions:
Input layers is set to default / ‘active’.
output mode is set to default / ‘replace’
There is an active selection
A filter outputs one image that is smaller than the source image, but matches exactly the size of the selection bounds
Then some kind of generic, filter-agnostic handling might be possible (blend the output image onto the active layer according to the selection mask, with the upper-left corner of the output positioned at the upper-left corner of the selection bound; and of course, preserve the selection mask.)
Since there are actually quite a few filters having this type of problem, a solution that would work for most of them would be a big help.
A simple test case:
load a photo
use Ellipse select to select a small area in the middle of the photo that you want to modify.
Apply one of the above filters
Only the area of the image containing that ellipse is now shown; and the elliptical selection has been removed.
I am using Gimp 2.8. I wish I could use GMIC on GIMP 2.9! But all I have gotten from my attempts to compile GMIC for 2.9 is crashes (and GIMP 2.9 has other serious problems such as tablet input not working at all if it’s using evdev driver, so I prefer to ignore 2.9 for now.)
Anyway that’s an aside expressing my frustration;)
To be precise:
GIMP 2.8.15 (installed Aug 14, 1:19pm. Probably commit 597fae39b4911b6e6e201e711f6de86cb6548f10)
Running on Arch Linux x86_64
Development version of GMIC – installed Nov 12, 10:24am, so, I guess, either commit b3663db348f8fab2f9a824b059b8125879205895 or commit 4c50c1ae9bfa09a919c0899c362742d129c5b3ca
I’ll try updating my builds of both GIMP and GMIC, and report back. I should mention that this particular issue has affected me for basically the entire time I’ve used GMIC ever, so it’s not a new issue, I just finally decided to report it.
EDIT: Ah, I reproduced the behaviour you are showing. You are working on an RGB image. Indeed, with an RGB image there is no problem. Try converting the image to Grayscale mode (Image->Mode->Grayscale) before you run the filter.
