[ome-devel] bfconvert 5 produces 16-bit tiff files that cannot be read by freeimage

[Roger Leigh]

On 25/07/2016 14:33, Tjelvar Olsson (JIC) wrote:
> Dear OME,
>
> I have for some time now been finding myself switching back to bfconvert
> version 4 when dealing with 16-bit microscopy images.
>
> The reason for this is that bfconvert version 5 produces tiff images
> that cannot be parsed by the freeimage library.
>
> Today I thought I'd spend a little bit of time trying to work out what
> is going on and send a query to your mailing list.
>
> The error that I get from freeimage is:
>
> FreeImage error: Unable to handle this format: bitspersample = 16,
> samplesperpixel = 1, photometric = 3
>
> I suspect that this has to do with the photmetric flag, which I don't
> really know anything about.
> However, looking through the freeimage source code I think it can be
> traced to the
> "IsValidBitsPerSample" function on line 1079
>
> https://github.com/imazen/freeimage/blob/master/Source/FreeImage/PluginTIFF.cpp#L1097
>
> In particular the check for the whether or not the "photometric" is a
> "PHOTOMETRIC_PALETTE" on line 1111.
>
> https://github.com/imazen/freeimage/blob/master/Source/FreeImage/PluginTIFF.cpp#L1111
>
> Inspecting the content of the TIFF files generated using bfconvert it
> seems that one difference between version 4 and 5 is that the former has
> a photometric interpretation "BlackIsZero" and the latter "RGB Palette".
>
> Was this change in going from version 4 to 5 intentional?
> What was the rationale?
>
> I would love to be able to use newer versions of bfconvert on 16-bit
> micoscopy files and parse the files using freeimage.
>
> Do you think this will be possible in the future?

Dear Tjelvar,

Would it be possible to upload a sample source file demonstrating the
problem using http://qa.openmicroscopy.org.uk/qa/upload/ i.e. the input
to bfconvert?

I suspect it's not a result of any change in how we write TIFF files,
but rather that we now read lookup tables from the original file format
where we previously failed to read and preserve them.

Could you try the following:

Run "showinf" from both 4.4 and 5.1 on your original image.  What is the
"Indexed" setting?  Do you see any warnings about "no LUT for plane #nn"
with the 4.4 version which are not present with 5.1?

Example with a Zeiss LSM file:

4.4 showinf:

Reading core metadata
Filename = /home/rleigh/images/vessels.lsm
Series count = 1
Series #0 :
        Image count = 288
        RGB = false (1)
        Interleaved = false
        Indexed = true (false color)
[...]
Reading pixel data (0-287)
        ************ no LUT for plane #0 ************
        ************ no LUT for plane #1 ************
[...]

And if I run bfconvert to ome.tiff and run libtiff tiffinfo:

TIFF Directory at offset 0x8 (8)
   Image Width: 1024 Image Length: 1024
   Resolution: 22755.6, 22755.6 pixels/cm
   Bits/Sample: 16
   Sample Format: unsigned integer
   Compression Scheme: None
   Photometric Interpretation: min-is-black
   Samples/Pixel: 1
   Rows/Strip: 1
   Planar Configuration: single image plane
[...]

The photometric interpretation is indeed min-is-black.

If I do the same for a non-indexed file it also remains min-is-black.

Repeating with 5.1 showinf:

Reading core metadata
filename = /home/rleigh/images/vessels.lsm
Series count = 1
Series #0 :
        Image count = 288
        RGB = false (1)
        Interleaved = false
        Indexed = true (false color, 16-bit LUT: 3 x 65536)
[...]
Reading pixel data (0-287)
        Read 39/288 planes (13%)
[...]

And then running bfconvert to ome.tiff and running tiffinfo:

TIFF Directory at offset 0x8 (8)
   Image Width: 1024 Image Length: 1024
   Resolution: 22755.6, 22755.6 pixels/cm
   Bits/Sample: 16
   Sample Format: unsigned integer
   Compression Scheme: None
   Photometric Interpretation: palette color (RGB from colormap)
   Samples/Pixel: 1
   Rows/Strip: 1
   Planar Configuration: single image plane
   Color Map: (present)

You can see that we now have both palette colour *and* a colour map
(lookup table).

For the specific file format above (Zeiss LSM), the change between 4.4
and 5.1 is correcting a deficiency in the older version.  It now
correctly reads and preserves the indexed colour setting and colour map
from the original proprietary file format.

I've tested with images which are not indexed, and these do remain
min-is-black.


With a sample image, I can check what's happening in your specific case
in more detail.


It looks like the root of the problem is that FreeImage doesn't handle a
very common type of TIFF image, and the ideal solution would be to
update FreeImage to be able to read this type of TIFF.  As for
workarounds, one option would be:
- When running bfconvert, use the -expand option to remove the colour
map; this will turn the image from greyscale to RGB however, and it
wasn't working for me with the latest 5.1 bfconvert.  There isn't an
option to simply strip the colour map without conversion that I can see.
- Other people on the list may well have better suggestions here.


Kind regards,
Roger

--
Dr Roger Leigh -- Open Microscopy Environment
Wellcome Trust Centre for Gene Regulation and Expression,
School of Life Sciences, University of Dundee, Dow Street,
Dundee DD1 5EH Scotland UK   Tel: (01382) 386364

The University of Dundee is a registered Scottish Charity, No: SC015096