Incorrect sidecar filenames in func

1

Hello all,
I am trying to make a pipeline that ultimately converts all of our data into a BIDS-compatible format. When the sidecars get created for func, it seems that the resulting filename is some conglomeration of the intended filename and the protocol name key from the header. I am not sure what is causing this, but instead of getting files that look like sub-001_task-MID_run-01_bold.json (or .nii.gz), I instead get filenames approximately like sub-001_task-MID_run-01_bold.5_60sl_4_times_20210421094004.json. The extraneous data seems to be coming from a few keys in the headers, but I’m not sure how to tell dcm2bids to ignore that stuff.

My config file is set up as such:

{
  "descriptions": [
    {
      "dataType": "func",
      "modalityLabel": "bold",
      "customLabels": "task-MID",
      "criteria": {
        "SidecarFilename": "*8_*_EPI_2.5_60sl_4_times*"
      }
    },
    {
      "dataType": "func",
      "modalityLabel": "bold",
      "customLabels": "task-MID",
      "criteria": {
        "SidecarFilename": "*7_*_EPI_2.5_60sl_4_times*"
      }
    },
    {
      "dataType": "func",
      "modalityLabel": "bold",
      "customLabels": "task-SST",
      "criteria": {
        "SidecarFilename": "*10_*_EPI_2.5_60sl_4_times*"
      }
    },
    {
      "dataType": "func",
      "modalityLabel": "bold",
      "customLabels": "task-SST",
      "criteria": {
        "SidecarFilename": "*9_*_EPI_2.5_60sl_4_times*"
      }
    },
    {
      "dataType": "fmap",
      "modalityLabel": "magnitude1",
      "criteria": {
        "SidecarFilename": "*_gre_field_mapping_230FOV_*_e1.json"
      },
      "intendedFor": [
        0,
        1,
        2,
        3
      ]
    },
    {
      "dataType": "fmap",
      "modalityLabel": "magnitude2",
      "criteria": {
        "SidecarFilename": "*_gre_field_mapping_230FOV_*_e2.json"
      },
      "intendedFor": [
        0,
        1,
        2,
        3
      ]
    },
    {
      "dataType": "fmap",
      "modalityLabel": "phasediff",
      "criteria": {
        "SidecarFilename": "*_gre_field_mapping_230FOV_*_e2_ph.json"
      },
      "intendedFor": [
        0,
        1,
        2,
        3
      ]
    },
    {
      "dataType": "fmap",
      "modalityLabel": "epi",
      "customLabels": "dir-j",
      "criteria": {
        "SidecarFilename": "*_EPI_2_5_60sl_PA_*"
      },
      "intendedFor": [
        0,
        1,
        2,
        3
      ]
    },
    {
      "dataType": "anat",
      "modalityLabel": "T1w",
      "criteria": {
        "SeriesDescription": "t1_mprage_sag_p2"
      }
    }
  ]
}

Any help with this issue would be greatly appreciated. Of course, I can supply more information about my environment as needed.

2

Hi and welcome to neurostars!

This might be because you are specifying the sidecar filename as a criterion. Instead, you should try to use something like the SeriesDescription or some other field within the json as criteria.

Best,
Steven

3

I’m not sure I’m understanding. I changed “SidecarFilename” to “SeriesDescription”, and nothing has changed. Is that what you meant with your suggestion?

4

You need the series description criteria to match the series description field in the JSON files. Did you run a dcm2bids_helper on a subject to see the JSON outputs for a single subject?

5

I have figured out the issue. Our SeriesDescription/ProtocolName uses a period in the name, so when dcm2bids says ext = Path(srcFile).suffixes in line 141 of dcm2bids.py, the filename is being parsed at the period in the SeriesDescription, with everything to the right of the period being treated as a file extension which is later added back to the filename. Adding a check to dcm2bids.py that makes sure the extensions are either .nii, .gz, or .json fixes my issue and results in a bids-validated dataset. Is this something worth making a pull request about? Or should people just not use periods in their SeriesDescription/ProtocolName lmao

6

Good catch! I would open an issue / PR about this.

7

Wow, it seems there was a fix introduced to dcm2bids for this exact behavior on June 1st (see here). I must not be using the most up to date dcm2bids, though I could have sworn I updated to 2.1.9 not two months ago.