Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming convention for "setter" scans for T1w/T2w #40

Open
tsalo opened this issue Oct 23, 2019 · 11 comments
Open

Naming convention for "setter" scans for T1w/T2w #40

tsalo opened this issue Oct 23, 2019 · 11 comments

Comments

@tsalo
Copy link

tsalo commented Oct 23, 2019

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
Copy link
Member

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
Copy link
Author

tsalo commented May 9, 2020

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
Copy link
Author

tsalo commented Jun 26, 2020

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
Copy link

cookpa commented May 19, 2022

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
Copy link
Member

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

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
Copy link

cookpa commented Jun 6, 2022

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
Copy link
Member

have a look/try nipy/heudiconv#570 ?

@tsalo
Copy link
Author

tsalo commented Jun 7, 2022

@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
Copy link
Member

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
Copy link
Author

tsalo commented Jun 8, 2022

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
Copy link

cookpa commented Jun 9, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants