Remaining problems with JSON sidecars

[mguaypaq]

These are some remaining issues after merging https://data.neuro.polymtl.ca/datasets/lbp-lumbar-usf-2025/pulls/1.

From this comment:

Git-annex is fine, but It looks like there are still some problems with the filenames:

• The chunk entity doesn't match between image files and json files: the image files have things like chunk-L1toL4Frfse with text (which is not allowed), and the corresponding json files have chunk-1, chunk-2, chunk-3 (which is ok, but it's not clear which json goes with which image file). The chunks should be numbered. If you want to keep an extra description of the FOV, you could add a custom key inside the corresponding json sidecars.
• Some files use the desc entity, but this is only allowed for derivatives. Probably this should be combined with the acq entity instead.

Bids-validator also raises some errors:

• 259 json sidecars raise this error:

  The fields 'RepetitionTime' and 'AcquisitionDuration' for this file are mutually exclusive.
  To specify acquisition duration, use 'SliceTiming' or 'DelayTime'

• 3 json sidecar files contain negative numbers where they shouldn't:

  Invalid JSON sidecar file. The sidecar is not formatted according the schema.
  SliceTiming
  /sub-nMRI033/ses-Post/anat/sub-nMRI033_ses-Post_acq-sag_T2w.json - must be >= 0
  /sub-nMRI033/ses-Post/anat/sub-nMRI033_ses-Post_acq-sag_T1w.json - must be >= 0
  /sub-nMRI018/ses-Post/anat/sub-nMRI018_ses-Post_acq-sagittal_T2w.json - must be >= 0

• There is a mismatch between some 'SliceTiming' arrays and image dimensions:

  SLICETIMING_ELEMENTS The number of elements in the 'SliceTiming' array should match the 'k'
  dimension of the corresponding NIfTI volume.

  /sub-nMRI052/ses-Post/anat/sub-nMRI052_ses-Post_acq-sag_T1w.nii.gz
  /sub-nMRI052/ses-Post/anat/sub-nMRI052_ses-Post_acq-sag_T2w.nii.gz

  128 more files with the same issue

  Looking at the first file, I see that 'SliceTiming' is an array with 17 values, and the image data array actually has shape (17, 320, 320). As explained here in the BIDS specification and here, by default bids-validator expects the third dimension (k, from [i, j, k]) to be 17, but you could specify i or i- in 'SliceEncodingDirection' to tell bids-validator to look in the first dimension instead. The choice of i or i- will depend on whether the slices were acquired in increasing or decreasing order.

  This is probably because you reoriented the images to RPI, without fixing some corresponding fields in the json sidecars. For example, the listed values for 'PhaseEncodingDirection' are maybe not accurate anymore. This may be annoying to fix.