I have segmented label maps from two imaging modalities (3D ultrasound and MRI), and have performed a registration and transformation between them. When the Hausdorff distance option is clicked in the DiceComputation module I get numbers in the results matrix. However, with the Dice option clicked, clicking the Compute button doesn’t do anything. Any suggestions?
You can also try Segment Comparison module in SlicerRT extension. It computes both Dice and Hausdorff.
I tried the DiceComputation extension and it worked fine for me with two labelmaps generated from the same source volume (using the legacy editor on the MRHead from SampleData). @aharris perhaps your volume data is not in the same pixel space and needs to be resampled. Check in the error log for clues.
Segment comparison module in SlicerRT extension takes care of all transformations and resampling. It works on segmentation nodes, if you have labelmaps or models then you can convert them into segmentation using Import section of Segmentations module.
This worked, thanks!
Dear Slicer users,
I post here to not open a new discussion.
I just try to use the Segment Comparison module in SlicerRT, but the calculated Dice coefficient is always 1. I’m using latest Slicer nightly on macOS.
How can I resolve this problem?
Thanks a lot.
P.s.: I also cannot find on slicer extension manager the DiceComputation extension, which I would like to try.
Based on your screenshot the two segments do not overlap, so the calculation based on this is correct.
In order to have two segments that have overlapping parts and meaningful dice, you need to either
- Enable overlapping in Segment Editor before drawing the second segment, or
- Use different segmentations for the two regions
DSC should be 0 if there is no overlap, so indeed there is something wrong here.
@Sunderlandkyl I suspect that Segment Comparison module was not updated to handle merged labelmaps. Could you please check if this and other SlicerRT modules use the correct API for getting labelmap representations?
OK, I need to re-compile SlicerRT and then I can submit a PR.
Most of the modules in SlicerRT seem to be fine, except for a couple (SegmentComparison, RoomsEyeView, SegmentMorphology) that use vtkSlicerSegmentationsModuleLogic::GetSegmentRepresentation() / GetSegmentBinaryLabelmapRepresentation().
I can fix this in SegmentComparison (and vtkSlicerRoomsEyeViewModuleLogic) by getting the individual non-shared labelmap with vtkSegmentationNode::GetBinaryLabelmapRepresentation().
Thank you @Sunderlandkyl.
It seems that SegmentMorphology module does the same as Margin effect and Logical operators effect. Maybe we could just remove it, to reduce SlicerRT maintenance burden. @cpinter what do you think?
Yes this is actually true. Thanks @Sunderlandkyl for fixing this!
I have thought about this as well, but didn’t have time to check if some workflow or other extension relies on this etc. But in theory I agree, it is basically a duplication of features.
SegmentMorphology module was developed when Segment Editor did not have these features, so it made sense then, but not necessary now. We have the option of A. fix it now and commit to its maintenance, 2. remove it now and fix&maintain if it turns out that somebody needs it. I would vote for B.
Absolutely, I agree.
I just said I haven’t removed the Segment Morphology module because for that I wanted to check if another extension used that particular module. You have a build machine so doing that check should be easy. If nobody else uses the module, then it can be removed.
SegmentMorphology module is not used in any other extensions. It is not used either in SlicerRT workflow tests. So, removing it should not disrupt anything.
@Sunderlandkyl, since you already have a SlicerRT build configured, would you mind submitting a pull request that removes SegmentMorphology module? Thank you!
OK, PR made here: https://github.com/SlicerRt/SlicerRT/pull/156.