I am trying to export a Scalar Volume, which combines the original CT and the binary Label-Maps of the segmentation, as DICOM. Below is a coronal section of the volume and three labels, one of which is a cranioplasty implant. The purpose is to share the volume using a viewer like OHIF and get feedback through annotations.
OHIF can display DICOM segmentation object overlaid on the volume. To create a DICOM segmentation object, you can convert the labelmap to segmentation and follow these instructions. I’ve also created a detailed video tutorial that demonstrates a full segmentation object roundtrip between OHIF->Slicer->OHIF:
This is working so far. One thing I noticed is that I had to use the DICOM Patcher for some of the original datasets. Otherwise, sending to the KHEOPS server kept throwing Error 409
Following-up on this.
How to you export a modified base or reference volume?
I tend to clone and modify the cloned volume node to preserve the original. For instance, applying a filter and maybe even a transformation.
When I export to DICOM, the segmentation is the only node that actually gets exported.
If I use the scalar volume exporter, the process generates an additional study.
The behavior might have been different in earlier Slicer versions, but in the current version (recent Slicer Preview Releases) if you export an image by right-clicking on it in the Data module then:
if you leave StudyInstanceUID empty then it will be set based on where you have the image in the Subject Hierarchy tree (first tab in Data module)
if you set the StudyInstanceUID, FrameOfReferenceInstaceUID to match another study (and preferably copy all the other patient and study field values, too) and generate a new SeriesInstanceUID value then the image will appear under that other patient/study
If you use this via the GUI then the first option is definitely easier. If you process the images automatically then the second may be a bit simpler and more explicit. Although if you do batch processing then it may be simpler to use DICOM Patcher module, which does not disassemble the image and puts it back together, but just changes individual DICOM tags. You can even add custom rules by a couple of lines of Python script to address specific non-conformities that you encounter and not fixed by default.
Thank you, you are right, I could reproduce the behavior. It seems that you need to set the 3 IDs manually for now. You can get the ID values by right-clicking on the original series in the DICOM database and choose “View DICOM metadata” and then “Copy metadata”. I’ll see if we can automate this process to make it easier to export data to the same study as the original.
Then I started copying them manually into the GUI and realized that the SeriesInstanceUID needs to be different in order for this to work!
In other words, I think copying the volume node does preserve the SeriesInstanceUID instead of changing it. Is there a way to programmatically change this DICOM attribute?
I’ve made the DICOM export more convenient. In Slicer Preview Release that you download tomorrow or later images that show up under the same study in the subject hierarchy tree will be exported by default into the same study (the study instance UID is now populated automatically).
You can copy the frame of reference UID from the original image to the modified image if you want fused image display in external software.
A DICOM series is not allowed to be changed, ever, without generating new Series instance UID. If a file must be corrected then you send a “delete” request to the PACS (this hides the old instance); then push a new version of the image (that references the old hidden version). The same UID keeps referring to the same content.
Therefore, since the same series instance UID cannot be reused in another image, I would recommend to leave the series instance UID empty, which will generate a new UID automatically.