Looks like you have figured it out. I see the change. Thanks!
Yes, finally <span style="margin-left:-1.5em"> did the job !
What do you think about two convenience commands/macros to replace the usual loop over the image stack?
-repeat $! -l[$>]
<code here>
-endl -done
I know we can define our own but for the sake of giving examples it could improve clarity if they’re already available, maybe something like:
repeat_all
<code here>
done_all
One downside is that it may then be confusing for anything other than all images in the stack.
That might be useful since it is a common thing to do. Thoughts:
– Sometimes direction matters; i.e., l[$<].
– Maybe a better name; e.g., repeat_images ... done_images.
– local ... endlocal isn’t always necessary but people might abuse this new command out of convenience.
Actually, no, this is not possible for a user to define a repeat_all command that would behave like that. The reason is that when exiting a command, the scope must be the same as when one enters it, which is basically not possible for this particular case.
I’m not a big fan of having several native commands used to do the same things, anyway.
I have to think about this a bit more 
New update seems to work fine, thank you
One question and one little thing:
Question; The Transfer colors [advanced] filter never did work with bigger images (for me, I blamed it on my PC). I always had a result that in some way resembled this :
image from this post:[Feature Request] FFT denoise - #18 by Magnade
But without the saturated colors. Is it possible the last update fixed this also? Because now it works.
One little thing:
Using Color>Curves with CMYK with transparancy layer gives an error (this error already existed before update).
Without transparancy layer this filter does work (CMYK without alpha).
When I have a transparancy layer, the window for the Alpha curve will not close when done. When I also close this alpha window, I have this error:
*** Error in ./fx_curves_interactive/*if/x_color_curves/*repeat/*local/*repeat/function1d/*local/ *** Command 'a': Invalid selection [2--1] (contains indice '2', not in range -2...1).
Yes, definitely, a bug has been fixed in the guided smoothing algorithm, which is used by the color transfer filter.
I get it too, I’ll try to fix this ASAP.
Thanks for reporting!
1 Like
This has been fixed in the filter updates. Refresh your filters and it should be OK
1 Like
@David_Tschumperle Interactive crop crops per image whereas normal crop crops everything in the buffer if we don’t specify a selector. Could you fix that? I usually want to interactively crop everything using the same coordinates. I understand that the images may be different in content and dimensions but it would be great if the behaviours are more consistent. Thanks.
This is a consistent behavior : crop without arguments lets the user crop the image selection interactively, so crop[img] will let him do that for one image, and crop[selection] will let him crop interactively all images of a selection.
As you say, images may have different sizes and using a single set of user-selected crop coordinates for all images is a nonsense (or at least not a generic enough behavior, i.e. limited to selections where images have all the same size).
Now, good news, the specific case you are talking about can be easily solved by this:
my_crop:
if {!$!} return fi
+select[0] 2 coords={^} rm. # Interactively crop first image of the selection, and remember crop coordinates
z $coords # Use the same crop coordinates for all images, then.
Then:
$ gmic sp tiger +mirror x +mirror y my_crop
A. Another behaviour thing. Compare the zooming of
gmic sp tiger and gmic sp tiger +b 5 a z
In the first case, it is click(hold)+drag+release.
In the second case, it is click(hold)+drag+release +click. Also, if I click but don’t hold the first time, a box is generated giving the illusion that zoom is possible. This doesn’t happen in the first case.
B. Trouble saving GIF (2.2.1).
gmic sp tiger o _.gif
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'tiger' (1 image 750x500x1x3).
[gmic]-1./ Output image [0] as gif file '_.gif' (1 image 750x500x1x3).Invalid Parameter - 100
'gm.exe' is not recognized as an internal or external command,
operable program or batch file.
[gmic]-1./ *** Error *** [instance(750,500,1,3,000000000c976040,non-shared)] gmic<float>::save_other(): Failed to save file '_.gif'. Format is not natively supported, and no external commands succeeded.
gmic sp tiger +b 5 o _.gif,1
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'tiger' (1 image 750x500x1x3).
[gmic]-1./ Blur image [0] with standard deviation 5, neumann boundary conditions and quasi-gaussian kernel.
[gmic]-2./ Output images [0,1] as animated gif file '_.gif', with 1 fps.Invalid Parameter - 100
[gmic]-2./ *** Error *** [instance(2,16,0000000008f25b08)] CImgList<float>::save_gif_external(): Failed to save file '_.gif' with external command 'magick/convert'.
Yes, for the selection I’ll look at it.
For saving/loading .gif files, G’MIC uses an external call to the ImageMagick’s convert tool. This requires then IM to be installed (preferably in the ‘default’ install folder).
Must be something wrong on my end then. I am currently using the portable version of IM. magick and convert are in the same folder but only magick works. Weird.
Didn’t you give G’MIC the ability to detect magick a while back?
No, it’s actually CImg, the image processing library used by G’MIC that search for a valid path to find convert.exe or magick.exe.
Where is this file located for you ?
I’ve made some important changes today to make the selection behavior more consistent.
Let says there are two different selection modes : ‘standard’ and ‘deep’, that concerns only how selections are handled in 3d volumetric images, with the following meanings:
- ‘standard’ selection : the user really wants to select a 3d box, meaning he has to select two rectangles, in a least two of the three views XY,YZ and XZ.
- ‘simplified’ selection : the user wants only to select a rectangle in one view, then the selection is composed of all these rectangles along the dimensions of the other view. For instance, selecting a rectangle in the XY view, and the selection has the maximum depth possible (all slices of the volumetric image).
When doing a selection, the left CTRL key acts as a modifier to select the non-default selection mode for a given command.
Defaults selection modes are defined differently, depending on the command you run:
- Commands
display: default selection mode is set to 'simplified’, as it appears that it is easier and faster to use to explore image data. - Commands
selectandcrop(w/o arguments) : default selection mode is set to ‘standard’, as selecting/cropping rectangular regions in 3d volumetric images should naturally allow the more flexibility for these commands.
Note that Command select gets a new argument is_deep_selection={ 0 | 1 } that can be used to change the default selection behavior for this command.
Note also that you can always choose between the two selection modes in any command, using the left CTRL key to switch selection behaviors.
I think this will be more practical this way.
It is on another partition but location didn’t matter before as long as I added them to PATH. Again, it might be something wrong on my end because magick works but convert doesn’t. I will try again but at the default location.
PS I installed it at the default location and it works now. However, I would prefer it to be at another one. Would it be possible for me to direct CImg to a different one?
Not if you don’t compile G’MIC by yourself, I’m afraid.
Tant pis. At least I know where the problem lies.
This looks great! Can you install it into GIMP 2.10? I have not been able yet to install g’mic on GIMP 2.9.x releases.
I’ve compiled a new pre-release package for version 2.2.2, available here, with the recent changes I’ve made on the interactive displays.
Feel free to test and report issues (or say it’s fine 
).
1 Like