If I remember correctly, move has a quirk moving the last item. I made a command to deal with that, but I do not know if it still works after so many G’MIC updates. (Just a quick response, so may not be completely helpful.)
Yes, you need to ‘revert’ the effect, as you say. And the bad news is that you cannot do that ine one go, but use an explicit loop to do this. Something as:
foo :
1x12 => A,B,C,D,E,F,G,H,I,INT,INT,INT
repeat 3 { mv[-{1+$<}] {4*$>+3} }
Best i can do for now is this :
INT:=round(($!-1)/3)
repeat $INT {
place:=$INT*($>+1)
if $place<=$! [BG] =>. INT mv. $place fi
}
That’s fine. But it looks quite complex. i don’t know it move or sort_list could be modified to allow a syntax like sort_list -5,-1,%3 or something like that? Where the command would be applied to the whole list minus the range from -5–1 and would place 1 image from -5–1 (the last one i guess) every 3 images? Maybe i’m just overcomplicating things lol
Or something that would interleave 2 images selections/list with a given offset?
Just throwing ideas in the air cause i know i can’t do it 
Ah forget it, i just give up on this, the more i do it the worse it gets.
David’s solution seems to work. I modified it so you can do steps:
foo:
1x12 => A,B,C,D,E,F,G,H,I,INT,INT,INT
repeat 3 { mv[-{1+$<}] {($1+1)*$>+$1} }
And my test:
C:\Windows\System32>gmic foo 3 echo ${lof\ n} rm
[gmic]./ Start G'MIC interpreter (v.3.3.6).
A,B,C,INT,D,E,F,INT,G,H,I,INT
[gmic]./ Remove images [0,1,2,(...),9,10,11] (0 images left).
[gmic]./ End G'MIC interpreter.
lof returns a list of specified features along images. n is name, so you can see names here.
Your code can use this:
foo: repeat $1 { mv[-{1+$<}] {($2+1)*$>+$2} } # $1 = number of times. $2 = step size.
Also, I would look into different solution. I almost never need to use move in arbitrary order. Actually, literally never now that I taken a check at reptorian.gmic.
Also, there could if break rule in case there’s issues or other things.
Wanted to make underwoods faster by generating everything first, so i had to rewrite everything and in a different order, and then use ap. That was working but then i got stuck on this damn list part. Sorting was kinda random, and sometimes i would get ‘out of range’ errors. Just gave up and deleted everything. Thanks anyway.
Well, that happens. Don’t worry though, sometimes working ideas do come later. Some of my changes involved ideas that came after a year in fact. For example, the 11.6x speedup to Lavander Binary Map were the results of two different ideas, and these were replacing vector with binary operation mathematics and lookup table, and I didn’t think of those nor could back then.
I am sure that is what @prawnsushi meant by
It takes a lot of discipline to be familiar enough with G’MIC to be able to do interesting things, not to mention the coding and mathematics chops to make algorithms and optimization work. I only have imagination working for me. 
If you come to a point where you need to manage a large number of images simultaneously in your list, then I strongly advise you to start naming your images with variable names (command name), and refer to them by their name rather than by their position in the list.
By doing this, you can often completely ignore the position of each image in the list when coding, making it much easier to find your way around.
It’s something I do personally (and more and more often, in fact), for example whenever I have more than 4 or 5 images to manage simultaneously.
Yes, I did it this time 
Like this : Tree1,Tree2…up to 100.
Just forgot to name the ambiance frames properly ( they all have the same name). But I think the order is important because I have to blend them With the main image [BG], and the result is different depending on the order ( at least I got some surprises more than once).
The current script is just a big loop so it doesn’t really matter, but if I want to use ap with all this, I’ll have to rock my brain a lot more, not sure it’s worth the 10000 hours I will lose on this.
I usually write scripts “on the fly” and hope that it works.
The idea was to ja or blend the trees on the BG, maybe 2-4 (depending on the total) and then blend one atmosphere frame over all that, then one light_ray , then next trees, atmosphere,LR, etc. Until I run out of trees. Like you would do in Gimp if you were to paint this scene.
I don’t think I can pregenerate the light rays because the trees need to be there already. Not sure I can parallelize this sequence either 
Another general rule that often applies is that if you have the equivalent of more than 20 input images (so potentially large images) at the same time in your list, then you could probably find a cheaper way to do the same thing 
Like drawing stuffs sequentially on the same canvas, or something like this.
Yes, that’s more or less how the current code works. I generate 2 trees for each loop and get rid of them as soon as possible to save memory.
But I have to use light_relief on each tree separately, or they look terrible if I regroup them on a single image ( like they melted together).
I also wanted to make the threading optional via the gui, off by default.
Oh, and optionally output to multiple layers. That explains the image sorting.
1 Like
After awhile, it will be a 1,000 hours. Then 100. Then 10. With experience comes cut-to-the-chase Eureka! moments.
Second @David_Tschumperle 's remark on name. Recall that names label image collections. Collections comprised of single images foster an illusion that names just explicitly tag single images. Look past that illusion, then one could astutely collect together images with particular characteristics into specific collections. Accomplish that aim, then the local command can select on specific collections and perform characteristic-specific operations on the membership. So goes one complexity management technique.
A toy, somewhat contrived, but wished to note that $! also reports the size of a local (and the collection the local selects).
reallyreally: skip ${1=1024},${2=0}
# Make lots of one pixel images that we can classify by color conditions
sz,fog=${1-2}
-input ({u(255)},{u(32)},{u(32)}^{u(32)},{u(255)},{u(32)}^{u(32)},{u(32)},{u(255)})
-permute cyzx
-resize. {$sz},1,1,3,5
-normalize. 0,255
-if $fog
-blur. $fog
-fi
-split x
# Collect together on color condition
-foreach {
-if R>G+B
-name. ReallyRed
-elif G>R+B
-name. ReallyGreen
-elif B>R+G
-name. ReallyBlue
-else
-name. ReallyBland
-fi
}
# Report counts through collection-based
# localities.
-named "ReallyRed"
-if narg(${})
-local[ReallyRed] {
-echo "Really Red: "$!
}
-else
-echo "Nothing Really Red…"
-fi
-named "ReallyGreen"
-if narg(${})
-local[ReallyGreen] {
-echo "Really Green: "$!
}
-else
-echo "Nothing Really Green…"
-fi
-named "ReallyBlue"
-if narg(${})
-local[ReallyBlue] {
-echo "Really Blue: "$!
}
-else
-echo "Nothing Really Blue…"
-fi
-named "ReallyBland"
-if narg(${})
-local[ReallyBland] {
-echo "Really Bland: "$!
}
-else
-echo "Nothing Really Bland…"
-fi
# Clean up
-remove
---
gosgood@bertha ~/git_repositories/gmic-community/tutorial/cheats $ gmic -m reallyreally.gmic reallyreally 1024
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Import commands from file 'reallyreally.gmic', with debug info (1 new, total: 4784).
Really Red: 227
Really Green: 533
Really Blue: 225
Really Bland: 39
[gmic]./ End G'MIC interpreter.
gosgood@bertha ~/git_repositories/gmic-community/tutorial/cheats $ gmic -m reallyreally.gmic reallyreally 512,200
[gmic]./ Start G'MIC interpreter (v.3.3.6).
[gmic]./ Import commands from file 'reallyreally.gmic', with debug info (1 new, total: 4784).
Nothing Really Red…
Really Green: 353
Really Blue: 76
Really Bland: 83
[gmic]./ End G'MIC interpreter.
See also:
Hope this helps.
Thanks, yes, i am aware of this. The reason i use single image selectionshere is that i don’t really want to track where the trees are in the list, and i paste them onto the BG before deleting them. But i don’t think ja will like it if i do ja. [Tree]... if the collections contains 30 images… Not sure what will happen then. Should do a little test maybe. And i do not wish to blindly remove the whole collection either.
Anyway, i’ve done so many modifications here and there that underwoods is really a mess. i see leftovers of this and that everywhere, that still work, but they don’t have any reason to be this way,so i guess i’ll need to rewrite it some day. But i hate to do the same thing again and again lol. I just keep on tweaking it to shave a few milliseconds here and there.
Thats a nice info indeed, sounds very useful.
I don’t know how you all write your scripts, probably you can see the final goal and all the paths leading to it from the start, but i don’t. I’m just running into the labyrinth until i dig a hole into a wall
How come i didn’t get any notification about these messages?
That’s the same for me. I’m already thinking about what i’ll do next. But i probably don’t have the skills yet. Frustrating lol.
I probably will have forgotten about this filter in a year lol. Unless people complain about how slow it is, which is unlikely.
By the time it’ll come, i’d be so old i’d need an assistant to type for me lol
Another idea would be to just write a downscaled preview version, not sure how or if it will work though.
Yeah, happens. You could be me, on the edit or rewrite only mode. I rewritten my bigint2bigbin conversion tool like 7x times, and went from 270 s for 90000 digits to .25 s for 90000 digits. Boring at times, but what keeps me going is the hope that they will be at their best and the most fun to use. More than 10000 lines of codes to go here, and saving the bests for the last.
Yeah i see your point but the problem is i’m just starting, and i already forgot a few things i wanted to do. I have a file full of one-liners (that i write when i’m bored) that could potentially become filters, but that could make me go in all directions and lose my way. I already forgot the whole gingko leaf and circle patterns and stuff that i was doing before this tree thingy. Oups. That was only a small part of it.
Is it possible to avoid this kind of redundancy:
arg0 $rayBL,\
"add","alpha","and","average","blue","burn","darken","difference","divide","dodge",\
"edges","exclusion","freeze","grainextract","grainmerge","green","hardlight","hardmix","hue","interpolation",\
"lchlightness","lighten","lightness","linearburn","linearlight","luminance","multiply","negation","or","overlay",\
"pinlight","red","reflect","saturation","screen","seamless","seamless_mixed","shapeareamax","shapeareamax0",\
"shapeareamin","shapeareamin0","shapeaverage","shapeaverage0","shapemedian","shapemedian0","shapemin","shapemin0",\
"shapemax","shapemax0","shapeprevalent","softburn","softdodge","softlight","stamp","subtract","value","vividlight",\
"xor"
rayBL=${}
arg0 $bgBL,\
"add","alpha","and","average","blue","burn","darken","difference","divide","dodge",\
"edges","exclusion","freeze","grainextract","grainmerge","green","hardlight","hardmix","hue","interpolation",\
"lchlightness","lighten","lightness","linearburn","linearlight","luminance","multiply","negation","or","overlay",\
"pinlight","red","reflect","saturation","screen","seamless","seamless_mixed","shapeareamax","shapeareamax0",\
"shapeareamin","shapeareamin0","shapeaverage","shapeaverage0","shapemedian","shapemedian0","shapemin","shapemin0",\
"shapemax","shapemax0","shapeprevalent","softburn","softdodge","softlight","stamp","subtract","value","vividlight",\
"xor"
bgBL=${}
Maybe put the whole list of modes in a variable? Or it is possible to combine the 2 arg0 calls into one?
PS :
Looks like it fixed a few problems :
No more white dots at the origin of light relief (took some time to tweak BTW)
Disabled light relief for half the trees (No need for those in the back, right? Might add this as an option)
And finally, downscaled the preview (note the checkbox):
Tree shapes and rays are slightly different but that’s ok for now i guess? Might be too much blur in the BG too.
Yes. What you can do is this:
list_of_blending_modes=add,alpha,and,average,burn,darken,difference,divide,dodge,exclusion,freeze,grainextract,grainmerge,hardlight,hardmix,interpolation,lighten,linearburn,linearlight,multiply,normal,negation,or,overlay,pinlight,reflect,screen,shapeaverage,softburn,softdodge,softlight,stamp,subtract,vividlight,xor
rayBL=${arg0 $rayBL,$list_of_blending_modes}
bgBL=${arg0 $bgBL,$list_of_blending_modes}
You can disable word wraps to simply ignore the additional line in KDE Kate. I enable and disable dynamic word wraps depending on needs.
1 Like
It’s actually man made word wrap. I hate long lines
Actually it throws an error “file arg0 doesn’t take any input options (add, alpha, etcc specified)”
Had to write it like this and it works :
rayBL=${"arg0 $rayBL,"$list_of_blending_modes}
bgBL=${"arg0 $bgBL,"$list_of_blending_modes}
Thanks!
PS : is it possible to do the same for GUI declarations?
i have 2 of these :
#@gui : Blending = choice(34,"Add","Alpha","And","Average","Blue","Burn","Darken","Difference","Divide","Dodge",\
# "Edges","Exclusion","Freeze","Grainextract","Grainmerge","Green","Hardlight","Hardmix","Hue","Interpolation",\
# "Lchlightness","Lighten","Lightness","Linearburn","Linearlight","Luminance","Multiply","Negation","Or","Overlay",\
# "Pinlight","Red","Reflect","Saturation","Screen","Seamless","Seamless_mixed","Softburn","Softdodge","Softlight","Stamp","Subtract","Value","Vividlight",\
# "Xor")
That’s a bit redundant, can’t imagine a filter with 10 identical menus…