Func .json file

,
1

Hi,

I’m using a BIDs converted dataset for secondary data analysis, however, it is missing the func .json files. I am using this template to create my own:

{
“TaskName”: “N Back”,
“RepetitionTime”: 0.8,
“EchoTime”: 0.03,
“FlipAngle”: 78,
“SliceTiming”: [0.0, 0.2, 0.4, 0.6, 0.0, 0.2, 0.4, 0.6, 0.0, 0.2, 0.4, 0.6, 0.0, 0.2, 0.4, 0.6],
“MultibandAccelerationFactor”: 4,
“ParallelReductionFactorInPlane”: 2,
“PhaseEncodingDirection”: “j”,
“InstitutionName”: “Stanford University”,
“InstitutionAddress”: “450 Serra Mall, Stanford, CA 94305-2004, USA”,
“DeviceSerialNumber”: “11035”
}

How would I go about finding the information for the following fields: “MultibandAccelerationFactor”, “ParallelReductionFactorInPlane” and “PhaseEncodingDirection”?

I’ve used fslhd to get information from the header, however, I’m unsure how this information translates (if it even does) to these fields?

Here’s the output I’m working with:
filename sub-M2ID10040_ses-1_task-EmotionalReactivityAndRecovery_run-1_bold.nii.gz
size of header 348
data_type INT16
dim0 4
dim1 64
dim2 64
dim3 30
dim4 265
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 4
nbyper 2
bitpix 16
pixdim0 1.000000
pixdim1 3.750000
pixdim2 3.750000
pixdim3 5.000000
pixdim4 2.000000
pixdim5 0.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 0.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 3
slice_name alternating_increasing
slice_code 3
slice_start 0
slice_end 29
slice_duration 0.066667
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 0.000000 0.000000 5.000000 -70.739998
qto_xyz:2 -3.750000 0.000000 0.000000 118.125000
qto_xyz:3 0.000000 -3.750000 0.000000 127.495003
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Anterior-to-Posterior
qform_yorient Superior-to-Inferior
qform_zorient Left-to-Right
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -0.000000 -0.000000 5.000000 -70.739998
sto_xyz:2 -3.750000 -0.000000 -0.000000 118.125000
sto_xyz:3 0.000000 -3.750000 0.000000 127.495003
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Anterior-to-Posterior
sform_yorient Superior-to-Inferior
sform_zorient Left-to-Right
file_type NIFTI-1+
file_code 1
descrip
aux_file

Thanks in advance!
Phoenix

2

By design, the BIDS JSON file contains information that is not found in the NIfTI header. This removes redundancy and the need to resolve conflicts in between two sources of data.

  • The best way to resolve this is to convert your DICOM images using a modern tool like dcm2niix or dicm2nii. If this fails, you will want to look at the PDF file for your sequence, here is an example for SIemens.
  • The SliceTiming tag should have one entry for each slice in your 3D volume. If you trust that the NIfTI header specification of slice_name alternating_increasing is accurate, than this image does not have multi-band, which seems reasonable considering the number of slices, and TR (e.g. a modern multi-band sequence would acquire more, thinner slices in the same time). With these assumptions, you could set SliceTiming using this Matlab script
    slicetime(2.0, 30, true, false)
  • You may have to guess regarding ParallelReductionFactorInPlane. I am not sure many processing tools use this. These techniques (e.g. GRAPPA, SENSE) reduce spatial distortion and allow faster readout times, at the expense of SNR. Visual inspection for spatial distortions can help here. Given the short TR for the number of slices, I would not be surprised if this used a factor of x2.
  • Assuming these are axial slices that appear symmetrical when viewed, the PhaseEncodingDirection is likely j or j-. You can tell if the polarity is j or j- by visual inspection of the direction of spatial distortion. This only matters if you have a TOPUP compatible phase reversed spin echo sequence that you are also converting, which seems unlikely given the properties of this data set.
"MultibandAccelerationFactor": 1,
"SliceTiming": [
		0.000,
		1.000,
		0.067,
		1.067,
		0.133,
		1.133,
		0.200,
		1.200,
		0.267,
		1.267,
		0.333,
		1.333,
		0.400,
		1.400,
		0.467,
		1.467,
		0.533,
		1.533,
		0.600,
		1.600,
		0.667,
		1.667,
		0.733,
		1.733,
		0.800,
		1.800,
		0.867,
		1.867,
		0.933,
		1.933	],
3

Hi Chris,

Thanks for your response. Isn’t the yorient field used to determine the PhaseEncodingDirection (therefore, superior-to-inferior in this case)? and I believe they were sagittal slices.

Many thanks!
Phoenix

4

No, the yorient is a spatial mapping, not a temporal one.

The *form_*orient describes how to map the order of the columns, rows, and slices of data stored to disk to world space in millimeters. There are 48 combinations. The fact that your data is stored to disk as PIR provides no information regarding the temporal order the rows were acquired.