Hi Matt, hi Stefan,
thanks a lot for your feedback. Especially Matt, your formulations
around "anisotropic points" made me realize that people might think
about something like that. I never considered that but always understood
the positions as the only information that is contained in a point set,
i.e. I saw no point size in the data themselves (but only in the visual
representation). I see that a point size/scale/orientation could also be
of interest, but this is well out of the scope of what I was trying to
change/fix here :-)
Given that we agree on how things should be, I'll try to
- adapt 2D display to what we discussed
- add geometry information to the pointset file format (falling back to
identity if missing, this imitates current behavior)
- figure out how to change the 3D mapper
- (package changes into Bugzilla tickets and publish git commits)
Since Michael and Eric are working on the 3D mapper, I'll not touch it
too much but I'll contact them directly to see how to coordinate our work.
Kind regards,
Daniel
On 12.08.2015 10:51, Kislinskiy, Stefan 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.
--
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
