Open Microscopy Environment

Dear all,

We are currently exploring OME-TIFF as a file format for allowing our users to load their data into ImageJ. Incidentally, it seems like OME-TIFF could then also be a great general data interchange format for compatibility with other applications, plus an ideal format for data archival.

The data in question is basically that from a laser confocal scanning microscope. One important mode of operation for this instrument is the creation of kymographs: continuous scans along a line, building up a kymograph — a picture with one spatial axis, and one time axis (basically a picture with line scans 'stacked' on top of each other).

When exporting a kymograph to OME-TIFF, ideally I'd like to do the export as one 2D image per channel. Is there a recommended way to do this in OME-TIFF?

My current implementation is to use

• the "XYZCT" DimensionOrder (as "XTYZC" does not exist);
• the "X" axis for the spatial axis, with SizeX=100 (say, for a line scan of 100 pixels), PhysicalSizeX=100 (say), and PhysicalSizeXUnit=nm;
• the "Y" axis for the time axis, with SizeY=200 (say, for 200 line scans), PhysicalSizeY=200, and PhysicalSizeYUnit=pixel;
• add one IFD per channel, where the image is the kymograph.

Would this be OK, or would there be nicer ways to solve this that I have overlooked?

Thanks a lot in advance!

Yours sincerely,


Onno

Hi Onno,

You are correct that the OME model and its implementation are currently XY-plane based. On the kymograph front, OMERO implements exactly the strategy you propose in its Kymograph script i.e. it uses an XY plane to store the spatio-temporal pixel intensities along a set of polylines. Exporting the resulting Image into an OME-TIFF file should match the layout you describe below.

For multi-channel kymographs, you should be able to use store each plane in a different IFD and define their dimensionality via the TiffData element.

One obvious limitation is the loss of the TimeIncrement unit. For now, it should be possible to preserve this metadata using a dedicated annotation.

Best regards,
Sebastien

Thanks, Sebastien, that's very helpful. I will keep my current implementation as-is then!

Best regards,


Onno