I have been slowly developing experimental filters with multiple components. It is really hard to keep track of all of the sub-images. Being able to store them not only makes the code more accessible but it would probably reduce the amount of time lost to keeping track of which images I removed, which ones I kept and which ones I renamed. And finally, which ones I may need at the end of an extremely long multi-command filter. Just talking about it is laborious!
I hope the performance hit isn’t too much for these native commands.
I’ve worked a bit this week end and today, to improve the new commands store and restore.
Here is the current help they display:
Command store:
store (+):
variable_name1,_variable_name2,...
Store selected images into one or several named variables.
Selected images are transferred to the variables, and are so removed from the image list.
(except if the prepended variant of the command '+store[selection]' is used).
If a single variable name is specified, all images of the selection are assigned
to the named variable. Otherwise, there must be as many variable names as images
in the selection, and each selected image is assigned to each specified named variable.
Use command 'restore' to get the stored images back in the list.
Example: [#1] sample eagle,earth store img1,img2 \
restore img2,img1
Command restore:
restore (+):
variable_name1,_variable_name2,...
Restore images previously stored in the specified named variables, and insert them at the end
of the image list. Note that restoring image data does not remove the data from
the corresponding named variable (use 'variable_name=' to explicitely delete a variable content).
I’ve made some work to optimize the assignment of image-encoded variables, so the speed is quite acceptable right now.
Also, the copy operator is now functional, so you can assign an image-based variable to another variable if necessary.
In a few minutes, the pre-release version 2.7.2 will be updated with new binary packages on the G’MIC website. Let me know if you have the occasion to test this new feature!
Just a thought: wondering if it would be good to use store and restore. Although in English it means “to bring back” or “recover”, it could be confusing for nonnative speakers for store to be in both command names. Could be taken as “re-store”, as in “store again”. Since I used the word recover, maybe that could the name… or maybe retrieve. Thoughts?
I like the idea of having similar names for both commands, as both commands clearly work together. As a non-english speaker, I think it really helps remembering their names.
Well, what I see from the Merriam-Webster dictionnary is :
Store : to place or leave in a location (such as a warehouse, library, or computer memory) for preservation or later use or disposal
Restore: to bring back to or put back into a former or original state
My understanding of that is we cannot be more close to what these commands does in G’MIC store has indeed the meaning of moving something in another place (so here, an image, from the image list to a variable), and restore brings the image back.
Just for info : Today, I’ve implemented the store and restore commands, as custom commands in the stdlib.
As a result, scripts using these commands (introduced natively in 2.7.2) should work also with previous versions 2.7.0 and 2.7.1 of G’MIC (they will just be a little slower though).
So, do not hesitate to use store and restore commands in your scripts already !
Commands img2var and var2img have been moved to my personal update file david_tschumperle.gmic, to ensure the recent scripts from @Reptorian continue to work (but if you can replace their use with store and restore, it would be better). Not sure how long they will stay there.
There are anyway small differences between the native and custom versions of store and restore. I don’t think that’s going to be a problem, though.
Yes, that’s it.
Native versions of store and restore are basically there is you are using G’MIC 2.7.2.
Before that version, the limited custom versions of these commands applies.
I just have one issue with store and restore. I really don’t want to see this in preview when using code[local]. The command is basically for reverse engineering gradient map.
Looks like he has found the same limitation as you did with the custom versions of store and restore. @Reptorian, are you running latest version 2.7.2 of the plug-in ?
So that’s probably one pre-release that didn’t contain the native versions of the store and restore commands. Try updating to latest stable version instead, it should work better.