questions > fail to obtain slice timing information with data from a GE scanner
Showing 1-7 of 7 posts
Jul 17, 2019 08:07 PM | Yaqiong Xiao
fail to obtain slice timing information with data from a GE scanner
Hi,
I am trying to convert DICOM data from a GE scanner but failed to get slicing timing information. The command I am using is as follows:
dcm2niix -b y -o $outdir/func/ -f sub-${subj}_task-rest_bold -z y $rest. The version of dcm2niix is v1.0.20190410. Here is one of the json files from my data. It seems all the details are extracted from the data but slice timing information. Could you please given me some hints? Thank you very much.
{
"Modality": "MR",
"MagneticFieldStrength": 1.5,
"ImagingFrequency": 63.8552,
"Manufacturer": "GE",
"ManufacturersModelName": "SIGNA_HDx",
"InstitutionName": "UCSD_Dunhill",
"DeviceSerialNumber": "0000000858822MR3",
"StationName": "GEHCOC1",
"PatientPosition": "HFS",
"SoftwareVersions": "14_LX_MR_Software_release:14.0_M5_0737.f",
"MRAcquisitionType": "2D",
"SeriesDescription": "BIRN_ACE_LIZ_LANGUAGE",
"ProtocolName": "BIRN_ACE_LIZ_LANGUAGE",
"ScanningSequence": "EP_RM",
"SequenceVariant": "NONE",
"ScanOptions": "EPI_GEMS",
"ImageType": ["ORIGINAL", "PRIMARY", "EPI", "NONE"],
"SeriesNumber": 4,
"AcquisitionTime": "23:25:59.000000",
"AcquisitionNumber": 1,
"SliceThickness": 4,
"SpacingBetweenSlices": 4,
"SAR": 0.00734041,
"EchoTime": 0.03,
"RepetitionTime": 2.5,
"FlipAngle": 77,
"PhaseEncodingPolarityGE": "Flipped",
"CoilString": "8HRBRAIN",
"PercentPhaseFOV": 100,
"AcquisitionMatrixPE": 64,
"ReconMatrixPE": 64,
"EffectiveEchoSpacing": 0.000492,
"TotalReadoutTime": 0.030996,
"PixelBandwidth": 7812.5,
"PhaseEncodingDirection": "j",
"ImageOrientationPatientDICOM": [
1,
-0,
0,
-0,
1,
0 ],
"InPlanePhaseEncodingDirectionDICOM": "COL",
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20190410 GCC4.4.7"
}
I am trying to convert DICOM data from a GE scanner but failed to get slicing timing information. The command I am using is as follows:
dcm2niix -b y -o $outdir/func/ -f sub-${subj}_task-rest_bold -z y $rest. The version of dcm2niix is v1.0.20190410. Here is one of the json files from my data. It seems all the details are extracted from the data but slice timing information. Could you please given me some hints? Thank you very much.
{
"Modality": "MR",
"MagneticFieldStrength": 1.5,
"ImagingFrequency": 63.8552,
"Manufacturer": "GE",
"ManufacturersModelName": "SIGNA_HDx",
"InstitutionName": "UCSD_Dunhill",
"DeviceSerialNumber": "0000000858822MR3",
"StationName": "GEHCOC1",
"PatientPosition": "HFS",
"SoftwareVersions": "14_LX_MR_Software_release:14.0_M5_0737.f",
"MRAcquisitionType": "2D",
"SeriesDescription": "BIRN_ACE_LIZ_LANGUAGE",
"ProtocolName": "BIRN_ACE_LIZ_LANGUAGE",
"ScanningSequence": "EP_RM",
"SequenceVariant": "NONE",
"ScanOptions": "EPI_GEMS",
"ImageType": ["ORIGINAL", "PRIMARY", "EPI", "NONE"],
"SeriesNumber": 4,
"AcquisitionTime": "23:25:59.000000",
"AcquisitionNumber": 1,
"SliceThickness": 4,
"SpacingBetweenSlices": 4,
"SAR": 0.00734041,
"EchoTime": 0.03,
"RepetitionTime": 2.5,
"FlipAngle": 77,
"PhaseEncodingPolarityGE": "Flipped",
"CoilString": "8HRBRAIN",
"PercentPhaseFOV": 100,
"AcquisitionMatrixPE": 64,
"ReconMatrixPE": 64,
"EffectiveEchoSpacing": 0.000492,
"TotalReadoutTime": 0.030996,
"PixelBandwidth": 7812.5,
"PhaseEncodingDirection": "j",
"ImageOrientationPatientDICOM": [
1,
-0,
0,
-0,
1,
0 ],
"InPlanePhaseEncodingDirectionDICOM": "COL",
"ConversionSoftware": "dcm2niix",
"ConversionSoftwareVersion": "v1.0.20190410 GCC4.4.7"
}
Jul 18, 2019 10:07 AM | Chris Rorden
RE: fail to obtain slice timing information with data from a GE scanner
I believe this reflects a limitation of your DICOM images, and not
a problem with dcm2niix. For GE equipment, we rely on the
tags RTIA Timer (0021,105E) or Trigger Time (DICOM
0018,1060). Be aware that not all GE sequences populate these tags.
Therefore, I believe that your raw data does not encode slice
timing. You can verify this by examining the DICOM header. I would
recommend dcmdump or gdcmdump to look at your header. However, you
can also have dcm2niix report the DICOM header by including the
logorrheic verbosity "-v 2". Since this mode generates so much
output, you may want to isolate a single image from the series for
this command. I suspect if you do this, you will find that your
files do not contain either of these two timing tags. Your GE
research collaboration manager can help you select EPI sequences
that generate these tags.
Jul 18, 2019 06:07 PM | Yaqiong Xiao
RE: fail to obtain slice timing information with data from a GE scanner
Thanks so much for your response.
I checked the dicom file using dcmdump, and found the tag information you mention, i.e., (0021,105e) DS [0.000000] # 8, 1 Unknown Tag & Data, but not Trigger Time (DICOM 0018,1060).
I have another question about dcm2niix. As I understand, if the slices originally are not in spatial sequential order, dcm2niix reorders the slices based on spatial position automatically, right?
Thank you.
I checked the dicom file using dcmdump, and found the tag information you mention, i.e., (0021,105e) DS [0.000000] # 8, 1 Unknown Tag & Data, but not Trigger Time (DICOM 0018,1060).
I have another question about dcm2niix. As I understand, if the slices originally are not in spatial sequential order, dcm2niix reorders the slices based on spatial position automatically, right?
Thank you.
Jul 18, 2019 06:07 PM | Chris Rorden
RE: fail to obtain slice timing information with data from a GE scanner
The NIfTI format requires that all 2D slices in a 3D volume be
saved in spatially sequential order. If your data was acquired in
ascending or descending order than the raw data was spatially
sequential, while if you acquired in interleaved order all the odd
slices are acquired prior to all the even slices (as you are using
a GE system).
Jul 18, 2019 09:07 PM | Yaqiong Xiao
RE: fail to obtain slice timing information with data from a GE scanner
Thanks for your reply. In my case, the images were acquired in
interleaved order. Does it mean I should reorder the slices before
converting to NIfTI format using dcm2niix? Here is an answer from
you to a similar question (see below), which seems to suggest
dcm2niix orders the slices based on spatial position. Is it
correct?
In general, dcm2niix converts images based on the order or their instance number, and the vendor-specific DICOM tag reveals the acquisition time for that slice. Unfortunately, the DICOM standard does not require that instance number refers to acquisition order (or is even unique). Therefore, if instance number does not correspond with spatial position, dcm2niix orders the slices based on spatial position and again uses the corresponding time tag to infer the slice time of that slice. In brief, NIfTI requires slices are saved in spatially sequential order, so dcm2niix ensures this.
Thanks.
In general, dcm2niix converts images based on the order or their instance number, and the vendor-specific DICOM tag reveals the acquisition time for that slice. Unfortunately, the DICOM standard does not require that instance number refers to acquisition order (or is even unique). Therefore, if instance number does not correspond with spatial position, dcm2niix orders the slices based on spatial position and again uses the corresponding time tag to infer the slice time of that slice. In brief, NIfTI requires slices are saved in spatially sequential order, so dcm2niix ensures this.
Thanks.
Jul 18, 2019 10:07 PM | Chris Rorden
RE: fail to obtain slice timing information with data from a GE scanner
With your data sorted by instance numbers the first slice of each
volume is near the top of the head, with subsequent slices moving
toward the feet. The Protocol Data block suggests that this is an
interleaved acquisition. According to Xiangrui Li's excellent
dicm2nii this suggests the slices near the feet were acquired later in
time, and it suggests the slice timing below.
This sounds plausible. However, neither Xiangrui or I have access to GE hardware. Further, there are certainly instances where the GE Protocol Block is known to be erroneous. Further, since GE does not report temporal gaps between fMRI volumes, we are not certain of the TA. Xiangrui assumes the acqusition is continuous (e.g. TA = TR * (nSlices-1)/nSlices). This guess will be wrong for sparse acquisitions.
I am simply the wrong person to ask. I would suggest you have three possible options:
1. Contact your GE Research Collaboration Manager.
2. Chat with the MRI physicist at your center
3. Spend a couple minutes in your scanner conducting a simple experiment to objectively detect slice order by starting the series with the participants head aligned to the scanner and then moving your head quickly during one volume.
If you find out anything, please let me know!
"SliceTiming": [
1.2096774,
2.4193548,
1.1290323,
2.3387097,
1.0483871,
2.2580645,
0.96774194,
2.1774194,
0.88709677,
2.0967742,
0.80645161,
2.016129,
0.72580645,
1.9354839,
0.64516129,
1.8548387,
0.56451613,
1.7741935,
0.48387097,
1.6935484,
0.40322581,
1.6129032,
0.32258065,
1.5322581,
0.24193548,
1.4516129,
0.16129032,
1.3709677,
0.080645161,
1.2903226,
0 ],
This sounds plausible. However, neither Xiangrui or I have access to GE hardware. Further, there are certainly instances where the GE Protocol Block is known to be erroneous. Further, since GE does not report temporal gaps between fMRI volumes, we are not certain of the TA. Xiangrui assumes the acqusition is continuous (e.g. TA = TR * (nSlices-1)/nSlices). This guess will be wrong for sparse acquisitions.
I am simply the wrong person to ask. I would suggest you have three possible options:
1. Contact your GE Research Collaboration Manager.
2. Chat with the MRI physicist at your center
3. Spend a couple minutes in your scanner conducting a simple experiment to objectively detect slice order by starting the series with the participants head aligned to the scanner and then moving your head quickly during one volume.
If you find out anything, please let me know!
"SliceTiming": [
1.2096774,
2.4193548,
1.1290323,
2.3387097,
1.0483871,
2.2580645,
0.96774194,
2.1774194,
0.88709677,
2.0967742,
0.80645161,
2.016129,
0.72580645,
1.9354839,
0.64516129,
1.8548387,
0.56451613,
1.7741935,
0.48387097,
1.6935484,
0.40322581,
1.6129032,
0.32258065,
1.5322581,
0.24193548,
1.4516129,
0.16129032,
1.3709677,
0.080645161,
1.2903226,
0 ],
Jul 19, 2019 04:07 PM | Chris Rorden
RE: fail to obtain slice timing information with data from a GE scanner
These slice times should be accurately reported with the latest
developmental version of dcm2niix (v1.0.20190719). This is
described in issue 310. The example datasets provided by the NIH validate the solutions, providing examples of both sequential and
interleave acquisition each acquired as inferior to superior and
superior to inferior slices.