I loaded different DICOM series that already have contours that need some editing. First problem is that the loaded contour is broken sometimes like in this pictures:
First I thought is just something visual in 3d Slicer that will not affect me, because I export the files to DICOM after finish the work, but when I looked at the contour in other software, the contour is really broken for body.
Another problem would be that when I draw an additional contour that wasn’t marked before (e.g. Esophagus), it removes the BODY contour in the place where I draw the esophagus.
With esophagus and body visible:
With only body visible:
The gap is obvious. And also checked that in another software and body looks like this:
It may be either invalid input data or a software bug. Which Slicer version do you use? Can you share the data set (upload dropbox, onedrive, etc. and post the link here)?
One thing that I noticed now playing with 3d Slicer now is that there are issues with DICOM export. I use the last version of the software, and I switched also to the preview version. The idea is that: if I have a CT scan, I edit it or add structures and then export it, the already existing structures in the original DICOM files are sometimes broke.
To give an example, if I have a CT with lung contour and I load it in 3d Slicer, it looks great, after that let’s say that I add a new structure spinal cord, and export the new DICOM files. If I load these new files to 3d Slicer, then the Spinal Cord I draw looks perfect, but the old lung gets some problems. It’s an intuition based on some experience with the application, nothing proved.
Do you have the same problem with the loaded structures in the 3D view? Sometimes the 2D display of certain surfaces have this issue. By default, the 2D display of structures shows the labelmap not the surface, but it’s good to make sure.
As I said it is a 2D display issue, so if it is the thing I asked about, then your export will not have this problem.
There are two things you can do to verify:
Make the segmentation semi-transparent (that’s your way to “have access in the middle of the 3D volume”) and see if there are lines or not
Make sure the 2D views are showing the binary labelmap. If what you have is what you see in this screenshot then the problem is with the data or it is an import bug as @lassoan suggests.
I don’t think it is a data problem, because I viewed this data in other software and also with matplotlib in python and there everything it’s ok.
The problem persist in the software and in the exported DICOM files from 3d Slicer.
Basically the simples example, if I load a DICOM series (that doesn’t have any problem because I verified) and export exactly the same series from 3d Slicer to DICOM, and the view it with matplotlib, the problem is appear.
About your question regarding 3D view, as you can see in this picture, the problem persist on 3D view also:
Also regarding setting representation for 2D views on binary labelmap, the software doesn’t allow me to do set “binary labelmap”, I see the option, I click on it and nothing happens.
It seems that the labelmap to contour conversion in Plastimatch fails if the contour goes outside (or touches the boundary) of the reference CT image.
First you need to create the “binary labelmap” representation by clicking on “Create” button next to “Binary labelmap” in the Representations section in Segmentations module.
The data set contains an extremely high number of contour points (in many cases about 1500 points per slice), so the conversion can take 5-10 minutes.
@gcsharp This RTSTRUCT was generated by Plastimatch, so maybe you can help with these questions:
Is it a known limitation that if the contour touches the reference CT edge then the contour points will be discarded? Does this occur with the latest Plastimatch version?
The contours contain many points (about 1500 per slice in many cases). Doesn’t this cause trouble in treatment planning systems? Could an option be added to decimate the contour polyline (e.g., with a filter like this)?
No I’m not aware, thank you for investigating. Do you already have an example data set that I could use for testing?
It could cause problems in some cases. There is already code for segment decimation, but it could be improved. The most user friendly approach is probably decimating to a fixed limit (e.g. decimate to maximum 500 points per contour). Also probably best to make this behavior it optional. Your thoughts?
@Fabian_Jichi Do you still have the segmentation in labelmap or segmentation format that you used as input for the RTSTRUCT export (that generated the files that you shared)?
I would try vtkDecimatePolylineFilter or similar filters in ITK (if there is any) to see how well they work on these contours. If they work well then they could be used to Plastimatch to simplify the contour. The stopping condition for decimation should be ideally some kind of maximum error metric instead of maximum number of points.
