Hello.
I’d like to talk about a slight change that will appear with the command name in the next version 3.0.3 of G’MIC. Technically speaking, the three following changes will apply:
Command name, which already has the shortcut (nm), gets a new shortcut (::).
When no image selection is specified when invoking name, the selection is not considered to be “all the images of the list” anymore, but “the N latest images of the list”, where N is the number of arguments passed to the name command.
When invoked, command name now checks that the number of specified arguments is always less (or equal) than the number of images in the selection.
This probably won’t break anything in the existing G’MIC scripts, because most of the time, a selection is specified when invoking command name.
On the other hand, these new rules allow to introduce a quite cool syntax, that will hopefully encourage a good programming practice: working with named images as much as possible!
With the version 3.0.3, for instance, it will be possible to write something like this:
foo :
file.jpg :: in # Eq. to `name[-1] in`
+blur[in] 3 :: out
fill[out] "avg(I)<128:[R,G,B]:[B#$in,G#$in,R#$in])"
Note that :: can be also used to assign multiple names to several images, so:
foo :
sp colorful
file1.jpg file2.jpg file3.jpg :: img1,img2,img3 # Only name the 3 last images!
blur[img1,img2,img3] 10
Seems good to me, I don’t think I’ve ever used name on more than one image except by mistake. The new shortcut is fine too, a bit of code formatting helps as you suggest.
I find myself using named images more often now anyway - it avoids a lot of annoying bugs due to the image stack management. It’s surprisingly difficult to hold which image is which in your head, just by numbers!
I’ve also another plan that will be really useful, and may lead to G’MIC 3.1.0 rather than 3.0.3 :
EDIT: Replaced with foreach
I’d like to make a command foreach that acts like an iterator applied on each image of its selection, a bit like the classical repeat $! l[$>] ... endl done pattern. This is not implemented yet!
As it seems to be not trivial to implement, I prefer to get your feedback before actually implementing it
So the idea would be to allows something like this:
foo :
foreach # Same as 'foreach[0--1]' or 'foreach[^]'
+blur 10 -- n 0,255
done
foreach is probably better, as the usual for takes one argument, and this new command won’t.
Plus, the fact foreach without selection will be possible to loop over all images of the list.
A little less number of characters while being concise is fine by me. I just realized that there needs to be a direction modifier. I have used repeat l[$<] endl done before.
That is just to avoid processing on the wrong images.
Sometimes, referring to images by numbers is natural. For example, when processing frames of an animation, or levels of a pyramid.
Sometimes, referring to images by name is more natural. For example, images in a list may have the role of background, foreground, mask, equalized, and so on. In these cases, “working with named images as much as possible” is good.
I am less convinced that synonyms in the language is a good thing. When “name” and “nm” and “::” mean exactly the same thing, people who write or read scripts in that language need to know all three versions. This is a burden on users. (It is also a burden on programs that read the scripts, but I don’t care about that.)
As a more general and radical point, I suggest that the concept of an image list is similar to numbering/naming. It is natural for animation frames and pyramid levels, and unnatural when the images have different roles (foreground, background, etc). This leads me to suspect that an image-processing language should enable each image to be either within a list, or in a standalone named role. Put it another way: the language enables multiple named lists, and a list can contain only one image. (Arguably, a list can contain no images at all.)
This may allow complex operations to be expressed simply, for example blur the list of animation-frames, then for each result make some specified colours transparent, then composite the results over a single background, then composite a single foreground over the results.
In fact, I’ve already discarded shortcut nm from the interpreter, so shortcut of name will be ::. But, I’ve still kept nm as a (undocumented) custom command so that any previous code using nm keeps a perfect compatibility.
In G’MIC, that’s the role of selections. All images are in the same list, but you can always select a sublist for all commands applied, so it’s quite easy to deal with something similar to multiple lists :
foo :
list1=0-3 # The 3 first images
list2=^$list1 # All the other images
blur[$list1] 10 # Blur only images from 'list1'
reverse[$list2] # Reverse order of images from 'list2'
Ah, yes, selections. Is there a fundamental difference between a named image, and a named selection of one or more images? Are both structures needed? Feel free to point me to documentation.
A selection is basically defined either as a list of images indices or names, e.g. 0-3 and img1,img2,img3.
But there are a few more syntaxes available that make them very flexible to work with
(a bit like when have a PDF document, and you can specify which pages you want to print).
