ooooooh. Thanks. I will take a look. Matt
> On 12 Aug 2015, at 12:02, Kolb, Christoph <[email protected]> wrote: > > Hi Matt, > > about the pointset rendering: > I also wanted to render large and dense colored pointclouds in mitk and it > took me a long time to realize that this functionality is actually included > in mitk! > You can create a vtkPolyData and assign colors as in this example: > http://www.vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ColoredPoints > Add an additional component to the UnsignedCharArray if you want RGBA > colors. > Now it can be put in a mitk::Surface and rendered in mitk. The colors are > shown when the "scalar visibility" property is on. > > I have just tested it with 600.000 points: > saved as a .vtp file it has 13MB. Loading and saving is accordingly quick > and the rendering seems to be smooth. You can test this yourself by using > my attached example code. > > Regards > Christoph > > > On Wed, 2015-08-12 at 10:00 +0200, Clarkson, Matt wrote: >> 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]> >>> 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] >>> https://lists.sourceforge.net/lists/listinfo/mitk-users > <testps-code.txt> ------------------------------------------------------------------------------ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
