Philips fieldmap: phase and magnitude are stacked together

[parekhpravesh]

Hello,

I am using dcm2niix v1.0.20200331 (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 (64-bit Linux) with Philips DICOM data that has functional scans as well as fieldmap files (two echoes, phase and magnitude images). Using this release of dcm2niix, I noticed that the trigger time was being added to filenames (most likely related to #395). Therefore, I tried using "-m y" option and the functional files turn out to be a single 4D NIfTI (as expected). However, for fieldmap data, the phase and magnitude images are now part of the same NIfTI (snapshot below). Additionally, the resulting NIfTI fieldmap image is a 4D file, not split into phase and magnitude. This issue does not happen with enhanced DICOM (with or without using "-m y" option).

How do you suggest dealing with this? Perhaps the development patch fixes this already? Thank you

A Google Drive link to example DICOM data that has resting state and fieldmap data (both classic and enhanced) is here.

[neurolabusc]

As you correctly note, this is a duplicate of issue 395 and a consequence of issue 384. However, I sugest a novel solution.

dcm2niix is segmenting the 4D fMRI series as separate 3D files, because the onset time of each fMRI volume is reported with a unique trigger time (0018,1060). To override this behavior, you forced merging (-m y) which has undesirable consequences for your phase map series. From my perspective, this usage of 0018,1060 is a clear violation of the DICOM standard: this time stamp has nothing to do with the cardiac R-wave. If dcm2niix ignored 0018,1060 for Philips images, it would not correctly convert legitimate cardiac-gated data (see here for an example). In brief, this is a limitation of your images, not my software.

My latest commit introduces a desperate kludge for this situation. Specifically, it will ignore the trigger delay time (0018,1060) unless the Philips private tag 2001,1010 reports TRIGGERED. Legitimate Philips cardiac-gated data report:

(2001,1010) CS [TRIGGERED]

while your scan reports:

(2001,1010) CS [NO]

I hate using private tags to over ride the behavior of public tags. I only use this if 0008,0070 reports the vendor is PHILIPS. This may introduce unintended consequences. I would be interested if Philips experts (@drmclem, @baxpr) have any counter-examples or better strategies for dealing with these images.

[drmclem]

Hi

Just a bit puzzled by your comment about (0018,1060) having nothing to do with R-wave - the link in your previous post explicitly mentions the delay between R-wave - "Time interval measured in msec from the start of the R-wave to the beginning of data taking" - from our (Philips) perspective "triggering" only occurs during cardiac or respiratory triggering and hence leads to the variable TR delay between volumes. Triggering, I beleive in this context is when the scanner is triggered from an external source - which is in line with the 4 definitions on dicom lookup.

The issue in 395 only occured because a specific user had reused the cardiac triggering functionality to perform variable inversion. I would be interested to know if the appearance of the trigger values in this case is similar - i.e. pulse programming shortcut or is genuinely cardiac/respiratory triggered

Matthew

[neurolabusc]

@drmclem the examples provided here by @parekhpravesh and by @yarikoptic with issue 395 appear to be generic fMRI sequences without any cardiac gating. Yet they still increment the Trigged Time (0018,1060) for each volume. I would expect 0018,1060 to reflect cardiac gating. The example provided by @baxpr in issue 395 was a heavily modified sequence that used this tag in a non-traditional way. I think my latest patch does what we want: it segments data into separate files if the trigger times are different and report having a cardiac trigger, but it keeps them together if they report varying trigger delays even though no cardiac syncing is reported.

[drmclem]

Hi - so I had a look at the fmri data set in the Multi-echo Philips 3T Achieva dStream 5.3.0.3 images from Baxter Rogers.

For this data - the fMRI is normal and does not have any occurances of 0018,1060 that I can see.
The datasets in the T1_1echo_2phase scans reuse the cardiac inversion recovery functionality with a simulated cardiac trigger to generate the two inversion times on one scan. These have fully valid cardiac tags.
eg
(0018,9037) CS [PROSPECTIVE] # 12, 1 CardiacSynchronizationTechnique
(0018,9070) FD 1000 # 8, 1 CardiacRRIntervalSpecifie1060
(0018,1060) DS [178] # 4, 1 TriggerTime

Looking at the data from yarikioptic - (example-dicom-functional) - as always its a bit hard to be definitive as this data is not as it comes from the scanner and has been through GDCM (you will also see that it has the fictitious values for the b vectors components and other diffusion tags even though this is not a diffusion scan.
(0018,9602) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueXX
(0018,9603) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueXY
(0018,9604) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueXZ
(0018,9605) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueYY
(0018,9606) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueYZ
(0018,9607) FD 7.229999999999997e+75 # 8, 1 DiffusionBValueZZ
)

For the data as it comes off the scaner - (Enhanced DICOM 5.6 I checked .. ) we use Temporal position index as the dimension
(0020,9128) UL 5 # 4, 1 TemporalPositionIndex
and
(2005,10a0) holds the dynamic time (secs)

So I there are two mixed up problems here - scans with valid cardiac modules where the functionality has been "appropriated" (Philips functionality) and scans without valid cardiac modules where erroneous tags have been added - Not Philips - I suspect by GDCM and similar to the issue on the b-matrix modules.

Matthew

[neurolabusc]

@drmclem thanks for your investigation. Regardless of the origin for these tags, I hope my current patch resolves different usage of these tags. I will close this issue, and flag this change in the notes for the next stable release. At some stage, users with large Philips datasets (e.g. @baxpr, @captainnova) can make sure there are no unintended consequences of my patch.

[drmclem]

Hi
No problem. I would see @baxpr data as valid but the other as unintended corruption - I would suggest @yarikoptic and others (perhaps @dagra) should look at why the workflow (GDCM presumably) is corrupting the Philips data and adding uncessary tags.

[drmclem]

As you correctly note, this is a duplicate of issue 395 and a consequence of issue 384. However, I sugest a novel solution.

dcm2niix is segmenting the 4D fMRI series as separate 3D files, because the onset time of each fMRI volume is reported with a unique trigger time (0018,1060). To override this behavior, you forced merging (-m y) which has undesirable consequences for your phase map series. From my perspective, this usage of 0018,1060 is a clear violation of the DICOM standard: this time stamp has nothing to do with the cardiac R-wave. If dcm2niix ignored 0018,1060 for Philips images, it would not correctly convert legitimate cardiac-gated data (see here for an example). In brief, this is a limitation of your images, not my software.

My latest commit introduces a desperate kludge for this situation. Specifically, it will ignore the trigger delay time (0018,1060) unless the Philips private tag 2001,1010 reports TRIGGERED. Legitimate Philips cardiac-gated data report:

(2001,1010) CS [TRIGGERED]

while your scan reports:

(2001,1010) CS [NO]

I hate using private tags to over ride the behavior of public tags. I only use this if 0008,0070 reports the vendor is PHILIPS. This may introduce unintended consequences. I would be interested if Philips experts (@drmclem, @baxpr) have any counter-examples or better strategies for dealing with these images.

Sorry - catching up - is vendor the best place to categorise these issues - I feel that this is not Philips problem but a consequence of the intermediate - would the implementation not be a better place

0002,0013) SH [GDCM 2.8.3] # 10, 1 ImplementationVersionName
(0002,0016) AE [gdcmanon] # 8, 1 SourceApplicationEntityTitle

which would also still help identify vendor specific issues as our dicom from the system is
(0002,0013) SH [Philips MR 56.1] # 16, 1 ImplementationVersionName

This would also avoid adversely impacting functionally correct Philips data.

Matthew

[neurolabusc]

Without knowing the full provenance it is hard to know the origin for these tags. I have only seen these for Philips, but it is possible some tool inserted them. Further, dcm may not be to blame, it might have been used subsequently to anonymize the data. Perhaps @yarikoptic can look at the sample he provided and see what tool inserted triggerTime. Regardless, I think the latest patch provides a comprehensive solution. I apologize if I have incorrectly identified Philips as the origin for this confusion. Philips should be lauded for their DICOMs. It is only the edge cases that cause issues, and often these images have been handled by many tools. Since we do not have GE or Philips at my center, I am at the mercy of others to get validation images. It is under stable that these users need to anonymize shared datasets, but this does make it hard to known the origin of issues.

[baxpr]

@drmclem @neurolabusc I finally have something to contribute here (now that everything has moved on, hah) We just acquired an fMRI scan on Philips that has a range of values in the (0018,1060) TriggerTime field that map onto the volume acquisition start times. These are classic DICOMs that were sent from the Philips scanner to our research PACS, with minimal amount of mangling, then downloaded from the PACS directly. To me this suggests the scanner did insert these TriggerTime values.

As regards dcm2niix, v1.0.20200331 converts these just fine to a 4D nifti with the expected value of volume acq time in pixdim[4], so long as I use the -m y option.

[neurolabusc]

@baxpr can you try this dataset out with the latest development build of dcm2niix (v1.0.20200707). This should convert your series to a 4D dataset with pixdim[4] reporting the TR and not incurring the unintended consequences of -m y that elicited this thread. I believe the latest development build will auto-detect that if can ignore the trigger time from these images, while correctly using trigger time for other data you have acquired. If this is not the case, I suggest you re-open this issue and send me a sample of the new dataset.

[baxpr]

@neurolabusc confirmed. The version mentioned above (commit 8326f94 v1.0.20200707) works as you describe, producing the 4D nifti without any extra flags. Thanks!

[drmclem]

Hi @baxpr - I find this finding in #408 (comment) very odd and would like to get to the bottom of it - would you be willing to share your examcard with me (I assume this is unpatched software) and which software release you are running ?

[baxpr]

@drmclem Scanner is Ingenia Elition X, software version is 5.6.1\5.6.1.0.

Almost certainly we were running a patch. We routinely use a patch with a couple of local modifications. I don't suppose there's a private DICOM field that stores something about patch status that I could check?

As you know, we did repurpose the trigger time field for inversion time with an MP2RAGE sequence. I don't think we did anything similar for this fMRI, but if I'm wrong maybe that is what's happening.

I'm working on that exam card for you.

[drmclem]

Hi all,

So - testing this on the current 5.6.1 release has thrown up some details. Ignoring for the moment non-standard software (the MP2Rage patch). Normal behaviour appears to be

1. If the scan is not cardiac triggered

• Tag (0018,0022) is present in CLASSIC export but with an unrelated value
• Tag (0018,0022) is absent in ENHANCED export
• The public tag 0018,9037 - Cardiac Synchronisation technique - is NONE
• Private tag (2001,1010) is No and present in both

2. If the scan is cardiac triggered

• Tag (0018,0022) is present in both CLASSIC and ENHANCED
• The public tag 0018,9037 - Cardiac Synchronisation technique - is PROSPECTIVE as set in the protocol
• Private tag (2001,1010) is Triggered

Note that 0018,9037 and 2001,1010 may have other entries depending on the protocol.

I have been unable to reproduce @parekhpravesh and by @yarikoptic with issue 395 where the Trigger time contains the dynamic time which is normally either inferred from the temporal position indictator (Enhanced) (0020,9128), or (0018,9074) DT [20200811092305.14] # 18, 1 FrameAcquisitionDateTime or the (both) private tag (2005,10a0)

This investigation has thrown up a possible bug wrt trigger time and the use of MultiBand but that is under investigation, however I would still advise caution of making decisions on trigger time for non cardiac triggered scans. @baxpr - could you look at one of your MP2RAGE sequences and see if the 0018,9037 - Cardiac Synchronisation technique disambiguates your scans from true cardiac triggered scans ?

M

[neurolabusc]

@drmclem thanks for the thorough investigation. Just to confirm, the current development release of dcm2niix (v1.0.20200808) should correctly ignore trigger time for your classic images that are not cardiac triggered, correct? Its great to understand this, so we can accurately detect when trigger time is relevant.

[baxpr]

@drmclem thanks for digging! In one of our MP2RAGE Enhanced DICOMs I see:

(0018,0022) ScanOptions                        OTHER
(0018,1060) TriggerTime                        1010, 3310, 5610
(0018,9037) CardiacSynchronizationTechnique    PROSPECTIVE
(0020,9153) CardiacTriggerDelayTime            1010, 3310, 5610
(2001,2010) Private_2001_2010                  Couldn't find this one

So I think the answer is no, (0018,9037) does not differentiate this from an actual cardiac triggered scan.

[drmclem]

What about (0018,9085) CS [VCG] # 4, 1 CardiacSignalSource Are you using physiological simulation or the clinical science key for “internal” trigger source Matthew From: Baxter P. Rogers <[email protected]> Sent: Wednesday, August 12, 2020 3:17 PM To: rordenlab/dcm2niix <[email protected]> Cc: Clemence, Matthew <[email protected]>; Mention <[email protected]> Subject: Re: [rordenlab/dcm2niix] Philips fieldmap: phase and magnitude are stacked together (#408) @drmclem<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.jparrowsec.cn%2Fdrmclem&data=02%7C01%7C%7Cd0feac1360f649fd6c7d08d83eca5883%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637328386071026823&sdata=FTq1JjRH12NKm9vInFi%2FTajyBnhYc5N1pY34bqJ95HM%3D&reserved=0> thanks for digging! In one of our MP2RAGE Enhanced DICOMs I see: (0018,0022) ScanOptions OTHER (0018,1060) TriggerTime 1010, 3310, 5610 (0018,9037) CardiacSynchronizationTechnique PROSPECTIVE (0020,9153) CardiacTriggerDelayTime 1010, 3310, 5610 (2001,2010) Private_2001_2010 Couldn't find this one So I think the answer is no, (0018,9037) does not differentiate this from an actual cardiac triggered scan. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.jparrowsec.cn%2Frordenlab%2Fdcm2niix%2Fissues%2F408%23issuecomment-672898357&data=02%7C01%7C%7Cd0feac1360f649fd6c7d08d83eca5883%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637328386071026823&sdata=Txdma7i1zOjD2HishReX6VaU2z%2F%2FoRqw5a4Qqsz7klw%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.jparrowsec.cn%2Fnotifications%2Funsubscribe-auth%2FAIRGAT6O3SG52O62QOTCYZDSAKP43ANCNFSM4OZP6XFQ&data=02%7C01%7C%7Cd0feac1360f649fd6c7d08d83eca5883%7C1a407a2d76754d178692b3ac285306e4%7C0%7C0%7C637328386071036817&sdata=n3lnjqM0vE6iWe2UdYWi6DQFQcbhSB%2Bi%2FhQR9fx2JC4%3D&reserved=0>.

…

________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

[baxpr]

(0018,9085)  CardiacSignalSource     VCG

[neurolabusc]

As a note for @drmclem's comment from Aug 12, 2020, Philips ASL scans

  (0018,9037) CS [NONE]   #   4, 1 CardiacSynchronizationTechnique
  (2001,1010) CS [TRIGGERED]  #  10, 1 Unknown Tag & Data

so 2001,1010 is not sufficient to determine if a scan is not sufficient to determine if a Philips scan is using Cardiac Sync.