Conversion of GE and Philips dual-TR B1+ maps

[cmadjar]

Describe the bug

It seems that dcm2niix is not capable of extracting the TR values from dual-TR B1+ maps on Philips and GE causing issues in the conversion of those maps.

A colleague looked briefly through the dcm2niix code and noticed that the (2005,1030) DICOM header tag does not appear to be read, which is where Philips is storing the two TR values. He has confirmed in the Philips DICOM datadef document that he has that this is the private tag used for TR.

To reproduce

The command used run was dcm2niix -ba n -z y -o <dir> <dicom_dir>. I don't know yet if I can share sample data with you.

Expected behavior

There should be two NIfTI files produces with different TRs but instead,

• for GE, we get two NIfTI files with two different EchoNumber but same TR.
• for Philips, we get one NIfTI file with two volumes within it

Version

Chris Rorden's dcm2niiX version v1.0.20220720 Clang12.0.5 ARM (64-bit MacOS)
v1.0.20220720

and

Chris Rorden's dcm2niiX version v1.0.20220720 (JP2:OpenJPEG) (JP-LS:CharLS) GCC9.4.0 x86-64 (64-bit Linux)
v1.0.20220720

[neurolabusc]

My center only has Siemens equipment. I require examples from users to support other manufacturers, and in particular sequences where the interpretation depends on private tags like 2005,1030). You can see my validation datasets for GE field maps here, courtesy of @mr-jaemin.

In general, I would expect most gradient echo field maps to have two echoes and a single TR. Therefore, your observed behavior for GE sounds appropriate to me. If your sequence really does use two TRs and dcm2niix reports the same TR for both volumes it sounds like the source DICOM is buggy.

I have little experience with Philips data. If you want to see support improved, can you share a sample dataset with my institutional email along with sequence details. I note that dicm2nii describes 2005,1030 as 'MRSeriesRepetitionTime' % duplicate. Again, I would expect a gradient echo field map to have two echo times but a shared repetition time, so one expected the volumes to be discriminated by the public tag echo time(0018,0081) which dcm2niix should recognize.

If you are acquiring a series with two TRs and the public tag repetition time(0018,0080) does not vary, this suggests the limitation is with your DICOMs and not with dcm2niix. dcm2niix makes the assumption that the DICOM images are truthful, and if this is not the case I would not consider these datasets of archival quality.

[mr-jaemin]

Please let me know if there is anything I can help you with (GE dataset).
(I am not familiar with dual-TR B1+ maps but will look into if sample GE DICOM can be shared)

[cornercase]

@neurolabusc We can provide a sample of the dual-TR B1 maps from Philips. These do in fact use a single TE and two TRs. The system appears to generate two series, one containing the raw images at the two TR values and then a generated series with the B1 map. The generated series has tag (0018,0080) set equal to 0 for the generated series, but stores both of the TRs in (2005,1030). I don't yet know if this is due to it being a generated series or because we are exporting classic DICOMs. I'll work on getting a set of images uploaded as an example.

[neurolabusc]

@cornercase feel free to share the Philips database with my institutional email. Again, since the public tag 0018,0080 is incorrect I do not think these are archival quality. We can add a kludge to dcm2niix, but this will confound tools that strictly follow the DICOM standard. I would encourage you to work with your Philips Clinical Scientist to address this issue at the root.

[neurolabusc]

@cornercase I have added a kludge to the development branch that will split a series into separate volumes based on TR. The DICOM standard allows an image to report a echo number (0018,0086), but does not provide the equivalent for TR number. Hence, it is not possible to detect that a slice comes from a multi-TR series. Therefore, the naming of the files is ambiguous. Hopefully, your scripts can deal with these. Given the DICOM standard, a better approach might be for the manufacturer to save each TR as a unique series.

[cmadjar]

Hi @neurolabusc,

Thank you for the quick fix!

I am wondering since I noticed that for the GE data, the EchoNumber is different for the two volumes produced by dcm2niix for AFI modalities why this is not the case for the Philips data. Instead, I can see that the image type is different between the two volumes (which was not the case for the GE of same modality). I am a bit confused by the outputs and am not sure how to properly label the Philips scans in BIDS since shorter TR should be labeled acq-tr1 and longer TR acq-tr2.

With the resulting files, I am not sure how to determine which file has the shorter TR and which one has the longest. For the GE data, I used the EchoNumber, assuming that EchoNumber 1 was for the shorter TR and EchoNumber 2 for the longer TR.

Thoughts?

Thank you for being so responsive BTW. Very appreciated :-)

[neurolabusc]

@cmadjar I have not seen the GE data, so I can not comment. In general, the echo number (0018,0086) is Type 3 (optional: may or may not be included). Regardless, for the Philips data they provided, they images use the same echo time (14ms) but vary the repetition time (30ms, 150ms). It does also look like the console generated a derived difference image but failed to save it as a separate series number or flag it as derived (which does violate the DICOM standard). You may want to work with the Philips Clinical Scientist associated with this instrument to generate valid DICOMs. At the moment, I think you will have to develop a script to parse the JSON files created by dcm2niix to disambiguate the images created by this unusual sequence.

[dcdeaniii]

@mr-jaemin I could share some example data from GE. How can I share it with you?

[mr-jaemin]

@mr-jaemin I could share some example data from GE. How can I share it with you?

Thanks Doug! Could you please upload your data using this link? https://ge.ent.box.com/f/3e5433ace5184a82850c6d00f8ca0d14

[dcdeaniii]

Thanks! Just uploaded some data to the link.

[mr-jaemin]

Thanks! Just uploaded some data to the link.

Thanks, Doug! I am not familiar with dual-TR B1+ map PSD. Could you please advise me how dual TR values were prescribed in PSD (e.g screenshots of Details/Advanced tab)?

[cmadjar]

@dcdeaniii when you have a chance, could you reply to @mr-jaemin please? Unless this was done outside of the GitHub issue. Thanks!

[neurolabusc]

I am closing this issue for now. I think that dcm2niix does everything it can with the known information and exemplars. This seems to be an extreme edge case where the DICOM does not accurately describe the sequence. If we get more insight into how @mr-jaemin can replicate this issue and reliably detect these sequences, we could consider a kludge.

[cmadjar]

Thank you @neurolabusc! One last question for you. Do you have an approximate idea of when the bug fix you implemented on the development branch would be released? Does not have to be precise. Just to get an idea. In the meantime, we will use the dcm2niix built from the development branch.

Thank you again for your help with this!! Very appreciated :-)

[neurolabusc]

Stable releases of dcm2niix are traditionally released twice per year (spring and autumn). Unfortunately, I was severely injured in hit and run while riding my bicycle earlier this year, so the spring release did not emerge until the end of July. This late release did incorporate a lot of changes from the community. I have now returned to a full load of teaching, service and research, but have a backlog of deferred work. My sense is that the next stable release will be Spring 2023, and at that stage we will return to the twice per year cadence.

[cmadjar]

So sorry to hear about your injury. Must have been terrible. I hope you feel better.

Thanks for giving the release estimate. Makes total sense. Best wishes,

[dcdeaniii]

I did pass along some information to @mr-jaemin about this outside of the GitHub issue. But if this was not received, just let me know.

[mr-jaemin]

I did pass along some information to @mr-jaemin about this outside of the GitHub issue. But if this was not received, just let me know.

Sorry, would you (@dcdeaniii) mind to re-send your note? (Just emailed your as well)