At our facility, most projects use sequences based on ABCD's protocol. One place where that seems to be a problem is with the T1w and T2w "setter" scans, which may be volumetric navigators.
The original protocol has the following scans:
- T1w_MPR_vNav_setter
- T1w_MPR_vNav
Which produces the DICOM folders:
- 1_T1w_MPR_vNav_setter
- Protocol Name: T1w_MPR_vNav_setter
- Series Description: T1w_MPR_vNav_setter
- Sequence Name: ABCD3d1_32ns
- Number of dicoms: 32
- 2_T1w_MPR_vNav_setter
- Protocol Name: T1w_MPR_vNav
- Series Description: T1w_MPR_vNav_setter
- Sequence Name: ABCD3d1_32ns
- Number of dicoms: 144
- 3_T1w_MPR_vNav
- Protocol Name: T1w_MPR_vNav
- Series Description: T1w_MPR_vNav
- Sequence Name: tfl3d1_16ns
- Number of dicoms: 176
- 4_T1w_MPR_vNav
- Protocol Name: T1w_MPR_vNav
- Series Description: T1w_MPR_vNav
- Sequence Name: tfl3d1_16ns
- Number of dicoms: 176
The only one we should want to in our BIDS dataset is 4, the corrected T1w volume. However, when I tried converting the names to ReproIn format, as below, there were problems:
- T1w_MPR_vNav_setter --> anat-scout_acq-setterT1w
- T1w_MPR_vNav --> anat-T1w
First, the T1w scan generates two sets of dicoms- one for the uncorrected scan and one for the corrected version. The uncorrected scan is flagged as a duplicate and is converted to nifti. It's not quite what I'd like, but it does seem reasonable and can be dealt with manually post-conversion.
Second, the setter generates two sets of dicoms. In the second set, the Protocol Name is the same as the protocol name for the T1 scan, even though the folder name, Series Description, and Sequence Name all reflect its nature as a setter. When using heudiconv with ReproIn, this leads to the second setter being treated as another duplicate of the anatomical scan, and we end up with ~100 extra __dup scans for each T1 acquired. I don't think this behavior is expected, and am not sure how to fix it, either in our protocol naming or in the heuristic file.
At our facility, most projects use sequences based on ABCD's protocol. One place where that seems to be a problem is with the T1w and T2w "setter" scans, which may be volumetric navigators.
The original protocol has the following scans:
Which produces the DICOM folders:
The only one we should want to in our BIDS dataset is 4, the corrected T1w volume. However, when I tried converting the names to ReproIn format, as below, there were problems:
First, the T1w scan generates two sets of dicoms- one for the uncorrected scan and one for the corrected version. The uncorrected scan is flagged as a duplicate and is converted to nifti. It's not quite what I'd like, but it does seem reasonable and can be dealt with manually post-conversion.
Second, the setter generates two sets of dicoms. In the second set, the Protocol Name is the same as the protocol name for the T1 scan, even though the folder name, Series Description, and Sequence Name all reflect its nature as a setter. When using heudiconv with ReproIn, this leads to the second setter being treated as another duplicate of the anatomical scan, and we end up with ~100 extra __dup scans for each T1 acquired. I don't think this behavior is expected, and am not sure how to fix it, either in our protocol naming or in the heuristic file.