Series Description and Protocol Name in the .json file

[andersonwinkler]

Hi Chris,

Thanks for the hard work on this incredibly helpful tool. We have many files collected from GE scanners that have these fields:

0008:103E 	Series Description 	EPI task AP3- 2 runs - 183 reps
0018:1030 	Protocol Name 	MAP_AP3 (Rear projector) 

In the BIDS/JSON file, however, we get:

"SeriesDescription": "EPI_task_AP3-_2_runs_-_183_reps",
"ProtocolName": "EPI_task_AP3-_2_runs_-_183_reps",

We'd like to have the ability to sort by protocol, but they end up populated with a repetition from the series description. Is there a way to change this behaviour?

Many thanks!

All the best,

Anderson

[neurolabusc]

What version of dcm2niix are you using? This sounds like issue 425, so I would have thought it is resolved in the current stable release. If that fails, check the behavior of the current commit to the development branch.

As noted in the release notes the latest stable release also dramatically improved the detection of GE meta information, so I would certainly recommend users with GE data consider upgrading.

[andersonwinkler]

Thanks! The issue is really that the ProtocolName in the JSON is inheriting the Series Description from the DICOM file, as opposed to the actual Protocol Name. The spaces/underscores/etc are ok.

The version used is 20200331 and we can certainly update if the most recent has this changed. Thanks!

Anderson

[neurolabusc]

Anderson,

Please see the filenaming notes. Unlike other vendors (and GE CT), the GE MRI product sequences use a generic name for 0018,1030, so we use 0018,0024 instead. Since 0018,0024 can be modified by the user on the console, it is equivalent to 0018,1030 on other systems. I think a lot of DICOM to BIDS heuristics would not have anything unique to tag on to if we used 0018,1030.

[neurolabusc]

Anderson,

Can you try out the latest development branch commit. The old behavior was to copy text from Series Description (0018,0024) to ProtocolName (0018,1030) for GE MRI. The new behavior is to swap these two strings. These removes the redundancy in the JSON and retains the value originally stored in 0018,1030. Be aware that 0018,1030 is generic for all sequences on GE MRI, but this does allow you to access this information. This modification will cause the dcm2niix automatic validation tests to fail as changes in behavior are detected. If we are happy with this new behavior, we can change the reference data for the validation scripts.

To try the latest version on a Unix computer:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make
./dcm2niix

Old behavior JSON:

	"SeriesDescription": "Ax DWI TENSOR R2",
	"ProtocolName": "Ax DWI TENSOR R2",

New behavior JSON:

	"SeriesDescription": "Brain Advanced Sequences",
	"ProtocolName": "Ax DWI TENSOR R2",

[andersonwinkler]

Thanks Chris! It almost perfect: the Protocol Name and Series Description are however swapped in the JSON:

  "SeriesDescription": "MAP_AP3 (Rear projector)",
  "ProtocolName": "EPI task AP3- 2 runs - 183 reps",

PS: the underscores have become spaces again (like in the DICOM), which is fine for us (either way is ok).

[neurolabusc]

This is intentional, it is a feature not a defect. Failing to do this would have catastrophic consequences for BIDS conversion tools. The GE MRI SeriesDescription (0008,103E) is equivalent to the ProtocolName (0018,1030) for Siemens, Philips, UIH and GE CT. Many tools rely on the Protocol Name to identify datasets, however 0018,1030 is inflexible in GE Product sequences. Moving forward, you can follow this simple heuristic: dcm2niix will always swap ProtocolName and SeriesDescription when the Modality is MR and the Manufacturer is GE.

This ensures that the ProtocolName has the same console-editable property across all vendors and modalities. Having console-editable values allows users to provide meaningful names and automate naming schemes.

[andersonwinkler]

Got it, thanks!

I think we'll live with it then, or swap in the JSON files we use in projects so that it remains compatible with what the users see when they browse the imaging database.

Thanks!

[neurolabusc]

For future reference, issue 476 describes how default behavior has changed.