Release of G'MIC 2.2.0


#21

Excellent!

Minor typo in docs.
#@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]"

:slight_smile:

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 |

[image],_interpolation,_boundary_conditions,_ax,_ay,_az,_ac |
{[image_w] | width>0[%]},_{[image_h] | height>0[%]},_{[image_d] | depth>0[%]},
  _{[image_s] | spectrum>0[%]},_interpolation,_boundary_conditions,_ax,_ay,_az,_ac |
(no arg)

#22

Crash when doing gmic sp tiger hessian yz.


(David Tschumperlé) #23

Confirmed here. I’m investigating…


(David Tschumperlé) #24

Bug fixed with this commit. Thanks for your report ! I’ll build new pre-release packages with the fix, tomorrow.


#25

:thinking: It worked, then it didn’t. Maybe I typed something other than yz the first time…

PS That was the pre release; the stable works. Thanks.


#26

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?

[image],_interpolation,_boundary_conditions,_ax,_ay,_az,_ac |
{[image_w] | width>0[%]},_{[image_h] | height>0[%]},_{[image_d] | depth>0[%]},
  _{[image_s] | spectrum>0[%]},_interpolation,_boundary_conditions,_ax,_ay,_az,_ac |
(no arg)

(David Tschumperlé) #27

I understand that, but in HTML this seems to be a bit hard to manage : https://stackoverflow.com/questions/3477625/is-it-possible-to-indent-wrapped-lines-within-code-blocks-via-css


#28

Looks like you have figured it out. I see the change. Thanks!


(David Tschumperlé) #29

Yes, finally <span style="margin-left:-1.5em"> did the job !


#30

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.


#31

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.


(David Tschumperlé) #32

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 :slight_smile:


#33

@David_Tschumperle

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
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).


(David Tschumperlé) #34

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!


(David Tschumperlé) #35

This has been fixed in the filter updates. Refresh your filters and it should be OK :slight_smile:


#36

@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.


(David Tschumperlé) #37

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

#38

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'.

(David Tschumperlé) #40

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).


#41

:thinking: 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?