While I was looking for a way to solve my tiled shape filter, I realized I need to be able to copy image into variable. Something like this.
var=[0]
. f. 0
l. $var rm.. endl
Result is the same as only a dot. The two images are the same.
Your command is the same as
gmic sample tiger . fill. 0 local. [0] remove.. endlocal
I added sample tiger.
1 Input a sample image called tiger.
2 Make a copy of the last image in the buffer (tiger) and input it at the end of the buffer.
3 Fill this last image with 0s.
4 Within a local...endlocal block, take the last image, add a copy of itself to the end and then remove the original copy of it within the block.
Result
Nothing happens to the original tiger. Its copy gets filled by 0s. Then this image gets isolated by itself. It gets copied once and then gets removed. The block ends with a copy of the image that was filled with 0s. So, we get the original tiger and an image with the same dimensions but filled with 0s.
I know it result into that, but that’s not the point. While I’m trying to copy image into variable. I get these things
1 Memory leak
2 0s in value or dimension
3 70+ channels with right ranges
Nothing I tried with gmic manual works
The type of G’MIC variables in G’MIC are text strings. It cannot be of another type.
If the image you want to store in a variable is small enough, you may try something as:
+serialize[0] img={^} rm. # Store a compressed version of the image as a list of numbers.
rm
($img) unserialize. # Get image back.
But for large images, this is not really optimal. In this case, you have to manage the list carefully.
Anyway, the possibility of storing images in variables can be interesting, I’ll think about it.
There may be already a way to deal with that, hopefully, with a few tricks.
OK, so I’ve added two new commands in the stdlib, namely img2var and var2img, which should ease storing image data into variables.
These commands are quite straightforward to use:
foo :
sample lena
img2var[0] this_is_lena
remove
(...)
# I need 'lena' here!
var2img this_is_lena
Note that the current implementation of these command use a base64 encoding to store image data, meaning it takes 1/3 more than the image size to store, but I think this is acceptable.
This may be more optimized in future versions.
Let me know if that works for you, and if you find it useful!
PS : Two more things to say:
-
img2varis also able to store a list of images in a single variable name. - These two commands should be available just after a
$ gmic update.
2 Likes
I been able to complete my rep_form_pixel all thanks to this change @David_Tschumperle. Thank you so much!
2 Likes