RTstruct not showing contour

Support
1

Hi everyone,

I am using the segmentations module in 3DSlicer v 4.8.0. I have contours that were made in MIM and I am exporting the RTStruct to 3DSlicer. One of the contours is rather small and when I load it into 3DSlicer, it doesn’t show the contour that I can see in MIM. I don’t know why this is and am confident it’s not in exporting the file from MIM as I have other contours that work just fine.

Let me know what I need figure this out, thanks!

2

Hi mmtg,

I can’t think of any obvious reason.

Is there any error in the error log?

Is an (apparently empty) segment created?

Would you be able to anonymize and share the data?

Greg

3

Hi, sorry I am not ignoring your response. I am making sure I have the ethics to send anonymized data. If I were to supply just the RTstruct, would that be helpful (if I can’t send the CT it was generated on)?

2 Likes
4

Yes, absolutely. Getting the RT struct should be enough.

5

I can send the anonymized RTStruct at this point (still waiting for lead PI on ethics of anonymized CT). Who should I send it to? I’d rather not post a link here.

6

You can send it to me: csaba.pinter@queensu.ca. I’m a SlicerRT developer, just as Andras and Greg who answered before. Please make sure that the anonymized dataset produces the samme issue as the original. Thanks!

7

@mmtg Thanks for the data! However I don’t think it is suitable for debugging your issue.

  • The only ROI in the dataset you sent me seems to contain less information than what is enough to calculate the spacing between the contours in itself (see error message “Input polydata has less than two cells! Unable to calculate spacing” - in general it is good practice to look at the log when anything unexpected happens and try to figure out the issue from there, but at least send it to us)
  • Usually the RTSTRUCT comes with a CT, which SlicerRT uses as additional information to determine the spacing. However you only sent the RTSTRUCT, so reading it in happens in a different way than if the CT is also available

Can you please give us more information?

  • What does “rather small” mean for your contours? How many slices do they span?
  • Do you segment a CT? If so, do you export it as well?
  • Please send us a dataset that you actually segmented in MIM (and exported ideally along with the CT), and also send us a screenshot what it supposed to look like

Thanks!

8

Hi thanks for taking a look.

In this case the contour only spanned 1 slice and, on the original CT is probably about 30 voxels or so… Just from memory. One problem is that I think MIM tends to interpolate the volumes heavily and so I am wondering if the coordinates specified don’t actually correspond to any physical space in the original CT… But again that’s just a guess and I am naive in how this works.

The CT is segmented and exported with the RT struct. Both are loaded at the same time.

I will attempt to use one of the sample data sets in Slicer, export to MIM, contour a small volume, and then re-import to slicer to see if I can recreate it. Unfortunately the main PI on this case is away from email and I haven’t got a response about sending the anonymized CT data.

I will hopefully be able to do this monday morning. Thanks for your time so far.

9

In that case please send the anatomical volume too, because loading the RTSTRUCT alone yields a different result.

It’s a good idea to start from a sample dataset to work around patient confidentiality issues. Thanks!

11

Thanks for the new data! I was able to determine the problem. It’s that due to the single-sliceness of the segmentation the contours->surface conversion algorithm is unable to do the “end-capping” step properly, because when it fails to calculate the contour thickness, it defaults to 0mm. So end-capping is done with 0mm thickness, and so while it is done, the surface will remain completely flat (see screenshot; the wireframe shows the end-capping).

image

@Sunderlandkyl will do a fix that sets a default slice thickness to the conversion algorithm for cases like this.

In the meantime you can probably fall back to the “ribbon” method, I’ll provide you a script shortly if I manage to make it work.

1 Like
12

The ribbon method yields a segment that looks nicer and that allows labelmaps to be created. The segment’s volume was calculated to be 0.209cc, which is about half of what you said it is in MIM. This makes complete sense if we consider interpolation (i.e. the aforementioned end-capping, which is performed in this scenario as well), instead of the raw ribbon method.

I had to do one fix in the ribbon converter as well. It required at least two cells in the polydata, but I don’t know why so I decreased it to one (@lassoan any ideas?) and now it works well. You’ll be able to try it with tomorrow’s nightly. Also you’ll need to disable the direct conversion that @Sunderlandkyl is fixing now. You can do it by entering this in the python interactor before loading the data, or adding this to .slicerrc.py. However this is a temporary workaround in case you’re in a rush.

f=slicer.vtkSegmentationConverterFactory()
f.DisableConverterRule('Planar contour', 'Closed surface')

It will look like this:

image
image863×810 80.8 KB

1 Like
13

I guess 2 contours were required so that we can compute slice thickness, but it is better to compute thickness from the CT image anyway.

14

Makes sense. Also the slice thickness calculator function has been significantly improved, so it can calculate it multiple ways. The 2 cell restriction shouldn’t be needed I think. Thanks!

15

Thanks very much for this! I will install the nightly - hopefully my script to batch convert these RTStructs into binaries still works. Glad this worked out!

1 Like
16

The underlying issue has been fixed (Slice thickness now defaults to image slice spacing instead of 0.0).

You should be able to use the default conversions tomorrow in the next nightly, without needing the workaround that Csaba posted.

image
image1255×909 117 KB

2 Likes