On the road to 3.0

Not at all. sort allows to sort image values according to a certain axis, ans this has been proved to be very useful in some of the stdlib commands.

Perhaps I forgot the behaviour. Does sort y smartly recognize that y isn’t for _ordering?

_ordering={ + | - },_axis={ x | y | z | c }

The ordering argument is optional, that’s why sort y is valid.
I could force the ordering argument to be present though, to avoid this issue. Not sure if it’s good or not.

You might use ImageMagick for that, and even call IM through G’MIC’s exec command. True, this means (a) having to learn both systems and (b) a performance hit, as images must be transferred by writing and reading files. But it works. For example, this Windows BAT command:

%GMIC% ^
  toes.png ^
  snibgo_imcaption ^
hello\ world,^
-background\ None\ -fill\ Yellow\ -font\ Calibri ^
  %TEMP%\gmicst_tmp.png ^
  normalize 0,255 ^
  to_rgba ^
  blend alpha ^
  output gmicst_hw2.png

… where snibgo_imcaption is …

snibgo_imcaption :
  skip "${3=}"
  if narg("$3") STR={/"$3"} fi
  skip "${4=}"
  if narg("$4") OUTFIL={/"$4"} fi
  skip "${5=}"
  if narg("$5") PREOPT={/"$5"} fi
  echo_stdout STR:$STR
  cmd=magick\ -size\ ${WW}x${HH}\ $PREOPT\ caption:\"$STR\"\ $OUTFIL
  echo_stdout $cmd
  exec $cmd

… makes this image:

Now that makes me want to try imagemagick at some point. Adds it to mental TODO

@snibgo Thanks. I roughly know how to do it. It is just that I prefer not to provide a public command that does that because the user would then be responsible for installing IM (or GM) and adding it to the path.

@Reptorian: My mental todo list keeps growing. It includes publishing a page that compares and contrasts IM with GMIC. They have some fundamental differences that confused me until I understood them.

@afre: Yes, using both systems in one application is klunky. But there will always be times when one system provides facilities the other doesn’t.

I haven’t looked at GMIC source code, but I think it includes a version of IM, perhaps for reading/writing image files of various formats. If so, perhaps GMIC could provide a command that called its internal IM, passing images in-memory.

A few words about the use of IM in G’MIC. I’ve read several times (not here fortunately), that G’MIC code is based on IM, which is patently untrue:

  • G’MIC doesn’t use IM for reading/writing common image file formats (JPEG, PNG, TIF, BMP, …). G’MIC is not even linked with the Magick++ library.
  • Only in rare cases, G’MIC calls a fallback function that may use IM (but also GraphicsMagick if IM is not installed), when an image file couldn’t be read (or written) with the native functions of the CImg library (which is the base image processing library used in the code of G’MIC). This fallback function just tries to do an exec() with IM (or GM) to convert data in a proper format in /tmp/ before reading it with CImg. This fallback function is called for instance if you try to read an animated .gif or a .pdf file with G’MIC.
  • Except to handle these very special cases, there are no other places where IM is used, in the G’MIC code.

Of course, G’MIC has been partially inspired by IM for some of its features, but it has a totally different scripting philosophy, and is more focused on the image processing itself than on the conversion between image formats. I can only advise to use these two pieces of software together :slight_smile:


Thanks for the clarification, David.

In my view, G’MIC and IM are two different systems with some similarities. I would love both systems to have all the facilities of the other, but I doubt that will ever be the case. For a workflow that needs both systems, it makes more sense to separate the functions so each system is called from a common script as required. But IM can be called from G’MIC, if we want.

In the other direction, IM has no equivalent to G’MIC’s exec, so I added one as a process module, so IM can call G’MIC:

magick xc: -process 'shell "gmic toes.png blur 3 output x.png"' x.png info:

R% in circle isn’t practical because anything ≥50% covers the whole image.

Not true, if the circle center is not located at the center of the image:

gmic 300,300 circle 0,0,50%,1,255


When used with R% the radius is actually computed as

\text{radius} = \frac{R}{100}*\sqrt{\text{width}^2 + \text{height}^2}

(that’s why the circle outline passes through the image center in the example above).

Just a request here. On erode commands, is it possible to add variants that disable computation of erodes on all area with 0 or less? Like erode_circ0 which is the erode_circ equilvalent of shapemax0.

Minor bug in GMIC 2.9.1. Not sure about pre.

First line of command doesn’t require a colon; however, help doesn’t work without it when it is only located in user.gmic but not in updateXXX.gmic (i.e. stdlib or community).

Could you exhibit an example. I can’t reproduce this behavior.

Cut the following from updateXXX.gmic and paste it into user.gmic.

#@cli gradient_norm
#@cli : Compute gradient norm of selected images.
#@cli : $ image.jpg gradient_norm equalize
#@cli : $$
gradient_norm :
e[^-1] "Compute gradient norm of image$?."
repeat $! l[$>] g sqr s c + sqrt endl done

help will display:

[gmic] Command 'gradient_norm' has no description; did you mean 'jr_gradient_norm' ?). Try 'gmic -h' for global help.

Hum, it works for me, with 2.9.2_pre.

Something happened to the website’s background. Now it is hard to read the text.

Gimp 2.10.20 kubuntu 18.04 - I see some new G’mic code for 2.9.2_pre so a compile this morning.

Interactive color curves Lab and Lch give this ?

Is this my installation or is it a bug ?

It’s a bug. I’m investigating…
Thanks for the report !!

Bug fixed:

I’ll update the sources of the pre-release packages for 2.9.2, on the website.
Thanks again @rich2005 !

1 Like