Sorry, this is probably easy and I know I’ve read it somewhere in the past, but yesterday I spent half an hour browsing through the webs and couldn’t find the answer.
So, I have a filter which creates three new layers, which then appear in GIMP (for further use). How can make Gmic name those layers??
Indeed, it’s easy, but not well documented at this time.
Using command -name in a G’MIC script allows to set the corresponding GIMP layer name, but also the blending mode, opacity and position, if necessary.
Something like this :
Some additional information : you may want also to retrieve the layer name, blending mode and position in a filter (for instance to name your output layers by adding text to the original layer name).
These info can be retrieved with commands -gui_layer_name, -gui_layer_mode, -gui_layer_opacity and -gui_layer_pos.
For instance, the following filter divides all input layers opacity by 2 and rename them accordingly :
Note that this ‘feature’ is specific to the plug-in for GIMP (and should also work for Krita), as these software can manage blending mode, opacities, and layer positions. It is a bit a hack, as we are using G’MIC image names to pass these information
Maybe some remaining useful things to know :
Command -gui_merge_layers is able to do render the one-layer blended images from all the named layers on the image stack.
Commands -gui_set_layer_name, -gui_set_layer_mode, -gui_set_layer_opacity and -gui_set_layer_pos can be also used to set only one of the desired feature, without changing the others.
Within gmic proper, it is easy to fall into the habit of thinking that -name labels images; I find myself lapsing into that manner of thinking myself, but to make a habit of such lapses is to miss out on a good deal of the versatility of -name. In fact, -name labels selections. Now, selections can entail just one image and many uses of -name entail single image selections, but interesting trickery awaits those who recall this subtle distinction that labeling selections is the game of a name:
gmic \
-input 120,240,18,3 \
-split. z \
-name[0--1:3] Blue \
-name[1--1:3] White \
-name[2--1:3] Red \
-fill_color[Red] 357,0.9,0.45 \
-fill_color[Blue] 230,0.9,0.35 \
-fill_color[White] 90,0.7,0.95 \
-hsl2rgb[Red,White,Blue] \
-append x \
-output. frenchflags.png
A named selection groups images into a particular class, and I may select that class without worrying where on the image list the members are, saving me tedious index arithmetic. Perhaps I wish to perform a few actions on just the white images. -local[White] -noise 0.2,2 -bandpass 0.008,0.02 -normalize 0,255 -endlocal, inserted just before -append x blottifies just the white panels.
Indeed Garry !
Anyway, we have to precise that using names for applying commands on selections also require the names to be constrained to variable names (i.e. composed only of characters [a-zA-Z0-9_] and not starting by a number).
This is not the case with layer name that come from GIMP
Indeed, -name allows me to keep track of the images and access them when required. Very handy. Still need to be mindful of the order of images though and know when to move or reverse them.
I personally found that setting image names with labels avoids the need to remember the position of each image in the image list. With a list of labelled images, in which particular case do you have still to worry about the image order ?
I’m interested.
I see. That is indeed a case where it is not recommended to use the merging version of the arithmetic operators.
Instead of ---[tiger,lena], you should write ---[tiger] [lena], so that you don’t have to care about the image ordering.
Definitely, that is why it was a silly example. Maybe blending might be a better one or some others where it is a part of the syntax. I will keep that in mind when writing my own commands.
The -blend command also has a non-merging mode, e.g. -blend[base] [layer],overlay
I think this is also true for most of the command (e.g. -append has one too).
Great page, as always!
Garry, one thing should be corrected anyway. When you write
The name may be composed of characters from the class [a-zA-Z0-9_], but cannot begin with a numeric
That is not completely true. You can associate any name you want with an image, e.g. -name "my name is 'Luka'" is correct. But if you don’t name your image like a variable name, you won’t be able to refer to it in selections afterwards, so e.g. -blur[my name is 'Luka'] 4 is of course not a valid command.
When interacting with the GIMP/Krita plug-in gmic-qt, image names are used to pass layer information (layer opacity, blending mode, layer position) from/to the plug-in to/from the host software, and in this case, input image names are often of the form: name(Layer name), pos(0,0), mode(alpha), opacity(100) which cannot be referenced in a selection. But this is really convenient as a filter can retrieve the layer information easily then, from the image name.
Similarly, if a filter output an image name like this, it can decide which blending mode, position or opacity will be used for the the output layers.
Ah! Thank you for the clarification, David. The page is a bit raw yet, so readers be advised. (David is familiar with the turmoil freshly minted Particular Art pages go through and generally doesn’t fetch them for gmic.eu until a week of settled dust has passed) Probably won’t touch the page until this afternoon (just after midnight, +2, methinks).
I’ve been tracking gmic-community on GitHub. Would you prefer pull requests in the fullness of time? I’ve been making a study of the various PA → gmic transforms which pages undergo, which seem straightforward. Whatever is simpler for you.
I’ve tested here with GIMP 2.8, and it works as expected. Will test with GIMP 2.9 at home, tonight.
The two number are the offset (in px) of the layer, nothing else. You can set negative numbers for instance, if you want your layer to be outside the image canvas.
At least, this seems to work only with the G’MIC-GTK version, and not the Qt-based version! There seems to be a bug to fix then