#@cli shape_gear : _size>=0,_nb_teeth>0,0<=_height_teeth<=100,0<=_offset_teeth<=100,0<=_inner_radius<=100
#@cli : Input a 2d gear binary shape with specified size.
#@cli : Default value: 'size=512', 'nb_teeth=12', 'height_teeth=20', 'offset_teeth=0' and 'inner_radius=40'.
#@cli : $ shape_heart ,
shape_heart
Minor typo cont.
shape_gear
nm "[2d heart shape]"
Indentation in docs.
It would be nice if the html followed the indentation of the stdlib; e.g., under resize. It makes it easier to figure out that the second | is actually inside the brackets { } and not separating two different parameter formats every time there is a wrap. Perhaps make it even more obvious by highlighting each version separately, instead of separating by |…
I noticed that indentation changed (increased) in the docs but what it is now wasn’t what I was pointing out. Now in the docs and in command line, everything has been oddly shifted to the right.
What I would like is a differentiation of a new line or and a soft wrap. In my earlier example, in the CLI, the third line is actually a wrap from the second, and the indent aptly indicates that. However, in the docs, this small detail doesn’t show, making it confusing for the reader. Does that make more sense now?
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
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 :
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).
@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.
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?
It worked, then it didn’t. Maybe I typed something other than 
Must be something wrong on my end then. I am currently using the portable version of IM.