Was normalize always affected by the image having transparency information?
I tried an image with colored squares separated by black lines and the same where the black lines are instead saved as transparent and did a normalize 0,100 on both as test and the one that has transparency comes out as now also having transparency on the colored blocks, or in other words the normalize also applied the limit to the areas that were previously non-transparent.
I guess to G’MIC it’s just a multi channel image and it does not realize it’s transparency then.
Perhaps we need a new normalize command (new to avoid breaking things) that has an option as to which channels the normalize is applied to, because it might create interesting options if you could do a normalize only on a few channels.
And does a transparency layer ever need normalizing anyway?
I see there is an ‘afre_norm’ but I’m not sure what “Compute normalized norms” entails, and there is a ‘rep_multinormalize’ but I’ll have to do a search to get more info than the help gives, but ‘Normalize based on channels using values.’ sounds like it’s channel based, but I can’t make much of that description I fear.
But perhaps I should try making my own command, try using apply_channels to limit things and add that to my own collection, but that would be exclusive to me though.
Excuse my rambling post, I should be asleep but am not.
Exactly. And it’s a feature, not a bug 
The philosophy behind G’MIC has always been that it manipulates n-dimensional arrays of data (n\in \{1,2,3\}) agnostically to what these data represent.
It’s the user who has to know what the values in these arrays represent.
G’MIC does not store any additional information than the width,height,depth, number of channels of an image, and the image values.
In practice, this makes things so much more flexible and powerful.
That’s being said, it indeed requires some attention when you try to process images that has different types (here, RGB and RGBA I presume).
why not using apply_channels directly ?
$ gmic image_transp.png ac \"n 0,255\",rgb
It can apply a command directly on the first three channels of an input image. And that works both for RGB and RGBA inputs.
Thanks for the reply
And perhaps you are right, a direct approach might be better, I was envisioning a more broad system with channel selection but now I think that is actually not needed and can get more confusing.
I wonder though. with other color formats does normalizing it equally over all channels not cause issues too? like Lab and such, you might want to normalize L with a different limit than a and b or am I seeing that wrong? Or is there another command that does the same formula basically (which incidentally is nicely outlined on the help webpage) but in a different context for such uses. Because I guess the normalize command is mainly meant for getting the output right for the container. Although I see it used in various ways in the examples I get with the help of various commands.
This whole thing started when I was looking at afre’s .gmic and I saw that his ‘contrast’ was using blend_fade and then looking at the help of blend_fade the example G’MIC gives uses “normalize[-1] 0,1” in it, which started me doing some tests (while being up too late for my needs) including on images I had around that had transparency without me realizing, which confused me for a bit since I got different results than with images without transparency, and the example doesn’t use display0 either for output of course.
My original point being that there normalize is used to prepare an intermediate image for further processing, which you can argue doesn’t work right when there is transparency, which in turn means that if someone makes a more complex command with normalize in the intermediate result you have to deal with cases where there is transparency. So much to watch out for eh.
Reminds me of a time when I had a script-language based thing to help me with common task and another guy asked me if he could have it, so I gave it to him thinking it was all safe and OK and then he told me it did complete havoc to his computer. I still don’t know why it would have, but it shows there is so much to watch out for with stuff you give out to 3rd parties and for use cases you can’t always think of in advance.
So I understand David, you give us a scripting language, and us users should RTFM and use it according to their abilities
You are absolutely right. In G’MIC, there are “normalized” version of lab, hsv, hsi…, called lab8,hsv8,… that ranges from 0 to 255 for all channels.
That’s what apply_channels actually uses when doing:
$ gmic sp colorful +ac \"n 0,255\",lab_l +ac. \"n 0,255\",lab_ab
(here you normalize independently the L and ab channels, but both in [0,255]).
It’s a bit weird actually, as it should be lab8_l and lab8_ab , so I will probably change that for the next version.
1 Like
Ah I see, nice to see it’s all thought of.
And interesting to see.
It can be a bit hard to wrap your head around all the formats, some of them have looong wikipedia pages and they are actually rather complex and based on a range of concepts and research into color perception.
And there are so many of them.