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.
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.
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.