[ome-devel] Is OME-TIF file with 2 image series of different pixel types supported?

[Michael Ellis]

This link might be what is required!

https://www.openmicroscopy.org/qa2/qa/feedback/17455/?token=0d0ad37c09cfdd73ca5c28df3d42e1b0 <https://www.openmicroscopy.org/qa2/qa/feedback/17455/?token=0d0ad37c09cfdd73ca5c28df3d42e1b0>


> On 1 Dec 2016, at 14:27, Michael Ellis <michael.ellis at dsuk.biz> wrote:
> 
> Dear Roger,
> 
> File uploaded https://www.openmicroscopy.org/qa2/qa2/qa/feedback/17455/?token=0d0ad37c09cfdd73ca5c28df3d42e1b0 <https://www.openmicroscopy.org/qa2/qa2/qa/feedback/17455/?token=0d0ad37c09cfdd73ca5c28df3d42e1b0>
> 
> I am currently just using Metadata methods to populate my metadata. Can you point me in the right direction for adding this TiffData that you refer to?
> 
> — Michael Ellis
> 
>> On 1 Dec 2016, at 14:17, Roger Leigh <rleigh at dundee.ac.uk <mailto:rleigh at dundee.ac.uk>> wrote:
>> 
>> On 01/12/16 10:48, Michael Ellis wrote:
>>> BioFormats does not seem to cope with a single OME.TIF file that contains 2 image series one with pixel type uint16 and one with pixel type uint8.
>>> 
>>> I can create the file with no problem but both the bftools showinfo command line tool and the ImageJ BioFormats importer crash when trying to load the file.
>>> 
>>> I realise mixing two images of different pixel types in a single OME.TIF file is somewhat bizarre. I have no actual need to do this but stumbled upon the situation whilst designing unit tests for my code.
>>> 
>>> My questions are:
>>> 
>>> - Is there anything else apparent from the output that points to anything wrong that I am doing?
>>> - Is this a bug or a feature?
>>> - If it is a feature, then where is it documented?
>> 
>> Dear Michael,
>> 
>> This should work, and is certainly supported by the specification.
>> There are two possibilities:
>> 
>> 1) An outright bug in the OME-TIFF reader
>> 2) A bug in the metadata which triggers the behaviour
>> 
>> Looking at the metadata you pasted, I think a potential culprit is the
>> lack of "TiffData" elements in your second Image element.  This likely
>> triggers fallback behaviour in the reader which makes it fall back to
>> attempting to use IFD0 as Plane0 in the image, which is of the wrong
>> pixel type.  It's likely the case that adding TiffData elements to the
>> Pixels element in this image will resolve the problem.
>> 
>> If the above suggestion doesn't help, if you would like to upload the
>> file using https://www.openmicroscopy.org/qa2/qa/upload/ <https://www.openmicroscopy.org/qa2/qa/upload/> I'll be happy
>> to look over the metadata and TIFF structure in more detail.
>> 
>> 
>> Kind regards,
>> Roger
>> 
>> --
>> Dr Roger Leigh -- Open Microscopy Environment
>> Wellcome Trust Centre for Gene Regulation and Expression,
>> College 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 <mailto:ome-devel at lists.openmicroscopy.org.uk>
>> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
> 
> Michael Ellis (Managing Director)
> Digital Scientific UK Ltd.
> http://www.dsuk.biz <http://www.dsuk.biz/>
> michael.ellis at dsuk.biz <mailto:michael.ellis at dsuk.biz>
> tel: +44(0)1223 911215
> 
> The Commercial Centre
> 6 Green End
> Cambridge
> CB23 7DY
> 
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel

Michael Ellis (Managing Director)
Digital Scientific UK Ltd.
http://www.dsuk.biz <http://www.dsuk.biz/>
michael.ellis at dsuk.biz
tel: +44(0)1223 911215

The Commercial Centre
6 Green End
Cambridge
CB23 7DY

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20161201/46275c2a/attachment.html>