The OME Data Model defines a Shape.Transform element with an AffineTransform type that is used to transform a Shape’s position in the image in various ways: scaling, rotations and more. These transformations are performed within the two dimensions of the image’s x, y plane. In order to properly locate a Region of Interest (ROI) on an image any geometric transformations of its Shapes must be taken into account.
The OME Data Model’s AffineTransform defines the elements of a transformation matrix,
where the attributes’ geometric meaning is,
The accompanying graph shows an example translation of in x and in y. The above representation of affine transformations reflects a common approach in computational geometry and works well.
In OMERO 5.2 the
property uses a single string to represent transformations. Historically
a variety of formats have been used for this string, most from the World
Wide Web Consortium’s Scalable Vector
(SVG), anything from
"rotate (12.000 262.000 174.000)".
must thus bear the burden of parsing the possible string formats simply
to be able to determine a ROI’s position on the image. From the example
illustrated in the previous section, given a Point at (40, 85) with
"translate(35 -65)", that Point should be understood to be
located at (75, 20) in the image.
The database upgrade script from OMERO 5.2 to 5.3 will include a parser written in PL/pgSQL that moves these string-based Shape.transform property values of existing ROIs to a new OMERO model object, AffineTransform, whose properties mirror the numeric attributes of the corresponding OME-XML element.
From OMERO 5.3 a Shape that does have an associated transform thus has the named matrix elements A00, A10, A01, A11, A02, A12 conveniently available to OMERO clients as floating-point numbers. This makes it far easier to write clients that properly take account of how a ROI’s Shapes have been transformed.
The OME Data Model and Bio-Formats remain unchanged in regard to affine transformations. However, the above constitutes a breaking change for OMERO users. We do not make such changes lightly.
It is highly likely that existing client code that works with OMERO
5.2’s SVG-based Shape.transform property strings already translates them
to fit the properties of the new OMERO AffineTransform model object.
Such code may parse the
"matrix(a00, a10, a01, a11, a02, a12)" SVG
format or use transformation matrices in its actual calculation or
display. For example, in adapting some of our Java code for OMERO 5.3 we
found that the AffineTransform object’s properties directly correspond
to properties of the
Java class that we use already. We are therefore optimistic that, while
some ROI-related code does have to be adjusted, it will be a relatively
easy process that leaves the code clearer and simpler.
— June 20, 2016