[ome-devel] 'Modulo' tag Start/End types

Munro, Ian i.munro at imperial.ac.uk
Fri Jul 29 12:45:50 BST 2016


Hi Stuart

These fields allow a scale to be added to the extra Dimension.
There is therefore no fundamental reason why they should be integers.
My feeling is that this would be very restrictive.

To give an example from FLIM: - the modality that I am most familiar with.
The data stored in the extra dimension has units of time - though not real-time.
Typically data is recorded over 12.5ns so “End” would be 12.5 if  ns rather than ps units were to be used.


Regards


Ian.




Thiere’s no fundamental reason why these fields 
> On 29 Jul 2016, at 00:25, Berg, Stuart <bergs at janelia.hhmi.org> wrote:
> 
> Hi,
> 
> I use Christoph Gohlke's 'tifffile.py' library for interpreting OME-TIFF
> metadata.  One of my users recently reported that tifffile.py chokes on a
> file created by the 'bfconvert' tool[1].  The problem turns out to be this
> tag:
> 
> <ModuloAlongC End="1.0" Start="0.0" Step="1.0" Type="other"
> TypeDescription="TCSPC" />
> 
> The tifffile.py code expects Start/End/Step to be straightforwardly
> convertible to int, not float.  If I understand correctly, these fields
> will always be integers, so they could have been written as Start="1",
> Step="1", etc.  Therefore, it seems wrong for bfconvert to write "1.0",
> right?
> 
> But if you think this is expected output from bfconvert, then I'm happy to
> submit a tiny patch to the tifffile.py repo.
> 
> Best regards,
> Stuart
> 
> [1]: https://github.com/ilastik/ilastik/issues/1289
> 
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel



More information about the ome-devel mailing list