Multiple cifti sidecars in fmriprep 20.2.3?

1

Hello - We have run fmriprep 20.2.3 using --output-spaces fsLR and --cifti-output.
I’ve noticed that there are two json sidecars associated with the ...space-fsLR_den-91k_bold.dtseries.nii image:

...space-fsLR_den-91k_bold.dtseries.json contains:

{
  "grayordinates": "91k",
  "space": "HCP grayordinates",
  "surface": "fsLR",
  "surface_density": "32k",
  "volume": "MNI152NLin6Asym"
}

...space-fsLR_den-91k_bold.json contains

{
  "RepetitionTime": 2,
  "TaskName": null
}

Why are there two different sidecars? Is it a bug or is this behavior intended? In version 20.2.0 there was only one sidecar (...space-fsLR_den-91k_bold.dtseries.json), without the info from ...space-fsLR_den-91k_bold.json.

Thank you!

2

...space-fsLR_den-91k_bold.json is the BIDS sidecar file containing metadata that’s required by the BIDS standard.

...space-fsLR_den-91k_bold.dtseries.json contains non-standard metadata that fMRIPrep added.

There is a discussion about this issue. The short story is that .dtseries.nii is the extension for a CIFTI-2 with dense time series, so the appropriate sidecar drops the .dtseries (.dtseries.json is not a meaningful extension). The problem is that we only allow “bug fixes” in minor series (20.2.x), so we had to decide what was the bug. The misplaced BIDS metadata is obviously a bug that had to be fixed, so that’s why it’s in bold.json. The custom metadata is more of a choice than a bug, so conservatively we left it where it was.

Potentially we could add a flag to move the custom metadata to bold.json, if that’s important to people.

3

Thanks for the answer.

The two files do not pose a problem for me at this point, I was more just curious. Without thinking too hard about it, it makes sense to me for the custom metadata to be included in bold.json. If it’s problematic to have the custom data at the same level as the BIDS required keys, you could add another key level, eg:

{
  "RepetitionTime": 2,
  "TaskName": null,
  "custom":   # or another, more creative key name 
    {
     "grayordinates": "91k",
     "space": "HCP grayordinates",
     "surface": "fsLR",
      "surface_density": "32k",
     "volume": "MNI152NLin6Asym"
    }
}
4

I don’t think it is problematic from a BIDS perspective (it is generally tolerant of unspecified metadata). It’s more a question of what changes are really bug-fixes, trying to ensure we don’t allow the impulse to “improve” things to change things on people who are depending on fMRIPrep to be consistent. So you should be able to update from 20.2.0 to 20.2.6, and the only changes should be corrections to things that were verifiably wrong. If you want to read more, here’s our bug-fix release document.

21.0.x has gotten rid of the .dtseries.json altogether.

1 Like