Hi Daniel, We implemented an fast OpenGL based vertex rendering mode for PointSets that can be enabled via properties. There are still some features missing. But it should finished soon.
Cheers, Eric Von: Daniel Maleike [mailto:[email protected]] Gesendet: Freitag, 14. August 2015 13:35 An: MITK Betreff: Re: [mitk-users] PointSet geometries (I/O & glyph rendering) 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
