Legacy ImageMagick Discussions Archive

Hi,
I have a large number of 32-bit single-channel TIFFS to process. I found that it doesn't work with the currently installed ImageMagick, I can't get output of e.g. cropping the 32-bit tiff , in 32-bit tiff format. Upon deciding to obtain an uptodate ImageMagick, and upon googling this issue, I find a number of different discourses mentioning the Q16 versus Q32 in the version string. Can someone direct me to the up to date information about how to define, set, and use this Q32 ? Is this something you have to set at the environment, at configuration time, or by editing the source code? Sorry, I can't seem to find this on the ImageMagick web site?

Thanks for any help !
Regards
Robert

You will likely need to set up IM using HDRI and Q16 should be adequate if you have non-integer values in your 32bit tiff. If you have 32-bit non-negative integers, then Q32 should suffice, though I have never worked that environment.

Either way you need to manually recompile IM with additional arguments in your ./configure command. These would be either

--with-quantum-depth=32 for Q32

or

--with-quantum-depth=16 --enable-hdri for Q16 HDRI


see
http://www.imagemagick.org/script/advan ... lation.php
http://www.imagemagick.org/script/high- ... -range.php


I am not an expert on this but you may also need to add the following to your command line

quantum:format=type
Set the type to floating-point to specify a floating-point format for raw files (e.g. GRAY:) or for MIFF and TIFF images in HDRI mode to preserve negative values. If -depth 16 is included, the result is a single precision floating point format. If -depth 32 is included, the result is double precision floating point format.

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

For the actual meaning of Q-level and HDRI see IM examples, Basics, Controling the Quality of Images
http://www.imagemagick.org/Usage/basics/#image_quality
It looks at depth first which can be important setting to understand, especially with different Q-level versions, but then goes into Quality and HDRI, and what they precisely do for you.

Thanks, Fred, Anthony:
Anthony's link is really exactly what I was looking for. I'm sorry I failed to locate it on my own. In fact, my 32-bit floating-point TIFFS contain negative values, and contain small numbers of extreme values, what I am initially trying to do is to launch a command line process to apply the same cropping to several thousand such images, launch several instances of this on a cluster, while requiring that the cropped image section to be identical precisely with the corresponding section of the uncropped image. Certainly I could write a c program for this very purpose but then future incorporation of some intermediate filter would be an annoyance , it will be so easy with ImageMagick! Thus, the simple notion that Q16 'should be adequate' is not really valid; the values will get changed unexpectedly since the images contain both small variations and some extreme values (these may get filtered out in subsequent stages before some final image is produced) . These images are the input projections for fourier back-projection tomographic reconstruction, so as Tony says:

"HDRI is thus vital when you plan to use extremely heavy mathematical processing of images, involving the temporary use of negative values, or strong scaling to very small or very large values."
though at this point I just want to crop them a little ...

Using Q32 and HDRI seems to be the right choice in this case

What I did not initially understand were the followign : the Q level is required at compile time; setting Q32 still does not allow negative values; and also the quantum:format= setting (but I found out about that setting first, of course it didn't do what I wanted because it was a Q16 non-HDRI build !)

Many thanks now, it seems to work as I wish -- apart from not being able to build branch 6.7.5 because AnnotateImage has the wrong number of arguments

Regards
Robert

robert_a wrote:TWhat I did not initially understand were the followign : the Q level is required at compile time; setting Q32 still does not allow negative values; and also the quantum:format= setting (but I found out about that setting first, of course it didn't do what I wanted because it was a Q16 non-HDRI build !)

The Q level is a compile time option. It must be given as part of the build configuration of ImageMagick.
The same is true for HDRI.

However when you have HDRI enabled the Q level becomes mostly irrelevant to the quality of images. It does not matter if it is Q8 or Q32 when you are working with floating point numbers. It only becomes a 'scaling factor'. However many of the operations use arguments that are input as 'color or channel values', and the Q level will effect what those numbers mean.

For example -threshold 128 will threld the image at about 50% grey for a Q8 imageMagick, and at a near black level for a Q16 or larger version of ImageMagick.

Typically those values can be input as a 'percentage' instead, so you would normally say -threshold 50% means threshold at a perfect gray value in all ImageMagick versions. It really only becomes important for operations such as -level or perhaps in generating morphology 'distance' gradients (though that can also use actual floating point values with HDRI).

A Q16 HDRI is thus typically 'good enough' for practically any purpose you may have need for, and is fairly standard.

The only time I see a Q32 HDRI is need is perhaps to read or write 32 bit integer values in some image file formats (TIFF, or perhaps raw RGB data), I am just not certain about the how individual coder modules handle that situation.

According to the changelog,

2012-03-05 6.7.5-10 Cristy <quetzlzacatenango@image...>
Fix too many arguments to AnnotateImage() (copy/paste bug).