Naming convention for "setter" scans for T1w/T2w

[tsalo]

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.

[yarikoptic]

and we end up with ~100 extra __dup scans for each T1 acquired

Smells like may be something to look to fix at dcm2niix level. What version of it do you have and either your have a set of phantom scans to share?

[tsalo]

Sorry for the delay. I don't think it's a dcm2niix problem, since "2_T1w_MPR_vNav_setter" would, in this case, be a mosaic, so converting it should generate a bunch of images from what I can tell.

I think the issue lies with the fact that ReproIn first checks ProtocolName for a valid ReproIn-compatible name, and then checks SeriesDescription if that fails. See here for the loop that checks the names and here for the order in which the fields are checked. When ends up happening is that the loop checks ProtocolName, which is anat-T1w in this case, finds a good name, and moves on. If it started with SeriesDescription, it would find anat-scout_acq-setterT1w and would flag the scan as a scout to be skipped.

This is related to nipy/heudiconv#387 (comment), where you touched on the idea of either switching the order in which ProtocolName and SeriesDescription are checked or coming up with something new.

Do you think it makes more sense to reorder the fields, to write a specific workaround for scouts, or to alter the seqname-determination step to use information from multiple fields at once?

[tsalo]

I tested out switching ProtocolName and SeriesDescription on my data, and, while it seemed to help with the navigator scans, it introduced a problem with single-band reference scans. While they should be named sub-XX_task-YY_run-01_sbref.nii.gz, after the switch they are named sub-XX_task-YY_SBRef_run-01_sbref.nii.gz. At minimum, I think this means that switching the priority of the fields in the heuristic will not solve all related issues on its own.

[cookpa]

Sorry for bumping an old thread, is there any solution to this that avoids having all the setter images converted as duplicate T1w / T2w?

[yarikoptic]

it has been awhile... and I started day starting to compose this comment and finishing the work day finishing it with

• @tsalo @cookpa -- do we (or you) have sample data of such kind? I am still not 100% certain on what we are dealing with and/or what we want to achieve, since AFAIK those derived (unless motion corrected) "sequences" should be skipped at https://github.com/nipy/heudiconv/blob/HEAD/heudiconv/heuristics/reproin.py#L385

• @tsalo -- in original description, you have

2_T1w_MPR_vNav_setter
- Protocol Name: T1w_MPR_vNav

and not

2_T1w_MPR_vNav_setter
- Protocol Name: T1w_MPR_vNav_setter

-- typo? or is that really so?

• @cookpa -- are you using reproin heuristic? according to @tsalo above mapping them into scouts at least partially addresses this issue. Which version of heudiconv do you use and how does your heuristic/naming looks like?

[cookpa]

Hi @yarikoptic, thanks for following up, sorry for the delayed response. I'm asking for a study that has not started yet, the plan is to use reproin naming but we have not got as far as defining a heuristic.

I have some existing data that does not use reproin, but has the problem above: some setter series DICOM images have ProtocolName = "T1w_MPR_vNav" and SeriesDescription="T1w_MPR_vNav_setter". The ImageType of the setter images is "ORIGINAL", so they don't get skipped as derived. I suppose they are not strictly derived, as they are acquired concurrently with the T1w / T2w image in order to assess motion in real time.

It seems that @tsalo tried switching the code to look at series description before protocol name, which allows the setters to be identified, but caused problems with sbrefs.

[yarikoptic]

have a look/try nipy/heudiconv#570 ?

[tsalo]

@yarikoptic sorry for the massive delay in responding.

@tsalo @\cookpa -- do we (or you) have sample data of such kind?

I don't have any DICOMs I can share, and I unfortunately am not able to scan any phantoms to create some shareable data.

@tsalo -- in original description, you have

I have DICOMs from after I renamed things according to ReproIn, and here are some of the DICOM header values:

(0008, 103e) Series Description                  LO: 'anat-scout_acq-setterT1w'
(0018, 0020) Scanning Sequence                   CS: ['GR', 'IR']
(0018, 0021) Sequence Variant                    CS: ['SK', 'SP', 'MP']
(0018, 0022) Scan Options                        CS: ['IR', 'WE']
(0018, 0023) MR Acquisition Type                 CS: '3D'
(0018, 0024) Sequence Name                       SH: 'ABCD3d1_32ns'
(0018, 1030) Protocol Name                       LO: 'anat-T1w_run-01'

So it looks like Protocol Name retains the name of the associated T1 scan, while Series Description uses the setter value I set. I think that means it wasn't a typo in my original post, because T1w_MPR_vNav was the T1 scan name and T1w_MPR_vNav_setter was the name of the setter scan. I hope that helps.

[yarikoptic]

Thanks @tsalo but seeing 3 completely different "Series Description", "Sequence Name" and "Protocol Name" I am confused now probably even more especially since none of those in your case have _setter suffix ;)
FWIW I was so confused that hacked myself a helper : nipy/heudiconv#572

you said that you "renamed to reproin" - do you mean on the console or somehow after?

[tsalo]

I am confused now probably even more especially since none of those in your case have _setter suffix ;)

Yeah, sorry about that! I don't have any DICOMs from those old scans, and I don't have any ABCD DICOMs either.

you said that you "renamed to reproin" - do you mean on the console or somehow after?

We changed the names on the console according to our best guess at a ReproIn style.

[cookpa]

The ABCD data is available through NDA, but getting to it involves going through the institutional data use agreement process and there are rules about not sharing it further.

The protocol is pretty confusing, in the sequence PDF (which IS available publicly at https://github.com/nih-fmrif/abcd_protocols/blob/master/ABCD_Prisma_VE11C_protocols__20190320d.pdf) the setter is mentioned explicitly:

ABCD_T1w_MPR_vNav_setter

This one produces a single "setter" image as its own series, with ProtocolName=ABCD_T1w_MPR_vNav_setter and SeriesDescription=ABCD_T1w_MPR_vNav_setter.

This is followed by

ABCD_T1w_MPR_vNav (page 8)

This one produces a multi-echo series (e1, through e4), an RMS series, and a series containing 100+ navigator volumes with ProtocolName=ABCD_T1w_MPR_vNav and SeriesDescription=ABCD_T1w_MPR_vNav_setter. This is the one causing the trouble.

I think @yarikoptic that your proposed fix will work, but I haven't been able to try it out yet. Thanks for your help with this issue.