Coordinate system and origin

[ajpatterson]

Moved from ​http://www.ome-xml.org/ticket/109

It might be beneficial to store the coordinate system, origin or other geometry associated with acquisition that we do not currently have a place for.

[rleigh]

I think this could be achieved through a generalised set of affine transforms expressed either as individual transforms for translation, scaling and rotation or composed together and/or multiplied with other transforms. This would require:

• a means of defining a transform
• a means of composing a transform
• rules for combining the transforms

Thoughts:

<affinetransform>
  <rotate xy="45" xz="23" yz="15"/>
  <translate x="5" y="7" z="44"/>
  <scale x="0.2" y="0.2" z="4"/>
  <matrix="1 0 0 0
           0 1 0 0
           0 0 1 0
           0 0 0 1"/>
</affinetransform>

Within the <affinetransform>, individual transforms are multiplied together in order to result in a single transform. At the level of the implementation, these can map directly to language types e.g. glm::mat4.

Common uses:

• Translation to global position from image position e.g. (0,0) in image => (234982,-827291) stage/slide/plate position
• Rotation of image to global position from image position e.g. 0° => 23.423°; the generic transformation can cope with rotation about any origin when combined with translation (i.e. translate*rotate*translate).
• Scaling of image to physical dimensions from pixels (this would be implicit by default from the PhysicalSize? attributes, but could possibly be overridden if PhysicalSize? was unspecified)

We may wish to have transformations attached at multiple levels in the data model.

Example: plate data:

• Plate: define global origin and physical plate dimensions
• Well: translation to well centre from plate origin
• Field/Image?: translation to image field origin from well centre, plus any additional rotation and scaling to the global scale
• Plane: per-plane adjustments from the image origin; most likely use is post-acquisition adjustments, or adjustments applied during acquisition as deviations from the desired position (i.e. expected->observed location), or to correct for e.g. channel mis-registration.

Example: Tiling:

• Related images in a set of tiles can be transformed from individual local coordinates into the same global space to allow visualisation.
• Image-image metadata or grouping of related images into a set would provide information about which images are in the same global space (i.e. same slide/well/sample).

Example: rendering:

• this will allow the visualisation of image data using e.g. OpenGL where we can use this as part of the input into a MVP (model-view-projection) matrix to go from local pixel space -> global physical space -> 2D projected space on the screen.

Example: plate overview:

• whole plate overview using well transforms and field/image thumbnails.

[rleigh]

If we allow attachment of transforms at different positions in the hierarchy, these would naturally multiply together as you go deeper into the hierarchy to stack up the transforms, e.g. if we have (P)late, (W)ell, (F)ield and (p)lane transforms, then the transform for an individual plane would be p*F*W*P.