Are you using DOS command line by any chance? I'm wondering if an unexpected substitution is happening, since DOS uses "%" for some things.

no, the command was experimented inside gimp, using gimp-gmic

ps
my environment is win 7 32 bits

edit: and was done using gmic 1.5.6 beta, I will try to reproduce it on the stable version downloaded yesterday

Like this ?



(Tested on Ubuntu / Linux 32bits).

Just tested on my Virtualized XP, and it works as expected too.

ok, I'll check on the stable version (obviously I don't have any more the beta version...)

checked, now it's OK also in my env with stable 1.5.6.0
don't know whether the beta I had previously was somehow involved, what I can tell you is that I tried many times, and with many different percentages, which ALL worked EXCEPT 0%

so, now good news also for myself!

Glad you got it working

I waited to get the updated version of the handbook before writing this post.
IMO the example 121 on page 84 about command 'cut' is incorrect:
the command --cut 25%,75% produces a duplicated image with LESS LIGHTS and LESS SHADOWS (25% less in both directions?) as I expected, but the example shows an image with MORE LIGHTS and MORE SHADOWS.
Am I wrong?

Probably because of the image normalization process that has been used for the visualization of the image ?

you mean the visualization of the Handbook image on my screen? or the visualization of my image under Gimp?
anyhow, does that cut command mean cutting the initial and final values or not (so that only the intermediate values are kept)? I'm confused

I meant the visualization of the Handbook image. All images generated for the handbook are renormalized between [0,255].
The '-cut' command basically replaces all values below the 'min' argument to 'min', and all values greater than the 'max' argument to 'max'.

this is exactly what I expected from -cut
so probably better to add to the example the command -normalize 0,255
after the -cut command

if I apply this on my testing the image shows up exactly that way (as in the handbook)...

Adding the '-normalize' command will do nothing, as it will be done by the handbook script automatically... Maybe I should rather set the two first pixel values to values 0 and 255, so that the normalization will do nothing.

good idea (just not to confuse the reader about the result of the -cut command)

sorry to be often a boring reader; I played just now with the command -set
I tried example 151 and I got only a black square by using:
2,2 -set 1,0,0 -set 2,1,0 -set 3,0,1 -set 4,1,1 (I added -resize 100,100 to see)
I got what the example shows if I input the following values:
2,2 -set 0,0,0 -set 85,1,0 -set 170,0,1 -set 255,1,1
I suppose it is again a problem of "normalization" of the handbook images
but - as a poor reader - again I feel confused.
Wouldn't be more understandable to enter the values which are shown instead of those to be normalized before printing?

I think that the problem of visualizing images with float-valued data doesn't have a 'best' solutions.
Sometimes, your images have values in [0,255], and so they can be nicely displayed without normalization, and you actually don't want to normalize them (as in the '-cut' example).
Other times, your image values are in range [0,1], and you definitely want to normalize them before display.

In the examples of the handbook, I've decided to normalize the images every time, as this is the easiest way to 'maximize' the contrast in the images and ensure you will see something at least. For some commands, it is a bit annoying.
On the other hands, if I wouldn't normalize the images everytime, it would imply I add *a lot* of '-normalize 0,255' commands in my examples, and this would probably lengthen the examples and make them maybe less clear to the reader. I'd like to keep examples as short as possible in fact.

I understand the "normalization" aspect, but - as you know - "an image is worth 1000 words", which means that an example has to be easily self-explanatory; so what I was asking in the latter case is not to use values which do not represent neither a usual graphic value (0-255) - immediately understandable by the reader - nor a float (0-1) range; the example shows values 1-4 which - by themselves - do not represent any "graphic" reality (IMO), they are only significant if normalized afterwards. I guess this creates confusion not only in "simple" readers like me, but also in "graphical experts" (but I would like to hear some opinion about that from those playing here around with G'MIC...)

What I'd say at a first glance (from my little image processing experience) is that I don't really understand why values 1-4 should not represent any "graphic" reality I have worked a lot with images normalized in [0,1] (medical images for instance). Also, someone used to work with 12bits or 16bits/channel images will not tell you that 255 is 'white'
I understand that most people here on Gimpchat are used to deal with values in  [0,255], but to me, an image is just a matrix of number, whatever these numbers are, and I won't be shocked by a normalized visualization.
But that's my viewpoint, and that's why I decided to normalize all the images in the Handbook examples. I don't pretend my thoughts must be shared by everyone. Interesting to get feedback on this actually.

I guess that when the computer displays will go to 12 or 16bits/channels, some people will have to learn another time what pixel values mean

I suppose it would at least make sense to mention somewhere that all reference images are normalised.