Add configuration to allow using itk or pydicom_seg for DICOM SEG

[joselfrias]

Motivation and Context

When working with DICOM images and running inferences to generate DICOM Segs, the ITK tool (itkimage2segimage) can sometimes fail: even if MONAILabel successfully produces a segmentation, converting it to a DICOM Seg may abort if a required tag is missing, as shown next, which aborts all the process and in the end no segmentation is returned.

E: CodingSchemeDesignator (0008,0102) absent in CodeSequenceMacro (type 1) E: Could not write item #0 in ProcedureCodeSequence: Invalid Value FATAL ERROR: Writing of the SEG dataset failed! Error: Invalid Value. Please report the problem to the developers, ideally accompanied by a de-identified dataset allowing to reproduce the problem! ERROR: Conversion failed.

To solve this error, a fix is presented here (https://qiicr.gitbook.io/dcmqi-guide/faq#conversion-fails-with-the-missing-attribute-s-error-what-should-i-do), but this is not optimal when dealing with real DICOM data, where files are constantly incoming to the PACS, since it requires to modify the attribute in all dicom files.

Since MONAILabel already supports pydicom_seg for DICOM SEG generation, this PR introduces a way to switch between the itkimage2segimage tool and pydicom_seg, which was previously hardcoded and could not be changed unless we changed the code.

Summary

• Add MONAI_LABEL_USE_ITK_FOR_DICOM_SEG in monailabel/config.py, overridable via environment variable. Default is True to preserve existing behavior.
• Update nifti_to_dicom_seg in monailabel/datastore/utils/convert.py to respect this setting. The function can still override the config if needed; the setting only applies when use_itk is None.

Test Plan

• Verify that infer requests and save label endpoints work correctly across different datastores.

[fedorov]

@joselfrias the underlying issue for that runtime error is that DCMTK (by default) version used in dcmqi refuses to inherit the problem from the reference image and write an invalid DICOM SEG. From your explanation, I conclude that pydicom_seg is less stringent and does not complain about DICOM errors in the output?

I completely agree with you that patching the reference image is often not practical. Because of this a feature was suggested for DCMTK to allow user to not abort when resulting SEG has DICOM non-compliance issues. It took a while (from 2017 to 2024) to actually implement that feature, but it was finally added here DCMTK/dcmtk@bf2c668 by @michaelonken. That feature is included in the latest stable DCMTK release 3.6.9, but unfortunately not in DCMTK release 3.6.8, which is the one currently used in the latest dcmqi release 1.4.0.

Also, while preparing this response, I discovered that the new DCMTK API is not currently used in dcmqi, so we will need to address that as part of resolving QIICR/dcmqi#232.

The good news is that we do currently have resources to maintain dcmqi, and we should be able to complete these updates by the end of the month. @michaelonken is also working on adding support of DICOM SEG/LABELMAP and further improvements of performance, which we hope to release in the next few months.

In summary, on the dcmqi side, to address the issue we will:

• upgrade to DCMTK 3.6.9 or newer
• implement the use of the new DCMTK API added in DCMTK/dcmtk@bf2c668
• we will also need to upgrade DCMTK to 3.6.9 or newer in 3D Slicer

You guys decide if you want to proceed with this PR, I just wanted to give the background on dcmqi for the context.

[bastiao]

@joselfrias the underlying issue for that runtime error is that DCMTK (by default) version used in dcmqi refuses to inherit the problem from the reference image and write an invalid DICOM SEG. From your explanation, I conclude that pydicom_seg is less stringent and does not complain about DICOM errors in the output?

True.

I completely agree with you that patching the reference image is often not practical. Because of this a feature was suggested for DCMTK to allow user to not abort when resulting SEG has DICOM non-compliance issues. It took a while (from 2017 to 2024) to actually implement that feature, but it was finally added here DCMTK/dcmtk@bf2c668 by @michaelonken. That feature is included in the latest stable DCMTK release 3.6.9, but unfortunately not in DCMTK release 3.6.8, which is the one currently used in the latest dcmqi release 1.4.0.

Also, while preparing this response, I discovered that the new DCMTK API is not currently used in dcmqi, so we will need to address that as part of resolving QIICR/dcmqi#232.

The good news is that we do currently have resources to maintain dcmqi, and we should be able to complete these updates by the end of the month. @michaelonken is also working on adding support of DICOM SEG/LABELMAP and further improvements of performance, which we hope to release in the next few months.

In summary, on the dcmqi side, to address the issue we will:

• upgrade to DCMTK 3.6.9 or newer
• implement the use of the new DCMTK API added in DCMTK/dcmtk@bf2c668
• we will also need to upgrade DCMTK to 3.6.9 or newer in 3D Slicer

You guys decide if you want to proceed with this PR, I just wanted to give the background on dcmqi for the context.

Thanks for explanation. This make a lot of sense. I subscribed the issue on dcmqi, but assuming that you fix it, then a release of dcmqi needs to come out, and then, update version (https://github.com/Project-MONAI/MONAILabel/blob/main/monailabel/interfaces/app.py#L556). Do you think there will be breaking changes?

Anyway, this patches does not change default behavior, only make possible to use a available library that was not possible to use due to the hard coded behavior. So both options can live together.

[SachidanandAlle]

Looks good to me