[ITK-users] Reading Gray Scale Palette Image

[Bradley Lowekamp]

Hello Michael,

The current itkTIFFIO does handle some special cases for palette. Namely when all  RGB palette entries are equal[1], the image palette is interpreted as grayscale. The other is when all the entires are less that 256, the component is interpreted as unsigned char.

On the bright side you are not getting an RGB of uint16 :) But we are not handling the case where the upper bits of the palette entries are used and not the lower, so you are still getting uint16.

While it is quite possible to modify TIFFIO to load this data as you expect, it likely would be easiest to just shift the palette in the file. As I have used this format before I was surprised with the support from a number of viewers.

HTH,
Brad

[1] https://github.com/InsightSoftwareConsortium/ITK/blob/6871f6f2c9510057ca253727d8487d88724cf2d8/Modules/IO/TIFF/src/itkTIFFImageIO.cxx#L122-L131
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/6871f6f2c9510057ca253727d8487d88724cf2d8/Modules/IO/TIFF/src/itkTIFFImageIO.cxx#L392-L402

> On Jan 22, 2016, at 9:28 AM, Michael Jackson <mike.jackson at bluequartz.net> wrote:
> 
> We have a Tiff image that is GrayScale (8 bit) and Palette (photometric interpretation=3) and the indices into the palette are 16 bit but the values in the palette are 8 bit? When trying to use ITK to figure out what type of array we should be allocating our logic is coming back with 16 bit unsigned shorts because  we have the following code:
> 
>   itk::ImageIOBase::Pointer imageIO = itk::ImageIOFactory::CreateImageIO(getInputFileName(), itk::ImageIOFactory::ReadMode);
> 
> itk::ImageIOBase::IOComponentType componentType = imageIO->GetComponentType();
> …
>   else if(itk::ImageIOBase::USHORT == componentType)
>  {
>    data = UInt16ArrayType::CreateArray(0, "Temp", false);
>  }
> …
> 
> Here is the header of the tiff file as put out by “tiffdump”
> 
> /Users/XXXXXXXX/Downloads/image_01.tif:
> Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF>
> Directory 0: offset 8 (0x8) next 113277976 (0x6c07c18)
> ImageWidth (256) LONG (4) 1<12288>
> ImageLength (257) LONG (4) 1<9216>
> BitsPerSample (258) SHORT (3) 1<8>
> Compression (259) SHORT (3) 1<1>
> Photometric (262) SHORT (3) 1<3>
> StripOffsets (273) LONG (4) 1<31768>
> RowsPerStrip (278) LONG (4) 1<4294967295>
> StripByteCounts (279) LONG (4) 1<113246208>
> XResolution (282) RATIONAL (5) 1<1>
> YResolution (283) RATIONAL (5) 1<1>
> ResolutionUnit (296) SHORT (3) 1<1>
> Colormap (320) SHORT (3) 768<0 256 512 768 1024 1280 1536 1792 2048 2304 2560 2816 3072 3328 3584 3840 4096 4352 4608 4864 5120 5376 5632 5888 …>
> 
> 
> My question is this: what can we interrogate from the imageIO object to really nail down that this really turns out to be an 8 bit image?
> 
> Thanks
> --
> Michael A. Jackson
> BlueQuartz Software, LLC
> [e]: mike.jackson at bluequartz.net <mailto:mike.jackson at bluequartz.net>_____________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.php
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-users/attachments/20160122/f5aa2957/attachment.html>