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.
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.
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.
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:
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.(?)
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.
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.
@Chris_Rorden Thank you for the links to helpful materials
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.
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)?
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.
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
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
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).
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).
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.
