Incorrect SeriesInstanceUID at least in Siemens-MAGNETOM Vida

[dagra]

In the latest release and in the latest developmental branch the SeriesInstanceUID is incorrect in the json file (running with -ba n), and more specifically replaced by the (0008,0031) SeriesTime, if the manufacturer and model is Siemens - MAGNETOM Vida. I checked with some other models from Siemens (e.g. Skyra, Avanto) and from Philips, GE and they seem ok, but my available list is limited, so I'm not sure that the problem doesn't exist in other models too.

I sent you a sample dataset in the email.

EDIT:
P.S.: The problem is evident also if the filename is defined as -f %j.

[neurolabusc]

The issue you are observing is a kludge to handle issue 394. dcm2niix clearly warns you about the issue:

Warning: Siemens XA exported as classic not enhanced DICOM (issue 236)

This is not a limitation of my software, but rather reflects the DICOMs created by an XA11 system when it is coerced to generate classic rather than enhanced DICOMs. Please heed the warning from Siemens we highly recommend that the Enhanced DICOM format be used. This is because this format retains far more information in the header. You should go back to the console and export the data as enhanced format to retain meta data, your sample dataset is not of archival quality. While dcm2niix includes kludges to deal with some aspects of these datasets, this will have unintended consequences and other tools are unlikely to handle these images at all.

For further discussion, see issue 236.

[dagra]

Ok, so the main issue of these datasets is that they are exported in the classic and not in the enhanced format. Unfortunately, I don't have immediate control of the export settings, but I will notify accordingly.

Regarding the kludge to handle issue 394, as far as I can tell the main purpose was to merge DICOM files with varying SeriesInstanceUIDs by using the SeriesTime and consequently even in datasets where there is only one SeriesInstanceUID, the replacement still occurs. I'd expect that in the case that all DICOM files have the same SeriesInstanceUID and SeriesTime, the resulted SeriesInstanceUID would be the SeriesInstanceUID, but I understand that this would require another kludge which would complicate things further. Perhaps a warning of this replacement would be useful.

In any case, thank you very much for all your effort and immediate response.

[neurolabusc]

To be clear, when a Siemens XA system is coerced to export classic data, it generates images that violate the DICOM standard. Specifically, the SeriesInstanceUID (0020,000E) is a Type 1 tag, and the variation created by Siemens contravenes this.

My software is designed to handle valid DICOM images - the format is complicated enough without having to deal with the limitless ways it can be corrupted. Making kludges to dcm2niix to handle such corrupted data runs the risk of unintended consequences.

While kludges in my software attempt to bind these images together, the DICOM images will cause mayhem with tools that implement the DICOM standard correctly. Beyond these errors, the classic data omits a lot of the meta data that is required for subsequent analyses, so the JSON files created by dcm2niix are impoverished. I have lobbied Siemens to remove this export option, as it has demonstrably led to data loss. I have also suggested that Siemens Application Specialists explicitly warn users of the consequence of this option when they train users with this equipment. To their credit, Siemens has attempted to address many of these shortcoming with future software updates. However, it seems that the education of users is lagging.

[dimrozakis]

Hi @neurolabusc

Specifically, the SeriesInstanceUID (0020,000E) is a Type 1 tag, and the variation created by Siemens contravenes this.

While this might be true for the datasets mentioned in #236 & #394,
it doesn't seem to be the case for the dataset @dagra is talking about.
All the DICOM files of that dataset contain a SeriesInstanceUID with the same valid value
(according to @dagra),
which is correct since they're all part of the same series.

Does it make sense to you that running dcm2niix on a set of files with a
proper SeriesInstanceUID results in a nii file with a wrong filename (-f %j)
and a bids file with a wrong SeriesInstanceUID?
It seems to me that in the best effort attempt to handle DICOM files with messed up
SeriesInstanceUIDs, DICOM files with proper SeriesInstanceUIDs end up having their
SeriesInstanceUID messed up as collateral damage.
Please keep in mind that the dataset we're talking about here doesn't seem to
benefit from the "kludge" (#394).

I suppose that the kludge could be a bit smarter and only replace
SeriesInstanceUID with SeriesTime if necessary (which would be the case if
files with different SeriesInstanceUIDs had to be merged, or files with the same
SeriesInstanceUID had to be separated to distinct series).

Alternatively, this behaviour (the "kludge") could perhaps be disabled by a CLI flag?

Would you be open in reconsidering any of the above options?

[neurolabusc]

The issue is that we are working with a very limited sample of datasets from these systems. I did supply Siemens with a laundry list of concerns regarding the XA data format before the hardware was deployed beyond their release customer. One of my suggestions was a way to track software patches the way we can for the V series, e.g.

"WipMemBlock": "5c24ac97-9ec0-458a-8b21-51a8260bf287||Sequence: ve11c/master r/ab69a6c; Apr 19 2017 10:08:21 by eja",
"SoftwareVersions": "syngo MR D13D",

While it is possible there are variations between software updates of different XA10 and XA11 systems, there is no obvious way to detect these variations. It is unclear whether a given system will generate different output for different sequences, though it is clear that console settings can dramatically change the output (e.g. if the user chooses to anonymize data from the console).

The Siemens engineers are very clear about this: the classic mode should be avoided. The engineers have also ensured that upcoming XA software releases contain more meta data in their enhanced mode.

dcm2niix is open source. You are free to fork the software and add the functionality you want. I begrudge the time I have lost to this crippled interpretation of the DICOM standard. Confident conversion of the data will require a large validation dataset to understand the variations in output from this system, and work with your Siemens Research Collaboration Manager to explore the corner cases for their proprietary export. Even with this effort, you are left with the fact that the classic data generated by this system simply omits many of the tags crucial for subsequent analysis. Once you are confident you have a robust solution, you can issue a pull request to share your work with the community.

[dimrozakis]

@neurolabusc

dcm2niix is open source. You are free to fork the software and add the functionality you want. I begrudge the time I have lost to this crippled interpretation of the DICOM standard.

Fair enough. Thanks for taking the time to respond and explain the issue, as well as for your overall stellar work on developing dcm2niix.