Duplicate Input DICOM Spatial Coordinates

[bluna301]

Will flesh out comment more tomorrow, just wanted to get some preliminary notes down prior to tomorrow's meeting.

Solution stores each SOP instance in a new dictionary (not ideal) and checks if the combination of StudyInstanceUID, SeriesInstanceUID, and ImagePositionPatient has been seen before; if so, it removes the duplicate, with preference for the higher AcquisitionNumber. In cases where the ImagePositionPatient tag is not present (X-Ray images, some non-image DICOM files like SR, KO, PR, etc. modalities), no duplication check takes place. This approach is effective for handling the case discussed:

[2025-04-15 23:07:39,429] [INFO] (dicom_data_loader_operator.DICOMDataLoaderOperator) - No or invalid input path from the optional input port: None
[2025-04-15 23:07:39,816] [INFO] (dicom_data_loader_operator.DICOMDataLoaderOperator) - DICOM Images to Load: 312
[2025-04-15 23:07:39,838] [INFO] (dicom_data_loader_operator.DICOMDataLoaderOperator) - Duplicate spatial coordinates detected; removing duplicate SOP at IPP (-250.0, -250.0, -746.25) in Series 1.2.840.113619.2.405.3.185216268.497.1730719949.233; kept SOP instance with higher AcquisitionNumber (3 > 2)
[2025-04-15 23:07:39,845] [INFO] (dicom_data_loader_operator.DICOMDataLoaderOperator) - DICOM Images Loaded: 311

I tested on ~20 clinical studies each for CT, CR, and MR modalities:

• CT: removes duplicate when present (just on the 1 study); all other cases have no duplicates
• CR: no duplicates present (ImagePositionPatient is absent), therefore no changes from existing loading functionality
• MR: removes a significant number of duplicates per study (sometimes around ~50% of total study images); repeated ImagePositionPatient values seem to be quite common for T1 mDIXON, mDIXON-Quant, SE-EPI MRE series; will provide anonymized version to illustrate

---

I wonder if it is worth having an input parameter to the operator to control whether or not duplicates are checked for. For example, if a user is targeting MR mDIXON series for inference (not sure how common this is), the duplicate check should probably be turned off to prevent a large number of SOP instances from not being loaded.

Finally, I am wondering how arbitrary referencing the higher AcquisitionNumber value is; besides the single test case, do we have any additional justification for using this approach?

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[MMelQin]

Look good to me. Thanks a lot.

[bluna301]

Thanks Ming. Future work may need to be done to make this functionality optional (say, for example, the desired series for inference is an mDIXON MR series that has duplicate ImagePositionPatient values). But I think this is good for now!