that directly converts a 2D Planar Contour to a 2D Binary Labelmap (and if I have more than 1 slice, that will become naturally 3D), without the overhead of triangulating a closed surface as intermediate step, etc. There was some related discussion here Convert binary label map into 2D contours (ideally splines) and back - #4 by cpinter but I thought not to necro-bump an old thread.
My reason is that I have hundreds/thousands of datasets (I cannot change) all using Planar contours (RTstruct.dcm format) as representation, and I just want to extract the binary labelmap (and doing this quickly matters for my application), not visualize them as closed surface. Contours are exactly aligned with CT slices, so they can be treated independently and fully parallelized, unlike if you try to reconstruct a 3D surface.
Currently, my workaround is to use in my C++ project a parallel-for loop for each slice, reading the slice 2D contour, and calling vtkPolygon::PointInPolygon for each pixel to fill the matrix.
The reason for going via closed surfaces is not the need of visualization in 3D, but as an intermediate step towards converting to labelmap. This is a very hard geometrical problem, so I don’t suggest jumping headfirst into it, because it already took two masters projects and it’s much more complex than it seems. See paper
Thanks Csaba for the prompt reply and the link to the paper.
The paper states: These structures must be converted into 3D meshes in order to be visualized or to be used for treatment planning and further analyses.
Maybe I should frame the conditions of my problem differently: the contours of all these datasets are manual 2D contours done by hand. So for this specific type of input, it makes less sense to me to try to go to 3D as intermediate step in order to convert to a 2D labelmap.
Since what the physician is actually doing is drawing a 2D labelmap with his mouse on a CT slice. This is why simply the function vtkPolygon::PointInPolygon works rather well for my specific application of creating a 2D labelmap.
In my mind, that would simplify the issues commented in this paper:
One issue that needs to be solved by all triangulation algorithms is determining which contours should be connected by triangles between each of the slices. This is referred to as the correspondence problem. Another obstacle to overcome is the occurrence of branching contours. A branching contour occurs when a single contour on one of the slices must be connected to two or more contours on an adjacent slice.
The issue though that has to be dealt with in the independent 2D problem is the other one:
Another issue that can occur is the existence of keyholes within the set of contours. The DICOM standard (RT structure set module) defines the storage of hollow structures as keyholes that are represented as an inner and outer contour connected by an arbitrarily small channel in order to be considered one contour.
I haven’t re-read the paper but as I remember the main purpose for the triangulation was to facilitate interpolation between the slices (avoid the staircase effect). Handling the different special cases is harder with surface meshes than with labelmaps, I agree.
We have another conversion path, via ribbon models. If you go to the Segmentations module and click Update in the Representations section for Binary labelmap, and choose the path via Ribbon models, you’ll see how the output changes.
If you use this path via ribbons would it help? I’d argue that it is basically what you want, if I understand it correctly.
And if you need better interpolation, we could use the algorithm that is behind the Fill between slices Segment Editor effect.
I have never seen keyhole artifacts in output ribbon representation. For closed surfaces this is an issue because you don’t want to see those faces connecting the outer and inner ends of the keyholes. For labelmaps this is not an issue, because the width of the keyhole is much smaller than the voxel size.
Feel free to create a new conversion rule if you see the need. However, if all you need is the simple 2D polygon to labelmap, you have it with ribbons. The SlicerRT community only had that for a few years (before the new segmentations infrastructure and the planar contours to closed surface algorithm) and no problems were reported.
I do see artefacts sometimes when I turn on the ribbon model representation, but maybe those are visualization glitches or rounding errors on my computer?
The contour in this case is simple, when plotted with excel is just a circle.
The glitch disappears if I use closed-surface or binary labelmap. If I choose for planar contour, the contour is simply just not drawn in 2D but yes in 3D. Maybe rounding error in z coordinate to know if it is on that plane?
These are due to a 2D visualization issue. Unfortunately it is not uncommon that vtkPlaneCutter in vtkMRMLSegmentationsDisplayableManager2D fails to give correct result. This occurs when you have a polydata type representation selected for slice visualization for your segmentation. If you change it to labelmap (Segmentations / Display / Advanced) then you’ll see the correct slice display.
