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
vtkSmartPointer<vtkPointSource> pss =
vtkSmartPointer<vtkPointSource>::New();
pss->SetCenter(127, 127, 127);
pss->SetRadius(127);
pss->SetNumberOfPoints(600000);
pss->Update();
vtkSmartPointer<vtkPolyData> ps = pss->GetOutput();
vtkSmartPointer<vtkUnsignedCharArray> colors =
vtkSmartPointer<vtkUnsignedCharArray>::New();
colors->SetNumberOfComponents(4);
colors->SetName ("Colors");
colors->SetNumberOfValues(ps->GetNumberOfPoints());
for(vtkIdType id = 0 ; id < ps->GetNumberOfPoints() ; ++id)
{
double pt[3];
ps->GetPoint(id,pt);
unsigned char col[4];
for(int d = 0 ; d<3 ; ++d) col[d] = (unsigned char)std::floor(pt[d]);
col[3] = col[0];
colors->InsertTupleValue(id,col);
}
ps->GetPointData()->SetScalars(colors);
vtkSmartPointer<vtkXMLPolyDataWriter> writer =
vtkSmartPointer<vtkXMLPolyDataWriter>::New();
writer->SetFileName("testps.vtp");
writer->SetInputData(ps);
writer->Write();------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
