OME (ROI) Coordinate System


I think I will start with the question and then give detail: is there a coordinate system in which OME ROI information (or transformation matrices) are assumed to be?

For example, if you provide a physical size for a light sheet dataset with dimensions 500x500x100 but physical sizes 1x1x2nm and then an Point ROI for say the middle of the volume (I don’t think this is possible with the given OME schema but just for this example), how should that ROI be stored? Would it be stored at location (500,500,50) (i.e the middle of the pixel coordinates)? Or would it be stored at (500,500,125) (the middle of the “scaled” physical coordinates of 500x500x250 where every “pixel” now corresponds to a 1x1x1nm sized chunk of physical sample)?

@nheathpatterson I think we dealt with something similar in 2D image registration and the conclusion was that the optimal route was that things like translation should happen in the “physical coordinate” system (so the later), no? So if you specify a translation, its a translation by nm (for example) not pixels.


1 Like

Hi Ilan,

OME ROIs are collections of 2D Shapes (X and Y are floats, using pixel coordinates) with each Shape optionally associated with a particular Z or T index (integers).
A 3D volume can be represented by an ROI with a stack of Shapes, one per Z section, but the Shapes can also be used in other ways (there’s no validation of 1 per Z section).

So for a Point in the middle of a volume of 500 x 500 x 100 pixels, you can have X:249.5, Y:249.5 and theZ: 50 (which isn’t exactly midway between the first and last Z-sections).
See Point at Schema documentation for ome.xsd

A Shape can have a 2D Affine Transform (6 values) which is in Pixel space.