In theory, such a syntax would not be a bad idea. In practice, however, it could be. So I’m not sure I want to propose it yet.
My main concern comes from the way the
store command is designed to be used. A stored image (or list of images) is saved in memory in a serialized form (which does not compress the image list, but at least re-encode it as a linear buffer of bytes). So “de-serializing” it (with
input $imgs) has a quite significant algorithmic cost.
So, allowing a syntax as
input $imgs would mean the entire list of images is de-serialized each time, just to return a single image. So in the current settings, this would be always quite slow, and a bad coding practice to allow this.
Two perspectives then:
- We don’t allow this, and recommend that if the user wants to access a single image in a stored list, then it’s better to store all images of the list as independent variables, with
sp lena,duck,earth store img0,img1,img2 ... $img1
This is in fact what you can already do with the current version of G’MIC.
If you really want to keep a single variable, then:
sp lena,duck,eart store imgs ... l $imgs k endl
will work too.
- We allow this in the future, but this means all the
store mechanism should be redesigned internally first, to make it more suitable to be used in this context. Not sure it’s worth it, if an alternative solution as above can be always used.