[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