[ome-devel] bfconvert 5 produces 16-bit tiff files that cannot be read by freeimage
Tjelvar Olsson (JIC)
Tjelvar.Olsson at jic.ac.uk
Thu Jul 28 10:51:13 BST 2016
Dear Roger,
Thank you for getting back to me.
The "showinf" tool did not reveal the difference you outlined.Both seem to be recognised as false color with 16-bit LUT. I have attached the output from the command.
I have uploaded the image using the link you provided. The file is called:
Col0-NV-Sense-mRNA670+Unspl570_01.czi
Can you access it?
Thank you for your help with this.
Kind regards,
Tjelvar
________________________________________
From: ome-devel [ome-devel-bounces at lists.openmicroscopy.org.uk] on behalf of Roger Leigh [rleigh at dundee.ac.uk]
Sent: 26 July 2016 11:50
To: OME External Developer List
Cc: Matthew Hartley (JIC)
Subject: Re: [ome-devel] bfconvert 5 produces 16-bit tiff files that cannot be read by freeimage
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
_______________________________________________
ome-devel mailing list
ome-devel at lists.openmicroscopy.org.uk
http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: showinf_v4.out
Type: chemical/x-gulp
Size: 34216 bytes
Desc: showinf_v4.out
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20160728/56a61cb7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: showinf_v5.out
Type: chemical/x-gulp
Size: 26785 bytes
Desc: showinf_v5.out
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20160728/56a61cb7/attachment-0001.bin>
More information about the ome-devel
mailing list