So, I guess it’s not solve-able at this point?
Right now, probably not.
I’ll check it in a few days probably.
I’ve checked this issue this morning. I confirm that dynamic arrays store its number of arguments as a float value (at the last available position in the image representing the array), which means that indeed, no more than 2^24 elements can be stored in such an array (which is the precision for the digits stored in a IEEE float 32bits).
Several workarounds can be found:
- You may not need dynamic arrays at all. If you know by advance what the maximum number of entries in your array will be, and if you do insertion only at the end, then using a dynamic array is overkill. In that case, you can just define an image with expected max dimensions and fill it, without the need of dynamic resizing.
- Another way is to store the number of elements in a dynamic array in a separate variable in the math evaluator (which uses
doublevariables rather thanfloat), and do your own dynamic arrays functions (inspired by what exists inmath_lib). This shouldn’t be a big deal to define such a ‘large’ dynamic array. Anyway, you’ll still get a limit of 2^32 elements, as the dimension of an image along a single axis is limited to 2^32. - Probably a better idea: redesign your algorithm. An algorithm that requires a dynamic array with more than 4096^2 elements is not that usual (even in image processing). I don’t say it is wrong, but there may be better alternatives to store these elements than a dynamic array. As I said before, if you already know the max number of elements, or if you can associate each element to a pixel on another image, then it is probably better to use another kind of data structure than a dynamic array to store the informations you need.
Is there already a way of using apply_channels on luminance (assuming sRGB input)?
It would be equivalent to color_channels = xyY_Y
Basically multiply linear pixel vector by scalar (new Y / old Y), here’s what I’ve used (add an extra channel temporarily):
_ac_luminance :
_p="to_color"
_f="srgb2rgb rgb2xyz8 sh 1 a c"
_b="s c,{1-s} sh.. 1 +eq. 0 +[-2,-1] /[-2,-1] * xyz82rgb rgb2srgb"
_s=3
No doubt there’s a more elegant way…
Yes, luminance is also YCbCr_Y, so you can pass this to apply_channel
I thought that’s still gamma compressed (as in Y’ = “luma”)?
When I last checked the formula for that it was “digital 8bpp Y’CbCr from R’dG’dB’d”, but that was a while ago.
Ah maybe yes, but in this case, why not
srgb2rgb. ac. "command",ycbcr_y rgb2srgb.
?
Hmm I’m not sure whether that’s a “correct” conversion either, because the Y’ “luma” is simply a sum of (gamma altered) R’G’B’
Edit: no, I misread that… re-reading!
OK, it’s almost correct but the multipliers are slightly off:
0.299 R’ + 0.587 G’ + 0.114 B’
vs
0.2126 R + 0.7152 G + 0.0722 B
So you could pre multiply to make it correct, but then it’s becoming a bit ugly perhaps
It should be fixed now.
1 Like
The filter now works, thank you.
I can’t see a difference with the boolean “cut” checked or not checked.
I fixed the “cut” option now.
2 Likes
It does seem the coefficients are different. Anyway it’s not urgent 
, I can define something like _ac_gcd_luminance in the meantime (I assume that’s ok?). It makes working with the drop down selection nicer.
Another question: is there something equivalent to isimage(imagename)?
I found you can do things like ${imagename}, but it could be a variable instead. You can force an error with something like {imagename,n} but it seems messy. Any tips for handling image naming would be good!
Of course that’s ok ! apply_channel is intended to be generic enough to allow such additions.
From my experience, there are two ways of using names.
-
You can explicitly set a name to an image, so you can refer to the image with a variable name (so, in that case, no exotic characters in the image name, etc…). If you do so, there are no chances that another variable with the same name exists (this would be a mistake from the programmer), as variables are only local to the current custom command. In that context, using
$image_nameis the way to go. -
Or, you keep the image name (e.g. a filename), and you want to check for instance what position has the image in the list. In that case, it’s better to manage image names as generic strings, for instance like this:
foo:
search_for="Unknown.PNG"
repeat $! if {['{$>,n}']==['$search_for']}
echo "Found it, at position ["$>"] !"
fi done
1 Like
Indeed, I have a luminance command with a set of different coefficients and also rename my input files to make them more manageable.
Thinking about this, I’m pretty sure having a way to get the image indice for any type of image names (not just variables) would be really nice.
I’m still not sure, but maybe something like $["Image name"] could be used ?
$["Image name"] would return all the indices (separated by commas) of the images having the specified name.
So that we could write things like:
rm[$["Image name"]] # Remove all images having the given name
rm[{arg(1,$["Image name"]}] # Remove the first image having the given name
And this syntax is close enough to ${image_name}, and with the square brackets it reminds the syntax used for image selections [0] or [image_name].
What do you think ? I already see many places where this syntax could be useful.
That would suit me fine anyway 
The choice of quoting symbols is almost certainly best left to you, it’s difficult to know the consequences
Here is my proposal, implemented in current git repo.
It seems to work quite well for the moment (and of course, introducing this new syntax breaks the compatibility with previous versions of stdlib):
- '$[name]' is substituted by the lowest index of the images named 'name' in the image list.
'$$[name]' is similar but returns all indices of images named 'name', separated by commas.
Specified name may contain characters that cannot be used for the variable name '$name'.
If no image with specified name exists, '$[name]' is an empty string.
Do not hesitate to correct the doc if you think it’s not clear enough.
1 Like
1. I still have trouble retrieving Clean Text and afre_cleantext, for the plugin and CLI, respectively. Maybe it has to do with how I wrote it. I have no idea. But @iarga seemed to get it a one point.
2. One example where help is less useful. Compare
>gmic afre_cleantext
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'afre_cleantext' at position 0
[gmic]-0./ *** Error *** Unknown command or filename 'afre_cleantext'.
with
>gmic h afre_cleantext
gmic: GREYC's Magic for Image Computing.
(https://gmic.eu)
Version 2.5.6
Copyright (c) 2008-2019, David Tschumperle / GREYC Lab / CNRS.
(https://www.greyc.fr)
[gmic] Command 'afre_cleantext' has no description. Try 'gmic -h' for global help.
help doesn’t tell us whether afre_cleantext exists or not, and it also asks the user to try to use itself, which is redundant.
test_var=5
f "$test_var"
I know there is a way around this, but ideally, this should work. If any one is wondering why I’m doing this, I was thinking of trying to reproduce this after I finish up my nebulous filter (the cli order particularly for now)- Fractal attractor (ymd:170628) - Plugins - Publishing ONLY! - paint.net Forum