-level option (under Windows?)

[whugemann]

Having been active on the mailing list for some time, I now try the "new" board for the first time:

I think there is a bug in the -level option when using fixed values as command line parameters for 8 bit images in the 16 bit versions of IM:

Convert -size 256x256 -depth 8 -colorspace gray gradient: in.png
convert in.png -level 80,200,1.0 out.png

should black out all pixels with values below 80 and white out all pixels with values above 200. The pixels in the middle region 80 -- 200 should be stretched to 0 -- 255. But you have to supply 16 bit values in order to get the correct result, i.e.

convert in.png -level 20480,51200,1.0 out.png

The same holds for GIF images, which definitively have 8 bit color depth, i.e. you have to type

Convert -size 256x256 -gradient: in.gif
convert in.gif -level 20480,51200,1.0 out.gif

to get the desired result, which seems really strange. Percent values however work fine, regardless of the color depth.

Wolfgang Hugemann

[fmw42]

Hello Wolfgang,

It does not matter whether Windows, Linux or Mac. I believe that raw values are/have always been specified for -level at the QuantumRange of the compile even when you specify -depth 8, which probably is only applied at the end (even if you specify it earlier). But I will defer to the IM developers. Feature rather than Bug, though a bit confusing. That is why I generally use percents.

see http://www.imagemagick.org/script/comma ... .php#level

Fred

[anthony]

Fred is quite correct

The operators -level and -threshold, and even -evaluate, will use a actual Quantum Range Value for the task (very exact, especially near the end of the range). Percentage values should be used when you want a value that is independent of the compile time quantum range.

Basically whether percent should be used or not depends on exactly what you are doing and the situation you are in using it in.

[whugemann]

I agree now that IM's behaviour in in agreement with the documentation, but does it coincide with what the user (me) would expect?

If I want to make a histogram correction, I have probably analized the input file(s) beforehand. If they have a colour depth of 8 bit, I will have noted 8 bit values for the desired boundaries. I would not expect to have to either compute them into percentage values or to multiply them by 256. Moreover, the most-spread image formats have still 8 bit depth and a lot of programs define the boundaries in terms of 8 bit values (older Photoshop versions, AVIsynth, VirtualDUB) or use the color depth of the image for these values (Gimp).

So I would rather expect absolute values to refere to the color depth of the input image.

Anyway, I would rather say that the histogram correction operators (level, auto-level, contrast-stretch and alike) should somehow be bundled, as they are all shades of the same basic operation. They should be handled as values for some basic operator, say -histogram-correction, like has been done for the -distortion operator.

Wolfgang Hugemann

[anthony]

So you computed your histograms as 8bit,
but IM reads and stores the image in memory as 16 bit.

How is IM to know you did your calculations with 8bit values. Not all images read in are 8bit.

IM does know if an image was read using depth 8 values (unless reset for output using +depth). However the image could have been further processed, resulting in new colors, color merges, etc. As such the color values in memory may no longer be 8-bit, even though it was originally 8-bit. IM has no way of knowing.

Further even if IM uses level values based on the images read in -depth That means you can get different results from different images, as every image may have a different depth! That is asking for complete chaos!

You can always compile your own version of IM that is Q8. Though that mean you will loose accuracy in many operations. Especially when doing multiple operations where color differences can add up. This is why Q16 is the default, not Q8.

[whugemann]

Anthony,

I see the point in your arguing. Possibly this would only need some more explaination in the documentation. (I should have looked up what "quantum range" means; I believed it to be a strange word for "colour depth"!)

I have performed huge amounts of histogram corrections over the last 15 years, in fact it's mostly the first thing I do for correcting any image. Therefore I was so used to the standard way of proceeding that it took me two hours to understand what was going wrong. (In fact, I believed in a bug and actually had a spontaneous insight while I was writing the board message.) So there might be other users who will step into this pitfall.

Wolfgang