Dcm2bids adding additional information not requested in config file to anat name

,
1

I have two T1 files. The first is the original scan. The second is the normalized scanner output.

The json files from both of these scans are exactly the same. The only difference is the series name (which is variable by the participant)

When I run dcm2bids, it can’t differentiate these two scans and simply names them run01 and run02. Is there some way to better differentiate these scans based upon their order? Their series number isn’t always the same between participants but the original image is always before the normalized one.

Also, the BIDS naming convention is adding additional information that I am not asking to add to the name.

I want:
sub-a017_ses-01_run-01_T1w.nii.gz

I am getting…
sub-a017_ses-01_run-01_T1w_8mmIso_202205171211124.nii.gz

Why is this happening? How do I stop it from doing this?

Here is my config file. What am I missing here?

{
“descriptions”: [
{
“dataType”: “anat”,
“modalityLabel”: “T2w”,
“customLabels”:"",
“criteria”: {
“SeriesDescription”: “T2”
},
“sidecarChanges”: {
“ProtocolName”: “T2”
}
},
{
“dataType”: “anat”,
“modalityLabel”: “T1w”,
“customLabels”:"",
“criteria”: {
“SeriesDescription”: “T1”
},
“sidecarChanges”: {
“ProtocolName”: “T1”
}
},

Also, is there a way to force dcm2bids to include “run_01” in the naming convention when there is only run? Sometimes, I will have 1 and sometimes 2 depending on the participant, so adding it to customLabels is problematic.

2

HI @AustinBipolar,

For normalized T1w images with our scanner (Siemens Prisma), the ImageType field should contain something like “NORM” whereas the non-normalized T1w image doesn’t contain “NORM”. Assuming this is also the case with your JSON metadata, you could select the normalized image by doing:

 "criteria": {
            "SeriesDescription": "T1",
            "ImageType": ["ORIGINAL", "PRIMARY", "M", "ND", "NORM", "MOSAIC"]
            },

That’s a big tricky. Since the run entity label is optional, it would make sense that dcm2bids wouldn’t include it unless explicitly requested by the user (i.e. “customLabels”:"run-01",). Why is it that some participants will have 1 T1w image, while others have more? Using the acq entity label might be better for differentiating why there are 2 T1w images for some participants (e.g. acq-lowMotion and acq-highMotion).

3

Thanks for your help! We are running our scans on a siemen’s vida.
Normally I would have expected the scanner sequence to output an image type that is different than the original T1 image (for the normalized output) but it is exactly the same? This is super weird.

It sounds like the only solution is to manually rename the files? The only difference in the normalized and original T1 json files is the sequence number. We are running a large longitudinal trial and sometimes we need to re-run a scan due to an error or don’t run a session if we run out of time. This sometimes results in an unequal number of scan acquisitions (and mismatching scan acquistion numbers) between participants.

4

That is indeed weird. Another possible solution would be to use the SidecarFilename criteria, which I used to do in the past to select only the normalized T1w images, though this isn’t as robust as the ImageType option. For some quick background reference, our scanner outputs DICOMS in a scan folder labeled like this:

001_000001_000001.dcm
001_000001_000001.dcm
...
001_000002_000001.dcm
001_000002_000002.dcm
...
001_000003_000001.dcm
001_000003_000002.dcm
...

where the numbers separated by the underscores (e.g. _000001_) denote the series number essentially. In my study protocols, the non-norm T1w series number was 2, and the normalized was 3. So I used to do the following to select only the normalized:

"criteria": {
            "SidecarFilename": "003*"
         }

where the SidecarFilename is essentially the substring for the specific DICOMS you want. This would be difficult in situations where the series ordering/numbering isn’t the same, and would require either manual intervention or wrapping it in some code. This is the main limitation of BIDS converters that requires heuristic/configuration files.

5

I think the lesson here is to use Heuristics from now on :frowning: Thanks for your help!

6

Hi @AustinBipolar,

Which version of dcm2bids are you using? This issue should have been fixed in the most recent release, if not I can fix it quickly.

Arnaud

7

I am using the most recent version available for docker.

https://hub.docker.com/r/unfmontreal/dcm2bids/tags

Thanks for gettting back.

Jen

8

Hi @AustinBipolar,

I updated the docker version of dcm2bids. Give it a try with 2.1.9 and tell me if you still have this issue.

Best,
Arnaud

9

Thank you so much! Will update and try again.

10

Just wanted to thank you for applying this fix. It seems to have fixed this problem for me. Much appreciated!

Jen