Missing TR and TE in dicominfo.tsv for Philips multiframe series

[catetrai]

Summary

TR and TE are incorrectly extracted as -1.0 in dicominfo.tsv.

We are using Philips multiframe DICOMs, which store the TR and TE tags in sub-elements for functional group sequences.

Example extraction using pydicom:

>>> ds = pydicom.dcmread('my-dicom-image')
>>> TR = ds.SharedFunctionalGroupsSequence[0].MRTimingAndRelatedParametersSequence[0].RepetitionTime
>>> TE = ds.PerFrameFunctionalGroupsSequence[0].get([0x2005, 0x140f])[0].EchoTime

See also how these are handled in the dicom2nifti tool.

Platform details:

Choose one:

• Local environment

• Container: nipy/heudiconv:v0.11.3

• Heudiconv version: 0.11.3

[akelkar26]

Hi,
I am also running into this issue. Do I need to extract the sub-elements with the above code for each scan and put it in the .tsv file?

[yarikoptic]

@catetrai thank you for all the details and sorry for taking so long with reply.
so we need to tune logic at https://github.com/nipy/heudiconv/blob/HEAD/heudiconv/dicoms.py#L45 to provide custom handling. @neurolabusc by any chance do you have such dicom samples in your test batteries already so we could reuse for testing here too?

if not -- @catetrai or @akelkar26 may be you could share some shareable (phantom)?

[akelkar26]

Thank you so much @yarikoptic and @neurolabusc for looking into this.
Please let me know if you need any dicom samples from my end. Also, please let me know the procedure to share them if that is the case.
Thank you again.

[yarikoptic]

do you have any shareable "ready"? any ways would work (share on google drive/dropbox, or just try to email an archive with them to me at debian AT oneukrainian.com) -- might expedite looking/fixing into this issue

[neurolabusc]

@yarikoptic for public enhanced DICOM Philips data visit here for sw 5.7.1 and here for sw 5.3.0.

[akelkar26]

Thank you so much for the public data. @yarikoptic unfortunately, I don't have the permissions from our collaborators to share the data I am using.
I would like to mention though, that I went ahead and created the heuristic file and ran heudiconv again to get the data in bids format. It worked well and the .json for each scan has the TR, TE values correctly populated.
So, this seems to be an issue with the .tsv file creation step.
Would it be safe to assume that the .json's in the bids data are correct and it would be okay to proceed to preprocessing?

Looking forward to hearing from you soon on the resolution for this issue.
Thank you

[yarikoptic]

what Times did you get in the sidecar .json files? For me on those provided by @neurolabusc after running heudiconv -f convertall -c dcm2niix --bids -o out-heudiconv -s unknown --files Philips on the ones for for sw 5.7.1

I get them all non-degenerate

❯ grep -e EchoTime -e RepetitionTime out-heudiconv/*json
out-heudiconv/run001.json:  "EchoTime": 0.003568,
out-heudiconv/run001.json:  "RepetitionTime": 0.256445,
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "EffectiveEchoTime": 3.568}
out-heudiconv/run001.json:              "RepetitionTime": 256.444793701171,
out-heudiconv/run002.json:  "EchoTime": 0.003568,
out-heudiconv/run002.json:  "RepetitionTime": 0.256445,
out-heudiconv/run002.json:      "EchoTime": 3.568,
out-heudiconv/run002.json:      "RepetitionTime": 256.444793701171,

and for the other ones I get it crashing on one leading to filing https://github.com/nipy/nibabel/issues/1211 on fMAP

and for the others it is also all nice and dandi

❯ grep -e EchoTime -e RepetitionTime out-heudiconv/*json
out-heudiconv/run0011.json:  "EchoTime": 0.004605,
out-heudiconv/run0011.json:  "RepetitionTime": 0.0080286,
out-heudiconv/run0012.json:  "EchoTime": 0.004605,
out-heudiconv/run0012.json:  "RepetitionTime": 0.0080286,
out-heudiconv/run0021.json:  "EchoTime": 0.008203,
out-heudiconv/run0021.json:  "RepetitionTime": 1.5,
out-heudiconv/run0022.json:  "EchoTime": 0.023165,
out-heudiconv/run0022.json:  "RepetitionTime": 1.5,

so I would still need some sample files which show this issue to resolve it adequately. Only you can assure that all data you expect is converted correctly and metadata corresponds to the values you know. bids-validator might help a little to catch some oddities automagically though .