Possible New Slicer Extension - DICOMToNRRDBatchProcessing

Development
1

Hi,

I’m looking to contribute a new slicer extension that takes a DICOM directory of patients and outputs NRRD files for each patient’s series into a DICOM conforming folder hierarchy Patient/Study/Series. So, there’d be a single NRRD file in each generated series directories.

I explored saving a NRRD file from the GUI, but I can’t select multiple patients for saving a NRRD file.

Before I put the time in for making this extension, is there anything I may have overlooked where this functionality already exists and this extension is unnecessary?

Thank you,
Alex

2

It would be useful to have a standard module for this. I do this kind of operation fairly often and I find that usually I need to write a customize script for each set of DICOM data due to some weird quirk of the data or something unique about the acquisitions, but probably there are standard use cases that could be handled by a custom extension.

Here’s a skeleton sample:
https://slicer.readthedocs.io/en/latest/developer_guide/script_repository.html#batch-processing

Here’s an example from a customized use case where some required data came from external files.

3

From pull request: ENH: DICOM To NRRD Module Implementation by alex-myers · Pull Request #7502 · Slicer/Slicer · GitHub @lassoan suggested I add this as a SandBox extension; however, I was originally thinking adding this as a Slicer extension.
@pieper suggested a standard module so I went down that path. If there is a similar custom extension base class similar to ScriptedLoadedModule where it’s not too much work, I’m fine with that.
So should this be a Slicer extension, a PerkLab SandBox slicer extension, or a Slicer module? I’ll be using this in tangent with a production DICOM viewer BTW.

4

It can become a Slicer core module, but I think it is too early. It will take some time for the module to become more generally usable and work well for a wide range of data. If it is in Slicer Stable Release then you can update it just once in every few months. If it is in an extension then you can update it every day.

Sandbox is a general-purpose collection of maturing Slicer modules, so I think it is a good place for this module. Adding a new extension and maintaining it has some overhead, so it would make sense if we have at least 1-2 more modules for DICOM batch processing - or if the module becomes very robust and capable, so we don’t want to keep it in “sandbox” anymore but we don’t want to move it to Slicer core (e.g., to keep it easier to make changes).

I would suggest to submit to the Sandbox now and decide on its final place later.

5

Ok. For the time being, I’ll be putting this task off for 3-6 months then I’ll re-assign it, or complete it. Right now, I have a solution for my current project, and I just have higher priorities at the moment.

Nonetheless, the bulk of the logic is already taken into account, and simply adding a checkbox for scalar volumes only should suffice in the sandbox.

Thank you for your feedback for potential invalid characters, that alone was worth the code review.