32bit tifs are 32bit what exactly?

[Colin Poczatek]

Ok, a bit of background first.  I've been writing some auto-contrast
adjustment scripts for document creation for my lab using
Ruby+Imagemagick.  Everything worked fine with 16bit integer images, but
when testing on a 32bit tif from ImageJ I couldn't get anything to work.
 I posted something on the IM user list and one of the developers
replied with this answer:

"The problem is that the image incorrectly reports the sample format as
IEEE floating point when it is unsigned. When we force the unsigned
format (with a quick debugging patch for GrayQuantum/32-bit in
ExportQuantumPixels() of magick/quantum.c), the correct image values are
returned (they match the output of the tifftopnm program)."

This strikes me as very odd.  I get the same behavior with an all
positive valued 32bit tif and a pos/neg valued 32bit tif.

I'm only asking since we have a very odd "image" format, and I'm
eventually going to have to rewrite some existing tools to output 32bit
tifs (that -somebody- wrote not using a tif library, but writing out the
file byte-by-byte) that can be opened in ImageJ.  (and I got the
contrast adjustment working by going through a temporary .pnm format)

I don't completely understand what's going on, but does the tif header
say signed 32bit float when it's not?  (I don't think this is an
endianness issue)  I looked around the list archive/wiki and didn't see
anything, but maybe I missed something.

Collin



The information transmitted in this electronic communication is intended only
for the person or entity to whom it is addressed and may contain confidential
and/or privileged material. Any review, retransmission, dissemination or other
use of or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received this
information in error, please contact the Compliance HelpLine at 800-856-1983 and
properly dispose of this information.

[Joachim Wesner]

ImageJ Interest Group <[hidden email]> schrieb am 07.04.2008 19:11:44:

> Ok, a bit of background first.  I've been writing some auto-contrast
> adjustment scripts for document creation for my lab using
> Ruby+Imagemagick.  Everything worked fine with 16bit integer images, but
> when testing on a 32bit tif from ImageJ I couldn't get anything to work.
>  I posted something on the IM user list and one of the developers
> replied with this answer:
>
> "The problem is that the image incorrectly reports the sample format as
> IEEE floating point when it is unsigned. When we force the unsigned
> format (with a quick debugging patch for GrayQuantum/32-bit in
> ExportQuantumPixels() of magick/quantum.c), the correct image values are
> returned (they match the output of the tifftopnm program)."
>
> This strikes me as very odd.  I get the same behavior with an all
> positive valued 32bit tif and a pos/neg valued 32bit tif.
>
> I'm only asking since we have a very odd "image" format, and I'm
> eventually going to have to rewrite some existing tools to output 32bit
> tifs (that -somebody- wrote not using a tif library, but writing out the
> file byte-by-byte) that can be opened in ImageJ.  (and I got the
> contrast adjustment working by going through a temporary .pnm format)
>
> I don't completely understand what's going on, but does the tif header
> say signed 32bit float when it's not?  (I don't think this is an
> endianness issue)  I looked around the list archive/wiki and didn't see
> anything, but maybe I missed something.
>

IJ "32-bit" TIFF AFAI can tell is definitely 32-bit IEEE float if it
reports so. I have an
independent (Visual Basic) application that writes a 32 bit float TIFF
using the "official" libtiff
library and it is fully compatible to IJ. (In contrast, "Irfanview" does
not yet know about
32 bit float TIFFs and tries to open those as 32 bit int and opens those
files incorrectly. you can
make out basic structures of the image, but the result is very "noisy")

Also, many completely valid TIFF files are organized in independent stripes
or even "sectors"
and simpler readers that determine one single start address and try to read
the while file from
there will fail (This is discussed in detail in some FAQs). TIFF float
support is also "relatively"
new, only since TIFF v6.0 AFAIK, maybe your software relies on an older
preliminary specification?


I used the docs and library from here:

http://www.libtiff.org/


Joachim


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________