MetaScene
MetaIO was created not only to store images and isolated objects (meshes, masks, arrows, etc), but to also arrange and physically couple them into a scene.
In a MetaScene, a metaObject can be assigned to be a child of another metaObject, and each object has an object-to-parent transform that also applies to all its children - forming a transform tree that allows subtrees to be rotated/translated, etc in space.
Object-to-Parent Transforms...except metaImages...
For every metaObject, the object-to-parent transform is stored in the TransformMatrix, Offset, and CenterOfRotation variables. However, for metaImages, there is also the transform that maps i,j,k space of voxels to physical space. Originally MetaIO stored that i,j,k to physical space transform in the TransformMatrix, offset, and CenterOfRotation variables - and the object-to-parent transform wasn't supported, and so subtrees that had an image as their subroot couldn't be rotated, translated, etc and intervening GroupSpatial objects had to be inserted into the trees to provide the functionality.
Proposal
I am proposing to introduce ElementDirection and ElementOrigin to the metaImage class definition (note that metaObject class already has an ElementSpacing variable which is unused in all but the Image class). ElementDirection, ElementOrigin, and ElementSpacing will mimic the definitions of Direction, Origin, and Spacing of an itkImage. They will store the transforms from i,j,k to physical space, so that TransformMatrix, Offset, and CenterOfRotation can be used (as intended) for the object-to-parent transform.
Backward compatibility
Backward compatibility is maintained as follows:
-
If ElementDirection, ElementOrigin, and/or Spacing are not specified (as currently/originally done in MetaIO files), then the TransformMatrix, Offset, CenterOfRotation, and ElementSpacing variables are treated as originally/currently defined: as i,j,k to physical space transform specifications. This applies for these variables individually: so if ElementDirection alone isn't provided, then TransformMatrix is used instead.
-
If one or more of ElementDirection and/or ElementOrigin is provided, then the new definition is used for those specific variables. For example, if ElementDirection is specified, then it is used for the i,j,k transform and TransformMatrix is used for the object-to-parent transform when the image is part of a metaScene.
The good and the bad
- All existing metaScene and metaImage (.mhd/.raw and .mha) files will still work as they do now when read by new code after these changes.
- When an stand-alone metaImage file is written using the new code, we propose to default to using the old (current) format so that old programs can read them correctly.
- Only when metaScenes are written and they include a metaImage, then that embedded metaImage will use the new format and the metaScene will support object-to-parent transforms for all metaObjects.
- Broken Backward Compatibility will happen when an old program reads a new metaScene file - the old/current MetaIO code will report (provide message, not an error) that ElementDirection, ElementOrigin, and Spacing are defined in the file, but they are undefined in the program.
- very few programs currently read/write metaScenes, so this isolate break in backward compatibility will have limited impact.
- These changes will produce a more consistent definition and behavior for metaScenes, so the break is worth it.
- We will also introduce a versioning scheme for metaObjects, so that file format updates can be handled / flagged correctly in the future.
Thoughts?
@thewtex
@hjmjohnson
@zivy
@N-Dekker