Output image ColorMap cannot be read by Matlab

matlab
scifio
Tags: #<Tag:0x00007fb882c34348> #<Tag:0x00007fb882c3fbd0>

#1

I tried to use BoneJ to measure the thickness with the latest version. Everything works fine except that the output image is coloured with certain colormap. The saved images as tiff files cannot be opened by any other image process software I am using (Matlab and Avizo) with an error message indicating that it is to do with the colormap.

Do you think you can help me resolve the issue?

Thanks


#2

Is the error you get, something like this?

Incorrect count for “ColorMap”; tag ignored. (TIFFReadDirectory)


#3

The error messege is:
TIFF library error: ‘TIFFReadDirectory: Incorrect count for “ColorMap”; tag ignored.’.


#4

Looks like this is a quite well-known issue, maybe related to changes in libtiff. A quick Google of your error reveals a number of possible issues that you could explore (none of which are in the control of the BoneJ team). Thanks @carandraug for picking this up.


#6

HI, I think it is to do with BoneJ and how it is handling the colormap.

Not only I cannot open in matlab, i cannot open the tiffs in Avizo.

I used t use an old version and it works fine.


#7

Maybe it is to do with NaN background: the pixel values of the background are set to the Double value ‘NaN’ because they represent empty space rather than 0 thickness. In this case the change in BoneJ (introduced recently) has exposed a bug in libtiff / how Matlab et al. handle NaN pixel values (i.e., they don’t). You could work around it by saving your TIFF with zeroes instead of NaN, but you will have to convert your NaNs first.

The reasoning for using NaN is that it makes generating summary statistics much easier in ImageJ: the NaN values are simply ignored (rather than zeroes, which would add to the denominator but not the numerator of a mean pixel value calculation, for example).


#8

This is not BoneJ specific and has nothing to do with NaNs. The problem is that ImageJ writes tiffs of disputable validity and some versions of libtiff choke on them. I’ve been experiencing this issue for a couple of years on GraphicsMagick, ImageMagick, R, and Octave. I have also heard reports about it on Matlab. Basically, any program that uses libtiff will have this issue.

tl;dr

ImageJ includes a ColorMap on grayscale images and libtiff is confused by this because the TIFF specs are not clear on whether this is valid.

Long explanation

An image on a tiff can be of many different types. The actual type of the image is defined by a set of fields. One of the fields is PhotometricInterpretation which has a value of 0 or 1 for grayscale and 3 for palette (indexed) images. Another field is ColorMap which has the RGB values to use in palette images.

The problem is that ImageJ includes ColorMap on grayscale images and the TIFF specs do not mention what to do with ColorMap for non-palette images. One could argue that on non-palette images, ColorMap should not be set at all since the specs say that ColorMap “defines a [colormap …] for palette color images”. But the specs do not say “for pallete images only” or “must not be set in non-palette images”. However, the TIFF specs are organized by image type and not by page fields so it wouldn’t make much sense to write it like that in the first place. And indeed, the section on RGB images clearly say they must not have a ColorMap defined. Still, no specifications for what to do on bilevel and grayscale images.

What happens then is that libtiff expects a ColorMap to only be present on palette images. When it finds ColorMap, it checks if it’s valid for the image. ImageJ’s colormap has 256 values which will rarely match the image (I often see this on 16 bit grayscale images). So libtiff throws an error ‘Incorrect count for “ColorMap”’.

I will guess that ImageJ position on this is that since this is a grayscale image (PhotometricInterpretation is 1), the length of ColorMap is irrelevant and therefore libtiff should ignore it. Very recent versions of libtiff changed their behaviour to throw a warning instead of an error (this change was made for version 4.0.4 which got released on June 2015).

I’m not sure why ImageJ saves a ColorMap in grayscale images. I believe this is where ImageJ stores the colormap used for display although I never dug deep enough to confirm this.


#9

@carandraug Thanks for the detailed analysis!

Have you checked whether the Bio-Formats Exporter plugin has this problem? What about SCIFIO (File :arrow_forward: Export :arrow_forward: Image…)? Maybe one of these options avoids the issue?


#10

The Bio-Formats Exporter has the same problem. The created tiff still has ColorMap, even when saving a “ome.tiff”, causing libtiff to error.

Using SCIFIO does solve the problem and libtiff no longer complain (thank you, this has been bugging me for years). However, then ImageJ no longer knows what color to use on each channel (I don’t personally care for this, but I know many who do). Technically, these are grayscale images so displaying them as gray seems the right thing to do but users do expect colour.


#11

Well, obviously, TIFF supports indexed color, which I guess is how they should be saved, then, if the user wants the colors preserved! Feel free to file an issue at https://github.com/scifio/scifio/issues, if you like.


#12

Done. SCIFIO exporter does not keep track of ImageJ lookup table.


#13

Thanks, @carandraug!


#14

Seems like this hypothesis is unsupported & it’s a TIFF ColorMap issue instead. Thanks @carandraug for the clarification.


#15

Great explanations and work-arounds ya’ll. Thank you very much.