Problems with OME TIFF reading

[stuarteberg]

From a user, submitted via team@ilastik.org:

after converting my image to .ome.tiff with the latest bfconvert, I have problems reading it with ilastik. ImageJ reads it just fine. Could you please have a look at it?

He also attached a sample file. Search team mailing list for subject "Error reading .ome.tiff"

[stuarteberg]

I don't have a solution yet, but I think the XML produced by bfconvert is technically invalid. In @maierl's OME-TIFF file, the following tags appear near the end of the OME header:

<XMLAnnotation ID="Annotation:11" Namespace="openmicroscopy.org/omero/dimension/modulo">
   <Value>
      <Modulo namespace="http://www.openmicroscopy.org/Schemas/Additions/2011-09">
         <ModuloAlongC End="1.0" Start="0.0" Step="1.0" Type="other" TypeDescription="TCSPC" />
      </Modulo>
   </Value>
</XMLAnnotation>

The problem is that Start="0.0" should be Start="0" and so on. We use the tifffile.py library to interpret tiffs, which seems to assume that Start is always an int, never float. As far as I can tell from OME examples, that's correct according to the standard. For example, Start="1.5" would make no sense in this context. I admit I can't find it mentioned in the official schema, though.

[stuarteberg]

Update: Apparently this is expected behavior for bfconvert1. Therefore, tifffile.py needs to be patched. I've submitted a pull request to the official semi-official mirror of the tifffile repo.

But we don't have to wait for it to be accepted. I've updated our conda package for tifffile to use our own fork+branch of tifffile.py, and updated ilastik's TIFF-reading code to be compatible with it (ilastik/lazyflow@bac6be6).

Therefore, this particular OME-TIFF reading issue will be resolved in the next release. (I'm able to read your example file, anyway.) Hopefully there aren't any other special cases missed in tifffile.py. If so, we'll open a new issue when we discover them.