Skip to content

Instantly share code, notes, and snippets.

@myselfhimself
Last active November 12, 2020 11:35
Show Gist options
  • Save myselfhimself/1eba99d5317190aa04cf65c06d4ebe35 to your computer and use it in GitHub Desktop.
Save myselfhimself/1eba99d5317190aa04cf65c06d4ebe35 to your computer and use it in GitHub Desktop.
About G'MIC's "fx_" and "_" prefixed filters or commands

About G'MIC's fx_ and _ prefixed filters or commands, and GUI-oriented commands in general

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

TL;DR

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.

About fx_-prefixed commands (and G'MIC GUI commands in general)

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:

  1. 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 wraps stylize), having thus a different parameters signature and slightly more complicated inner workings (dealing with layers etc..)
  2. 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.

About _-prefixed commands.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment