Re: 8bit tiff -- Change in Behavior / Bug : 8bit, 256color, PHOTOMETRIC_PALETTE == converted to 16-bit tiff

Thank you for your very complete response on this issue.

Your explanation below seems to fit with what I have observed.  
Below, I will outline a few items I have determined thus far using the example TIFF image referenced in this issue:

a.  In ImageMagick 6.3.6, the max pixel value is 254, even though the raw data has a max pixel value of 255.  I believe this is probably related to how the 'convert image.tif -depth 8 new.tif' command behaves.

b.  In ImageMagick 6.5.4-10, the max pixel value is 65280 (255*256).  I AGREE with you that this is correct and not a bug with ImageMagick.  Since the example TIFF image has a Lookup Table (LUT), the correct behavior is for ImageMagick to use the LUT supplied in the image to translate the pixels to 16bit values.

c. Both ImageJ and GIMP open the example image as a 8bit image and this 8bit image corresponds to the raw pixel values before translation by the LUT to 16bit.

d. The following transformation will give me the 8bit raw data I was looking for: Open the TIFF with ImageMagick 6.5.4; divide the pixels by 256; convert the pixel type from 16bit to 8bit unsigned.  This transformation give me the same pixel values as the raw pixel values in the TIFF.  Also, this transformation then matches the pixel value from both ImageJ and GIMP.




> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> Sent: Saturday, August 29, 2009 8:03 AM
> To: [email protected]; magick-
> [email protected]; Scott Callaway
> Subject: RE: [Magick-bugs] 8bit tiff -- Change in Behavior / Bug :
> 8bit, 256color, PHOTOMETRIC_PALETTE == converted to 16-bit tiff
> 
> > The primary problem for my application is that the 8bit tiff gets
> > converted to a 16bit image using the current version of ImageMagick.
> 
> Of course.  The colormap has a value of 65280 which does not fit in an
> 8-bit value without losing precision.
> 
> > The current versions of ImageJ and Gimp read this tiff as a 8bit
> image.
> 
> We recommend you file a bug report with these projects.
> 
> > I appears the code in coders/tiff.c [ near line 1000 ] is causing the
> > pixels to b e converted from 8bit to 16bit pixels.  If ImageMagic
> code
> > was modified so the pi xels were kept at 8bits (as with ImageJ and
> Gimp),
> > then this would also avoid the
> >  problem you outline below.
> 
> We certainly will if you can tell us how to fit the value 65280 in 8
> bits without losing color information.  Note the accepted conversion
> of 16-bit to 8 is 16-bit-value / 257.  See Google for an explanation on
> why 257 rather than 256.  The TIFF library is the definitive standard
> for
> the TIFF specification.  We cut-n-pasted code directly from the library
> for
> converting the 16-bit colormap to 8 and we get
> 
>   if (checkcmap(in, 1<<bitspersample, red, green, blue) == 16) {
>     int i;
>   #define CVT(x)          (((x) * 255L) / ((1L<<16)-1))
>     for (i = (1<<bitspersample)-1; i >= 0; i--) {
>         red[i] = CVT(red[i]);
>         green[i] = CVT(green[i]);
>         blue[i] = CVT(blue[i]);
>     }
>   #undef CVT
>     }
> 
> Notice how it returns 254 for the maximum color value.
> 
> > The image below that experiences this problem from an automated
> > microscope that i s used by many biologists and scientists [ this
> > image is of fluorescent cell nucl ei ].  Due to the quantitative
> > nature of this work, it is important that pixel va lues are accurate.
> >
> http://www.huntermikic.com/imagemagick/imagemagick_AS_09047_05042803000
> 1_O01f00d0
> > .TIF
> 
> That is precisely why we return 16-bits instead of 8.  We are returning
> the
> precise values that the image colormap reports (see below).  You can
> return
> an 8-bit image with this command:
> 
>   convert image.tif -depth 8 new.tif
> 
> However, the maximum value will be 254.  You can skew the data slightly
> to
> return the desired 255 maximum value with the -evaluate option.