Personal tools
  • We're Hiring!

You are here: Home Community Minutes Mini Group meetings Files ROI discussion proposal

ROI discussion proposal

Roger's doc sent to nitpick

ROI.txt — Plain Text, 5Kb

File contents

ROI Discussion

ROIs in three dimensions

This is just a followup regarding discussion with J-M and Will earlier
today, where we covered the possibility of adding support of 3D
primitives to the model.  (Note that opinions over what to add remain
divided, and this certainly needs further discussion!)  These are just
my thoughts on how we might add initial support.

[Note that for the n-dimensional stuff, I just added it as something
to think about--I'm not suggesting we add any support at this point.]

|2D             |   3D                  |  nD                       |
|Line [2DLine]  | 3DLine                | nDLine                    |
|Rectangle      | 3DCube [Cube]         | nDCube [Hypercube]        |
|Ellipse        | 3DEllipse [Ellipsoid] | nDEllipse [Hyperellipsoid]|
|Point [2DPoint]| 3DPoint               | nDPoint                   |
|Mask           | 3DMask                |                           |
|Path [2DPath]  | 3DPath                |                           |
|Mesh [2DMesh]  | 3DMesh                |                           |
|Text           |                       |                           |

Currently, the ROI model only supports 2D shapes.  In the above table,
additional primitives for 3D (and nD) have been added.  Due to the
"3D" or "nD" prefix, these do not replace the existing 2D-only
primitives for backward compatibility, and to make it clear that these
are for 3D work.  Note that the "nD" primitives would work in 2D, 3D
and higher dimensions; the existing primitives could all be
implemented in terms of nD primitives in the code, but it is useful to
have fixed-dimension primitives in the model.

Some of the 3D primitives described below may appear to be redundant;
it's certainly possible for example, to represent a shape in 3D right
now using multiple shapes, one per z plane.  However, being able to
use native 3D primitives is more powerful: it permits additional
measurements involving volume, surface area and shape.  At a higher
level, the same is implied for e.g. cell tracking in xyzt; being able
to draw a single polyline line (or vector), rather than storing a
single point or line at each timepoint results in us being able to
compute velocity and direction changes directly--rather than having to
compute this information from discrete shapes, the information is
directly available in a single shape.

I've also noted that some shapes may be represented equivalently in
different ways; it might be worth considering adding support for these
because it firstly allows the shape to be computed in different ways,
which can differ depending upon the problem being solved, and it also
contains information about how the measurement was made, i.e. the
intent of the person doing the measuring, which is lost if converted
to a canonical form.

Basic 3D primitives

**3DLine**     List of (x,y,z) vertices.
            Alternative representation: a single vertex and list of

**nDLine**     List of e.g. (x,y,z,t) vertices (tracking movement including
            speed and direction changes). Alternative representation: a single vertex and list of

**3DCube**     X,Y,Z,Width,Height,Depth
            The current representation is effectively a vertex and a
            Alternative representation: Both Rectangle and 3DCube could
            be represented by two vertices.

**nDCube**     Vertex + Vector
            Alternative representation: two vertices.

**3DEllipse**  X,Y,Z,RadiusX,RadiusY,RadiusZ
            This representation is effectively a vertex and a
            Alternative representations:
            - two vertices,
            - vertex + vector
            - single vertex and the Mahalanobis distance [most useful when computing distributions with covariance; enables rotation with n-1 degrees of freedom]

**nDEllipse**  Same as for 3DEllipse alternative representations

**3DPoint**    X,Y,Z

**nDPoint**    X,Y,Z,...


**Mask**       Could we have a pointer to an IFD/file reference plus
            two coordinates so specify a clip region, then we can
            pack potentially hundreds of masks in a single plane.

**3DMask**     As for Mask, but in 3D.
            A 3DMesh could be computed from a 3DMask.


**Mesh**       2D mesh described as e.g a face-vertex mesh.

**3DMesh**     3D mesh described as e.g. a face-vertex mesh.

Meshes could be computed from masks, polygons, extruded shapes where
there is a z range, or from thresholding.


**3DPath**     As for Path, but with additional vector to describe motion
            along the prescribed plane?


To support proper 3D operation, it would make sense to extend the
existing support for 3×3 2D affine transforms to 4×4 3D transforms.
Document Actions