It’s not a change, it’s an addition. nm will continue to work.
So name has two shortcuts with slightly different functions in G’MIC 3.0.3? Please clarify.
No all shortcuts behave the same.
Okay, they mean the same thing; only that 3.0.3 changes the behaviour. Is this correct?
Yes, it is a slight change, basically only when name was called without a selection (so, nm something).
I am just puzzled by the additional :: shortcut. You are saying that :: isn’t replacing nm. Maybe I am not getting enough sleep. Ha ha.
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!
1 Like
Indeed! I think I succeed doing it up to 5 images, but after that, it is just too much for me 
1 Like
I’m accustomed to thinking of images by numbers. I rarely ever use name. I do like the :: better than nm to be honest.
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
that would be equivalent to:
foo :
repeat $! l[$>]
+blur 10 -- n 0,255
endl done
What do you think?
2 Likes
Yes please, sooner the better! I do get tired of the usual construct…
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).
Reference page about selections : G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Command Items and Selections
This was what I wanted to know at the top of the thread. It is clear to me what the changes are now.
foreach … done is comme ci comme ça. Shortens the code but I usually do complex stuff, including repeat $!-1 l[$<] ... endl done and commands and selections between the repeat and local and endl and done.
Yes, indeed sometimes the usual repeat..done construct will be more adapted.
It’s just a proposal for another construct that will simplify maybe 80% of the commands in stdlib