Hello,
I am working on an application that uses mitk::PointSets and observed
some inconsistencies that I'd like to discuss before proposing any changes.
(I am sorry that this mail got rather long, but I am touching multiple
aspects)
My question is: how are geometries / transforms _intended_ to apply to
point sets and their visualization?
- Should point positions be transformed via the PointSet's geometry?
- I'd say yes, as for all other objects
- Should PointSet geometries be part of a PointSet file?
- I'd say yes, as in useful image formats. I'd have a preference to
store the geometry explicitly.
- In what unit shall the size of the rendered point glyphs be specified
(there are unspecified "size" properties)?
- I'd say world units but I see that this could depend on the
application (keep non-isotropic voxels in mind)
- I'd say the "size" is a diameter, not a radius
- What transformations shall be applied to glyphs?
- I'd say they must be generated at the correct world positions,
have a selected shape (e.g. sphere) in the world system (see "size")
Anybody, but esp. the MBI team: do you agree with my opinion? Do you
have an alternative version?
I'd like to update at least some documentation and ideally improve some
of the current behavior.
To provide motivation and context for my questions I summarized the
current state of display and I/O below. In this current state it seems
not completely consistent to me.
Looking forward to your comments,
Kind regards,
Daniel
= Current state of PointSet rendering and I/O =
3D visualization: Geometry is applied, transforms points "into world"
- both position and shape (spheres become ellipsoids unless isotropic
spacing)
- transform taken from BaseData
- "pointsize" is used as _radius_ of the spheres before transformation
(i.e. index size)
2D visualization: Geometry is applied, transforms points "into world"
- as in 3D, glyph positions and shape are transformed
- _positions_ transformed via BaseData transform
- glyphs are transformed for orientation via the render window(!) geometry
- however this is implemented in a way that takes orientation _and_
scaling
(fix locally available)
- "point 2D size" is applied as a _diameter_ (if I am getting it right)
Readers/Writers: geometry completely ignored, will be lost after saving
and re-loading
(already described as http://bugs.mitk.org/show_bug.cgi?id=16115 but bug
seems inactive)
= Consequences for current PointSet usage =
When applying a non-isotropic geometry (say spacing 1,1,3) to a
PointSet, I'll have the following effects:
- "circle" markers (as others) are displayed as ellipsoids in 2D and 3D,
show potentially different sizes
- unacceptable for users, esp. since sizes change in function of
co-loaded images
- when I save the points to file and re-load, I get a changed position etc.
- generates surprises for users, this is not expected
Usage that works better but feels like a workaround: don't attach a
specific geometry to PointSet, keep default identity transform:
- 2D display of markers still depends on "world geometry", e.g. _the_
image when only one is loaded
- i.e. 2D marker shape changes in function of other displayed images
- 3D display is fine and independent of other images, just "size"
property is interpreted differently
- save and load: correctly restored because we used the default
geometry, cannot loose anything
Example for "deformed" points (spacing ~ 1 1 3):
Example for the same "size" property in 2D / 3D (in 3D we get 2x the
size as in 2D):
--
Dr. Daniel Maleike, Mint Medical GmbH
Friedrich-Ebert-Straße 2, 69221 Dossenheim/Heidelberg
Geschäftsführer: Dr. Matthias Baumhauer, Registergericht Mannheim, HRB 709351
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
