Release of G'MIC 2.2.0



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 ,


Minor typo cont.


  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 |

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


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.


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


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 :


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 !


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:

  <code here>

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.

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



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: