As I have been learning G'MIC slowly for more than one year already in order to develop the gmic-py G'MIC Python binding, here is something simple and stupid I wish I knew before.
Here is what David, the creator G'MIC told me about fx_
and _
-prefixed commands. I thought it would be nice to share this knowledge on the Internet :)
If you intend to write solid scripts relying on the gmic
console executable, the C++ libgmic
library or Python gmic-py
, do it with filters whose behaviour do not change, especially no the fx_
or gimp_
ones, or most of what you see in the GIMP G'MIC plug'in's verbose output. Do to so, avoid the GUI filters, focus on the commands and filters listed on the G'MIC Reference page...
Otherwise shut down the internet and prevent G'MIC from updating itself through the gmic up
command which gets run for you from time to time :)
Commands preceded by a _
are internal commands, you should avoid calling them.
fx_
-prefixed commands such as fx_stylize
, fx_bokeh
, come from the G'MIC community filters on Github where anyone can make a pull request, have it included quickly and then make it available through the gmic up
(or gmic update
) command.
fx_
commands have two special traits:
- they are meant for GUI (graphical user interface) use mostly (eg. for G'MIC, Krita etc.. plugins) and wrap non-GUI-oriented commands most of the time (eg.
fx_stylize
wrapsstylize
), having thus a different parameters signature and slightly more complicated inner workings (dealing with layers etc..) - their authors do not care about parameters stability, because the UI of those filters are auto-generated by the G'MIC GUI plugins on start or "update button" time.
On the contrary, non-fx_
filters are meant to have a stable set of parameters across versions.
This year 2010 tutorial by Zonderr on G'MIC Gimp to G'MIC console shows how to tune a console verbosity level through clicks in one of the G'MIC plug-ins graphical user interface.
The console highlighted in the tutorial is [gmic_gimp]./apply/ -v -99 -gimp_mix_rgb 1,0,0,1,0,0,1,0,0,0,2,0
... and clearly shows that the filter in use is GIMP-oriented (or GUI-oriented in my words).
This kind of filter has no agreement of parameter stability with you :)
By chance the G'MIC terminal executable also exposes the same filters so they can be run, gmic-py and all most libgmic wrapper applications (Natron..?) may support them as well. If you notice the gmic.eu official online reference, such GUI-oriented or non-core community-contributed filters are not listed or documented there on purpose, because they can change anytime!!!
You are always free to use any filter provided by the G'MIC executable, now you will know why you might get non-consistent results when using GUI-oriented filters.
Commands preceded by _
are internal commands, and you should avoid calling them, they may change or disappear in any G'MIC version or contributed scripts which G'MIC downloads through updates.
Example: A famous internal command, famous on the internet nowadays is _fx_stylize <some painter's artwork name>
to load say a Mona Lisa before, akin to the non-internal sample
or sp
command. This command helps you have a painting's image within your input buffers before running the fx_stylize
GUI command, which needs 2 input images at least.
A stable alternative would be to use your own image and the input
command or sample
command.