Interpreting Pixels SizeX and DimensionOrder when using the

[Simon Carter]

I’m generating some tiff images which have use the tiff orientation tag (tag id 274) to indicate that the image should be interpreted as rotated, with a value of 8 where the 0th row of data represents the visual left-hand side of the image i.e. x = 0, and the 0th column represents the visual bottom i.e. y = 0.

One of interpreting this is with a DimensionOrder of YXZCT, although that applies to planes rather the actual 2d array of data in a single tiff image - and is not allowed anyway.

Should Pixels.SizeX be the length of each row of data in the tiff image or the actual number of pixels in the tiff image in the x direction?

Similarly, does PhysicalSizeX refer to the real world x pixel size or the size of the pixels in the direction of a row?

[rleigh]

Hi Simon,

In the OME model, the x,y origin (0,0) is defined as the top-left of the image plane(s). No rotation is performed on the image data, for example with EXIF data. For the TIFF orientation tag, whether automatic rotation is done may be dependent upon the TIFF library used--depending on this feature is discouraged due to its unpredicatability; it is recommended to store the image planes in the "correct" orientation, i.e. x is along rows, y is along columns, so that the sizeX is the pixel count along a row, and the sizeY is the pixel count along a column. With these constraints, DimensionOrder is always "XYxxx".

Regards,
Roger

[Simon Carter]

Hi Roger

I appreciate that support for the tiff orientation tag is patchy at best. We provide it as an option; our instruments can easily generate well over 50Gb of tiff data in 20 minutes. Without using the orientation tag the total scan time and / or memory requirements increase enormously.

In many cases whether a library supports the rotation tag is irrelevant; the analysis of the image does not depend on the orientation unless seeking absolute location-dependent features.

In the OME model, the x,y origin (0,0) is defined as the top-left of the image plane(s)

Ah.. I should have read the spec more closely. This then implies that use of the rotation tag is not consistent with the OME model.

Should Pixels.SizeX be the length of each row of data in the tiff image or the actual number of pixels in the tiff image in the x direction?

Similarly, does PhysicalSizeX refer to the real world x pixel size or the size of the pixels in the direction of a row?

If I am using the rotation tag and want to make the OME-XML as compliant as possible, then the question still applies. Would it be better to use SizeX to represent row length or image size? And what about physical size? Which do you think would we the least likely to cause issues?

Thank you very much for your assistance - I realise that I'm a bit off-piste here. The history is that we develop instruments which can generate tiff images as a secondary output, there is a desire to include some meta-data in those tiffs and the OME-TIFF standard largely fits the bill. It would be daft to invent our own standard when OME exists.

Simon

[rleigh]

Note that the dimension ordering is currently restricted to these values:

<xsd:restriction base="xsd:string">
<xsd:enumeration value="XYZCT"/>
<xsd:enumeration value="XYZTC"/>
<xsd:enumeration value="XYCTZ"/>
<xsd:enumeration value="XYCZT"/>
<xsd:enumeration value="XYTCZ"/>
<xsd:enumeration value="XYTZC"/>
</xsd:restriction>

This implies that you can't have YXxxx ordering. In consequence the X and Y dimensions must correspond to the width and height of the pixels in the image planes. This means that SizeX must be equal to the number of pixels in an image row (i.e. width), and SizeY must be equal to the number of pixels in an image column (i.e. height), irrespective of the physical orientation. The physical sizes must apply to the same dimensions as well.

I hope this answers the question.

Regarding the expense of rotation during acquisition. You could, if you can spare a second buffer, do a very quick copy to rotate. Or you can copy in-place using in-place matrix transposition (at the expense of being a bit more expensive in CPU time). I imagine this very much depends on the speed of data acquisition, but the time should be in the order of milliseconds, so should be possible.


Regards,
Roger

[Simon Carter]

Roger, thank you for your assistance - that does answer the question.

Transposing the matrix is an option - in fact we do so if the user elects not to use the orientation tag - but it has its own difficulties and would be a shame to disable OME meta data generation in the case where the user does use the orientation tag.