Thanks! M
On 12 Aug 2015, at 09:51, Kislinskiy, Stefan <[email protected]<mailto:[email protected]>> wrote: Hi, we had a short discussion yesterday and we totally agree. As Daniel mentioned, there is already a bug in our bug tracker regarding the persistence of geometry information. As our point set file format is based on XML it should be no big deal to add this data. In case this data is present in the file, MITK should use it in future. However, to keep compatibility, we should make the handling of geometry information optional, i.e., implement it as a reader/writer option. Otherwise there would be some code in the wild that applies the transformation twice. We also agree to the point size issues. Furthermore, the 3D mapper should be extended to provide a kind of fast mode, in which points ar really rendered as points instead of turtle-speed VTK spheres. Michael and Eric will work on the latter today as they coincidentally planned to do it anyways. :) Best regards, Stefan From: Clarkson, Matt [mailto:[email protected]] Sent: Mittwoch, 12. August 2015 10:01 To: Daniel Maleike Cc: MITK Subject: Re: [mitk-users] PointSet geometries (I/O & glyph rendering) Hi Daniel, Short Answer: I agree with you. I hope I understand things correctly. The thing that causes us most problems is the fact that PointSets do not maintain/restore their geometry when saved and loaded. The PointSet has a “natural” coordinate system, in which the positions are specified as x,y,z, a bit like the index[x,y,z] of an image. The Geometry is applied, which means to take each point, multiply by a transform, and plot it. So, the visualisation of the location looks in the correct position. We use this for point markers in IGT type apps. We do not currently use anisotropic points. The rendering of the PointSet should not depend on geometries in other images or other objects. If anisotropic PointSets were to be supported, i would imagine that perhaps a spacing of (1,1,3) should express relative scale, and then any “size” unit should be in world coordinates. These should be rendered in consistent size in 2D/3D. If we support anisotropic points, then the size property must also be a 3-vector. I think diameter is better than radius. In terms of saving/restoring the object, as we do not use anisotropic points, we have a work-around that simply multiplies each point by the geometry and saves it. So, the output PointSet has the Identity transform as its Geometry, and the position of the actual points change. This is not ideal, as you then cannot restore any anisotropic information should you require it. (i.e. glyph orientation would be lost). We also notices that the performance of loading/saving/rendering large (e.g. 600,000 points) is unsurprisingly poor! The loading and saving performance is poor due to verbose XML/ASCII, and the rendering performance is poor/unworkable due to rendering a sphere at each point. This is totally not surprising, as PointSets were presumably never meant to be this big. So, of more interest would be a new data type that stores X,Y,Z location and RGBA for each point, and is JUST rendered as a single OpenGL dot. This would be useful for visualisation of densely reconstructed point clouds! But thats another story. Hope that helps. Matt On 11 Aug 2015, at 10:25, Daniel Maleike <[email protected]<mailto:[email protected]>> wrote: 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): <fgbicfhc.png> Example for the same "size" property in 2D / 3D (in 3D we get 2x the size as in 2D): <idghbigj.jpg> -- 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]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
