Getting missing GE information required by BIDS for common preprocessing

ge
dcm2niix
dicom
fmriprep
bids

#1

I would like to use BIDS format for common preprocessing (e.g. using fmriprep), however with data from a GE scanner (Signa HDxt), I could not get any of the following fields (among others) with dcm2niix (including latest version I compiled myself at the time of writing):

  • “BandwidthPerPixelPhaseEncode”
  • “EffectiveEchoSpacing”
  • “TotalReadoutTime”
  • “SliceTiming”
  • “PhaseEncodingDirection”

I could manually get EffectiveEchoSpacing by looking at DICOM field 0043 102c (cf GE doc) and SliceTiming by looking at DICOM field “Trigger Time”.

I could compute TotalReadoutTime with (<DICOM field “IMG Columns”> - 1) * (1 / EffectiveEchoSpacing).

However I could not find a way to get BandwidthPerPixelPhaseEncode (the DICOM field “ACQ Pixel Bandwidth” seems to be something different) and could only get part of the PhaseEncodingDirection: the direction but not the sign (direction was “j” as DICOM field “ACQ Phase Encoding Direction” was ROW).

Any help on getting from GE DICOM images all the parameters required for standard resting state and diffusion MRI preprocessing (especially slice time correction, fieldmap-based correction, and use of FSL eddy) would be great.


#2

dcm2niix is able to extract a lot of this information, but there are limits. GE is unfortunately known for not including some of the crucial pieces of information.

If you know of some fields that could be extracted automatically by dcm2niix (but currently are not - like SliceTiming) it would be worth opening an issue to let dcm2niix developers know.


#3

I suggest you try out the dcm2niix pre-release. This attempts to read the proprietary GE Protocol Data Block to work out phase encoding direction. The release notes provide a few caveats. I do not have GE hardware, so please test cautiously. Note that no one knows how to extract all the details you requested from GE DICOMs, however most of them only influence the calibrated values of TOPUP/Eddy and do not influence the actual images that are created for analyses. In practical terms, you do not need these values as long as your datasets have equal polarity in opposite directions.


#4

With regards to SliceTiming I have scanned agar phantom on GE MR750 (a.k.a. Discovery) running DV-24 using short fMRI sequence planned in 8 combinations:

| Code | SeqNum |    ORDER    | ACQUISITION | HEAD_TOP_SLICE | HEAD_BOTTOM_SLICE |
|------+--------+-------------+-------------+----------------+-------------------|
| s06  |      6 | Top-Down    | Sequential  |              1 |                44 |
| s07  |      7 | Bottom-Up   | Sequential  |              1 |                44 |
| s08  |      8 | Top-Down    | Sequential  |             44 |                 1 |
| s09  |      9 | Bottom-Up   | Sequential  |             44 |                 1 |
| s10  |     10 | Top-Down    | Interleaved |              1 |                44 |
| s11  |     11 | Bottom-Up   | Interleaved |              1 |                44 |
| s12  |     12 | Top-Down    | Interleaved |             44 |                 1 |
| s13  |     13 | Bottom-Up   | Interleaved |             44 |                 1 |

Unfotrunately TriggerTime was not saved with DICOMs but I have found FloatSlopRTIATimer (or RTIA_timer) to have something to do with SliceTiming.

I can share the DICOMS (224MB). (Or produce more if needed.) Detailed report can be found on https://github.com/nikadon/cc-dcm2bids-wrapper. At the bottom of the README file I have placed number of tables containing:

  • SeriesNumber,
  • ImagesInAcquisition,
  • InStackPositionNumber,
  • InstanceNumber,
  • SliceLocation,
  • TriggerTime,
  • FloatSlopRTIATimer

for each acquisition.

I am not sure about the reliability of the FloatSlopRTIATimer for SliceTiming estimation.(?)


Dcm2nii: Problem with slice-timing metadata extraction
#5

This sounds very useful (and might allow us to close dcm2niix issue 163). I would be grateful if you could share the DICOMs. Alternatively, if you work out a solution you can submit a pull request. Since I do not have GE hardware, in the future it might be nice to have a validation dataset that is a bit smaller than 224 mb, e.g. just a few volumes in each 4D series, just a few slices in each volume (~ 7 slices) and a coarse (64x64) matrix. A very compact dataset like that would be useful for creating a GE analogue to the Siemens dcm_qa dataset that we use for validation whenever a new patch is submitted to dcm2niix.


#6

I tested getting the slice timing based on the RTIA_timer (0021,105E) using the sample data from University of Iowa GE Discovery MR750w sample data.

Below are the first two volumes (37 slices each) for series four (ascending acquisition, TR=2). The times from the first volume have some clear errors (multiple slices reporting time = 0). However, the second volume looks plausible.

I would really prefer sample data from a human head rather than an abstract phantom - it would make determining the head-foot, anterior-posterior and (if a fiducial marker is used) left right clear. Also, a human could rotate their head once during acquisition, confirming the slice acquisition order.

001.dcm 0.0023
002.dcm 0.0563
003.dcm 0.1104
004.dcm 0
005.dcm 0.2185
006.dcm 0.2725
007.dcm 0.3266
008.dcm 0.3806
009.dcm 0.4347
010.dcm 0.4888
011.dcm 0
012.dcm 0.5969
013.dcm 0
014.dcm 0
015.dcm 0.759
016.dcm 0.8131
017.dcm 0.8671
018.dcm 0.9212
019.dcm 0.9753
020.dcm 1.0293
021.dcm 1.0834
022.dcm 1.1374
023.dcm 1.1915
024.dcm 1.2455
025.dcm 1.2996
026.dcm 1.3536
027.dcm 1.4077
028.dcm 1.4617
029.dcm 1.5158
030.dcm 1.5698
031.dcm 1.6239
032.dcm 1.6779
033.dcm 1.732
034.dcm 1.786
035.dcm 1.8401
036.dcm 1.8941
037.dcm 1.9482
038.dcm 2.0025
039.dcm 2.0565
040.dcm 2.1106
041.dcm 2.1646
042.dcm 2.2187
043.dcm 2.2727
044.dcm 2.3268
045.dcm 2.3808
046.dcm 2.4349
047.dcm 2.489
048.dcm 2.543
049.dcm 2.5971
050.dcm 2.6511
051.dcm 2.7052
052.dcm 2.7592
053.dcm 2.8133
054.dcm 2.8673
055.dcm 2.9214
056.dcm 2.9755
057.dcm 3.0295
058.dcm 3.0836
059.dcm 3.1376
060.dcm 3.1917
061.dcm 3.2457
062.dcm 3.2998
063.dcm 3.3538
064.dcm 3.4079
065.dcm 3.4619
066.dcm 3.516
067.dcm 3.57
068.dcm 3.6241
069.dcm 3.6781
070.dcm 3.7322
071.dcm 3.7862
072.dcm 3.8403
073.dcm 3.8943
074.dcm 3.9484


#7

@Chris_Rorden Thank you for the links to helpful materials :slightly_smiling_face:

I have acquired the data (14MB in total for) 8 basic variants of fMRI planning/acquisition. Six volumes per sequence, each with head movement around volume(s) 4, 5 and 6.

  • Reconstruction matrix was 64×64
  • Each volume had 44 slices.
  • SliceThickness = 3 mm,
  • SpacingBetweenSlices = 3.3.

Summary is available here. Raw DICOM data here.

| SeqNum | Order | Acquisition | Slice num at head top | Slice num at head bottom |
|--------+-------+-------------+-----------------------+--------------------------|
|      7 | TD    | Sequential  |                     1 |                       44 |
|      8 | BU    | Sequential  |                     1 |                       44 |
|      9 | TD    | Sequential  |                    44 |                        1 |
|     10 | BU    | Sequential  |                    44 |                        1 |
|     11 | TD    | Interleaved |                     1 |                       44 |
|     13 | BU    | Interleaved |                     1 |                       44 |
|     14 | TD    | Interleaved |                    44 |                        1 |
|     15 | BU    | Interleaved |                    44 |                        1 |

The last two columns describe the geometrical position of the cuboid during planning:

    ---------------------- 1                  ---------------------- 44
    ----------------------                    ----------------------
    ----------------------                    ----------------------
              .                                         .
              .                   OR                    .
              .                                         .
    ----------------------                    ----------------------
    ----------------------                    ----------------------
 44 ----------------------                  1 ----------------------

I hope that I did no miss anything during the acquisition.

If needed I can repeat the above mentioned procedure in the following days/weeks in order to:

  • be sure that nothing was mixed up…
  • provide smaller dataset (as suggested by @Chris_Rorden)

#8

This is really useful, and it shows my current solution PhaseEncodingGE actually detects the Order. Your new dataset seems sufficient to work out the slice timing, but means I am back to the drawing board for working out phase encoding (which is useful for tools like TOPUP). Would it be possible to acquire some sets where you manipulate the phase encoding direction (e.g. A->P, P->A, R->L, L->R)?


#9

With human subject or would phantom be enough for that?


#10

A phantom could work, but it would be important to have fiducials that indicate the L->R, A->P and S->P of an assumed human. We really want to make sure we have the phase encoding specified correctly.


#11

I have added dataset to the dicom-qa-examples. Right side positioned fiducial gave very weak signal in T2*, but it is visible.

I have also attached screen-shots of the user CV (pepolar) modification that (according to our local GE support folks) should do the trick of phase encoding polarity flip. Although I will try to consult GE as the NIFTI-converted images acquired with pepolar = 1 do not look too good :frowning:


#12

Thanks, I have updated a version of dcm2niix on Github for users to test. Would it be OK for me to include these images at the dcm2niix wiki. If so, how should I attribute this. I was thinking:

Images acquired on a GE 3T  DISCOVERY MR750 courtesy of the Uniwersytet M Kopernika
Form more details see https://github.com/nikadon/cc-dcm2bids-wrapper#overview

#13

Sure, it should be OK to include these images at the dcm2niix wiki. I am very glad I could be of any help.

If it is OK with you I would suggest the following for the attribution:

Images acquired on a GE 3T Discovery MR750 courtesy of the Interdisciplinary Center for Modern Technologies of the Nicolaus Copernicus University in Toruń. For more details see https://github.com/nikadon/cc-dcm2bids-wrapper#dicom-qa-examples

Also, the above link should now be stable as I have reorganised a bit the repository isolating examples in separate directory with separate description. (I have also updated links in this thread).


#14

Nikadon,
You have been very helpful in providing share-able GE data to validate slice timing and phase encoding polarity. Would you be interested in acquiring GE data with multi-shell DWI. Again, simpler is better - small number of gradient directions (12/20) with two non-zero b-values (e.g. 750, 1500).


#15

Sure, I am interested, I don’t have much experience with DWI data acquisition, therefore it can be a sort of learning opportunity for me. I can work on that around the end of this week.


#16

Got some DTI/DWI data:

  • 12 slices,
  • 16 directions,
  • b-val(s): 750, 1500.