How to handle scanner derivatives?

[mirestrepo]

Hi! we are trying to use the reproin naming at scanner and heuristic for conversion.
Our scanner generates some extra files for instance for sagittal, coronal and tranverse planes. I am assuming they should go into derivatives folder, but I not sure how to indicate so to the reproin heuristic. Any pointers are greatly appreciated. Thank you!

[yarikoptic]

As long as it is done by the scanner, and not you on the MR console, nothing for you to worry about, and reproin should work. Those derivatives (processed at the scanner) likely to be ignored ATM, or get some _proc or _rec suffix, don't remember. The best approach, is to scan some phantom, run conversion, if something to be fixed in reproin or heudiconv, share that data so we could make it all work as desired.

[mirestrepo]

Thanks for the guidance!
Our fist issue is with the scouts and localizer but #35 helped me a lot. The issues for the localizer happen because the scanner adds _sag _cor _tra to the names ... but I could ignore those if I just name them anat-scout

The second issue are the trace and fa for diffusion ... as the scanner adds _TRACEW and _FA to the name, but this discussion suggests we can turn those off at the scanner.

The last question is what to do with the RMS combined data. E.g. We have two sequences:

• anat-t1w_acq-memprage
• anat-t1w_acq-memprage rms

Thanks!

[yarikoptic]

what is RMS combined data in this case of T1w?

[mirestrepo]

It is the RMS of 4 echoes.

For the non RMS sequence, ffter Heudiconv+Reproin I get something along the line:

sub-116_acq-memprage_T1w__dup-011.json
sub-116_acq-memprage_T1w__dup-011.nii.gz
sub-116_acq-memprage_T1w__dup-012.json
sub-116_acq-memprage_T1w__dup-012.nii.gz
sub-116_acq-memprage_T1w__dup-013.json
sub-116_acq-memprage_T1w__dup-013.nii.gz
sub-116_acq-memprage_T1w__dup-014.json
sub-116_acq-memprage_T1w__dup-014.nii.gz

Instead I think I would like it to do:

sub-116_acq-memprage_echo1_T1w
sub-116_acq-memprage_echo2_T1w
sub-116_acq-memprage_echo3_T1w
sub-116_acq-memprage_echo4_T1w

Thanks!

[mirestrepo]

Hi Again - We have figured most of the cases.

HeuDiConv now gives us the echoes as expected:
sub-116_acq-memprage_echo-1_T1w the BIDS validator complaints that the echo files don't have a valid naming scheme. Do you spot anything unusual? or are echoes not allowed in the anat types?.

Thanks

[yarikoptic]

Not ATM afaik

See bids-standard/bids-specification#223 for more information and please chime in with your use case (are they both really T1w?)

[mirestrepo]

For MEMPRAGE I've seen recommendations similar to this one to keep the echoes. While most researchers user the RMS only, I think it's best to also keep the echoes. So I was just wondering if they can be kept them in a BIDS compliant way. I'm happy to chime in the other discussion, if you think it's useful.

Thank you for all your answers. They are much appreciated!

[mirestrepo]

👋 @yarikoptic we are still having issues with our derivatives as they end up polluting our BIDS directory and failing validation. We don't want to turn them off at the scanner and we would like to still have them somewhere for reference (sourcedata or derivatives). The ReproIn heuristic has code(to ignore them, but the boolean seems to be hardcoded to False. It also has code to put them in a derivative folder but that one is commented out. So I'm unsure what the best way to handle them is. We could write a post-processing step to move them out of the bids directory, that that gets messy because we need to touch other files too. Any recommendations?