vtkPlanarContourToBinaryLabelmapConversionRule

I am interested in creating a variant of SlicerRT/DicomRtImportExport/ConversionRules/vtkPlanarContourToClosedSurfaceConversionRule.cxx at master · SlicerRt/SlicerRT · GitHub

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.

But I thought it’s maybe wiser to profit/reuse the more advanced handling of keyholes of SlicerRT/DicomRtImportExport/ConversionRules/vtkPlanarContourToClosedSurfaceConversionRule.cxx at master · SlicerRt/SlicerRT · GitHub for which maybe PointInPolygon is not prepared to deal well with if not preprocessed.

I’d be happy to hear comments / suggestions from @Sunderlandkyl @lassoan @cpinter

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

Reconstruction of surfaces from planar contours through contour interpolation

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.

which I agree is a hard geometrical problem, but I still do not see the need to go to a 3D problem to solve it (which also prevents parallelization for each slice). Here a related discussion: https://stackoverflow.com/a/218081/7471760 GitHub - Aditi1993/Point_in_Polygon: Application can tell whether a point is inside or outside a complex polygon with holes. · GitHub Determining Whether A Point Is Inside A Complex Polygon

Maybe the GitHub - AngusJohnson/Clipper2: Polygon Clipping, Offsetting & Triangulation in C++, C# and Delphi · GitHub library that @lassoan mentioned some time ago could be useful in this regard to be able to process the CLOSEDPLANAR_XOR 2D contour types.

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.

Thanks for the reply!

Yes, I first thought so, but then I noticed that