Dcm2nii: Problem with slice-timing metadata extraction

1

Hello,

I have a question regarding metadata extraction from DICOM files into *.json file associated with 4-D *.nii functional data file. According to BIDS specification (http://bids.neuroimaging.io/bids_spec.pdf page 11) dcm2nii extract BIDS compatible metadata. However, after conversion I discovered that onset values in the slice timing field in json file are not in seconds:

"SliceTiming": [ 0.00019523, 9.524e-05, 0.00019047, 9.047e-05, 0.00018571, 8.571e-05, 0.00018095, 8.095e-05, 0.00017619, 7.619e-05, 0.00017143, 7.143e-05, 0.00016666, 6.666e-05, 0.0001619, 6.19e-05, 0.00015714, 5.714e-05, 0.00015238, 5.238e-05, 0.00014762, 4.762e-05, 0.00014286, 4.285e-05, 0.00013809, 3.809e-05, 0.00013333, 3.333e-05, 0.00012857, 2.857e-05, 0.00012381, 2.381e-05, 0.00011905, 1.904e-05, 0.00011428, 1.428e-05, 0.00010952, 9.52e-06, 0.00010476, 4.76e-06, 0.0001, 0 ],

Other fields have correct units (e.g. "RepetitionTime": 2,). I can manually correct those values to fit in range [0, 2], however I am not sure if dcm2nii works properly. Previously I was told that slice order for this dataset was set to [ 1 : 2 : 41, 2 : 2 : 42 ] (in MATLAB / Octave notation). Data were acquired in 3T GE scanner. Those onset values suggest reverse order of acquisition.

I also tried to use dcm2niix, but apparently it doesn’t include slice timing in json extracted metadata.

Did anyone encounter similar issue? Should I reformat those values using script or use different tool to extract valid metadata?

Thanks,
Kamil Bonna

2

This looks like a dcm2niix bug. Could you try again using the latest version (obtained from GitHub) and if that doesn’t help report the bug at https://github.com/rordenlab/dcm2niix/issues.

3

You mentioned that dcm2niix isn’t including slice timing information in the jsons, which is odd. Are your DICOMS sorted in any way prior to being converted? I think that I’ve noticed in the past that dcm2niix may struggle with getting the correct metadata if the DICOMs are not organized. In my case, the DICOMs are just dumped into meaningless folders, and sorting them by sequence name, and then converting improved things.

For sorting, I use https://github.com/pieper/dicomsort/blob/master/dicomsort.py like so:
/path/to/dicomsort/dicomsort.py ${where_my_unorganized_dicoms_are} ./sorted_dicoms/%SeriesDescription/%SOPInstanceUID.dcm -k

I then call call dcm2niix on each output folder. This also makes scripting nice and easy.

**Update 7/3 - I’ve been unable to reproduce the dcm2niix error I mentioned above - perhaps I made a mistake in my early neuroimaging days? In any case, I will leave this post here, as I think sorting the dicoms may still provide value to folks.

4

I used latest version of dcm2niix pulled from Github. Also, in order to test dcm2niix I used only one folder (n-back task for one subject) so sorting solution is not likely to work. If I understand correctly you advise to sort folders containing DICOMs and not DICOMs themselves?

dcm2niix json output from this conversion is:

{
“Modality”: “MR”,
“MagneticFieldStrength”: 3,
“Manufacturer”: “GE”,
“ManufacturersModelName”: “DISCOVERY_MR750”,
“InstitutionName”: “Uniwersytet_M_Kopernika”,
“DeviceSerialNumber”: “000000PL2853MR01”,
“StationName”: “28532853”,
“PatientPosition”: “HFS”,
“ProcedureStepDescription”: “GLOWA”,
“SoftwareVersions”: “24_LX_MR_Software_release:DV24.0_R02_1607.b”,
“MRAcquisitionType”: “2D”,
“SeriesDescription”: “n-back_3”,
“ProtocolName”: “n-back_3”,
“ScanningSequence”: “EP_GR”,
“SequenceVariant”: “SS”,
“ScanOptions”: “EPI_GEMS_ACC_GEMS”,
“ImageType”: [“ORIGINAL”, “PRIMARY”, “EPI”, “NONE”],
“SeriesNumber”: 4,
“AcquisitionTime”: “14:01:9.000000”,
“AcquisitionNumber”: 1,
“SliceThickness”: 3,
“SpacingBetweenSlices”: 3.5,
“SAR”: 0.465609,
“EchoTime”: 0.03,
“RepetitionTime”: 2,
“FlipAngle”: 90,
“PercentPhaseFOV”: 100,
“AcquisitionMatrixPE”: 64,
“ReconMatrixPE”: 64,
“EffectiveEchoSpacing”: 0.000468,
“TotalReadoutTime”: 0.029484,
“PixelBandwidth”: 7812.5,
“PhaseEncodingAxis”: “j”,
“ImageOrientationPatientDICOM”: [
0.999845,
-0.00785919,
-0.015746,
0.00736586,
0.999488,
-0.0311478 ],
“InPlanePhaseEncodingDirectionDICOM”: “COL”,
“ConversionSoftware”: “dcm2niix”,
“ConversionSoftwareVersion”: “v1.0.20180622 GCC7.2.0”
}

5

The core issue is that we do not know how to identify these properties for GE data. There are no defined standard DICOM tags to store this information. For Siemens data we can read the tag MosaicRefAcqTimes from the proprietary Siemens CSA header. Your bizarre values may reflect that dicm2nii attempted to read the proprietary GE protocol data block (0025,101B). However, this method proved unreliable.

We have recently made some progress reading the User Defined Data GE (0043,102A) tag. For example, if you build the latest dcm2niix commit with the custom MY_DEBUG_GE:

g++ -dead_strip -O3 -I. main_console.cpp nii_foreign.cpp nii_dicom.cpp jpg_0XC3.cpp ujpeg.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp -o dcm2niix -DmyDisableOpenJPEG -DMY_DEBUG_GE

You will find that the JSON file fills adds a new BIDS JSON “PhaseEncodingGE”: “TopDown” - which appears to reliably report the polarity of the phase encoding direction.

What we need is an algorithm to identify the slice timing information. The GE documentation for this block is available, but it is unclear which modules are provided with which versions of GE software. Both dicm2nii and dcm2niix come from centers with only Siemens equipment. A good place to start might be this recent GE dataset from the University of Iowa that systematically varies whether the EPI slices are acquired in sequential or interleaved order. We need to determine 3 properties:

  1. Were the slices acquired in interleaved or sequential order.
  2. Were the slices acquired in ascending (foot->head for axial slices) or descending (head->foot for axial) order.
  3. Was there a pause after the end of the final slice of one volume before the beginning of the first slice of the subsequent volume (e.g. as seen with sparse acquisition or Philips acquisition with prospective motion correction).

These tools are open source, so if you want to see this problem solved I encourage you to acquire validation datasets and submit a solution that can be shared with the community. Alternatively, you may want to see if your GE research collaboration manager can provide you with a reliable method to detect these properties.

6

Although not ideal, one approach for this issue is to check-up on the following DICOM fields:

  • (0020,1002) ImagesInAcquisition (number of all slices per each volume)
  • (0020,9057) InStackPositionNumber (number of particular slice in particular volume)
  • (0020,0013) InstanceNumber (number of particular slice in the whole acquisition)
  • (0020,1041) SliceLocation (self explanatory)

From the above - all the necessary information on the volume/slice acquisition regime can be deduced and verified…

A toy-example:

  • ImagesInAcquisition
    [ 44, 44, 44, ..., 44 ]
  • InStackPositionNumber
    [ 1, 2, ..., 44, 1, 2, ..., 44, ..., 44 ]
  • InstanceNumber
    [ 1, 2, 3, ..., 19800 ]
    (For a 15 mins scan with TR=2 and 44 slices/volume)
  • SliceLocation
    [ 52.3353, 49.1677, ... -83.8686, 52.3353, 49.1677, ... -83.8686, ..., -83.8686 ]
    (For a top-down and non-interleaved acquisition)

Based on the above the vector containing slice-timing can be prepared and populated in the data.

Obviously this approach is not straight-forward and it would be nicer to have it imported directly from DICOM files… :confused:

Another example attached below

dicom-slices
dicom-slices.png1130×1608 132 KB

7

cf. Getting missing GE information required by BIDS for common preprocessing

8

I have Philips data that dcm2niix Nov’18 version also isn’t extracting slice timing information from ? I can look at which dicom fields have to be there if someone points me to it.

9

As confirmed by drmclem from Philips, current Philips DICOM data does not store slice timing information or phase encoding polarity. This is not a limitation of dcm2niix, rather it is a limitation of the DICOM images created by the vendor. The dcm2niix Philips page describes how dcm2niix decodes Philips data. I suggest you lobby your Philips research collaboration manager to have these details included in the future.

1 Like
10

Thanks, Chris. The data I am working with are a few years old. Did at some point Philips DICOM files encode slice timing data ?

11

I do not have Philips hardware. I do not have a comprehensive set of data. I can not remember there ever being a way to extract slice timing, but I am not 100% confident in this.