Clarification for protocol naming conventions

[dlevitas]

Hello,

I've read through the walkthrough and source code for how to properly name the protocol sequences, but have a few questions I was hoping to get clarified.

1). For spin echo fieldmaps, it is appropriate to simply name them fmap_run-01, fmap_run-02? I like to keep the names short if possible, which is why I haven't specified _dir. Also, is there a specific way to name fieldmaps with magnitude and phasediff?

2). Our current naming convention for multi-echo anatomicals is:

tfl_mgh_multiecho
tfl_mgh_multiecho
tfl_mgh_multiecho RMS RMS

but could this just be anat-T1w?

3). For a dwi B0 acquisition, would dwi_acq-b0 work?

4). Some of our protocols contain audio tests or other miscellaneous stuff that is not necessary for BIDS. Since these shouldn't be converted, should they be be referred to as ```scouts```` or something else?

Sorry for the barrage of questions, and thanks for the help.

Dan

[dlevitas]

Just wanted to ping this

[yarikoptic]

Hi Dan, sorry for the delay. I am not ignoring, just seems too busy for a good reply... started to compile the reply, but never finished. Here is the beginning/draft:

Well, quite a loaded single question, isn't it? ;)

Overall -- the idea with ReproIn we should stick to regular BIDS as close as possible for various reasons.

One of the culprits with multi-echo files is that generalizing relevant BEP for those is still WiP: https://github.com/bids-standard/bep001 . I would advise you to review that effort and possibly express your opinion there and/or simply join the effort. Myself I have tried to grasp some ideas with groupping suffixes, but yet to "read on more"

As for all the multi-echo support in heudiconv -- there is some, and there is more todo. Please review https://github.com/nipy/heudiconv/search?q=multi+echo&unscoped_q=multi+echo

[dlevitas]

Thanks @yarikoptic!

Yea, I'm working with my institution's MRI center and want to see how the different protocol scans would need to be named to work with Reproin. I may try a "simple" protocol with just anat, func to see how the BIDS conversion works, and then build up to the less common scan types.

[yarikoptic]

and I would recommend collecting sample acquisition (what is your scanner?) DICOMs on phantom, so they could be shared and we see how things should be adjusted. While trying, use current master of heudiconv (we should probably kick out release soon) so you could see what is happening to multi-echo sequences already.

and yeah -- for spin echo fieldmap, just make them e.g. fmap_dir-AP and fmap_dir-PA. Add _run or different _acq (e.g. _acq-dwi and _acq-func) if you have multiple of those pairs for different modalities. ATM we have not coded in yet how to establish IntendedFor fields so it will be up for manual changes there anyways.

[dlevitas]

We have a Siemens Prisma scanner, and yes, we're planning on running some mock protocols on phantoms. More than happy to share that data in the future.

Regarding multiple SE pairs, I made a post (NS5053) about how to name them via runs, just for reference.

Ah, that's unfortunate about the IntendedFor SE metadata fields, but makes sense, given how much of an issue that can be. Personally I use a system of checking for all functional data in the same section as a SE field map pair, where a section is everything from one localizer to the next localizer. Any functional data in the same section as the SE field maps is then included in the IntendedFor field

[dlevitas]

I'd like to reopen this to clarify 3 things:

1). The SeriesDescription for the field map cases described in the BIDS spec. Specifically, the cases of 2 phase & 2 magnitude images, and 2 magnitude images & 1 phasediff. It's not clear to me how the code would want these SeriesDescriptions labeled, but would these be acceptable?

2 phase & 2 magnitude fmap-phasemag

2 magnitude & phasediff fmap-magphasediff

I realize that dcm2niix will output multiple nifti/json pairs for these acquisitions, but that the exam card only needs these listed once.

2). In the SeriesDescription, can acq contain multiple paramters (eg. *_acq-0p8mm-2tr)? In this example the two parameters being stored are the resolution and TR.

3). Is there an accepted term that designates a non-BIDS acquisition? For example, at my facility, some researchers collect idiosyncratic acquisitions for their own purposes but that aren't part of the BIDS specification. I know that with localizers the scout term is often used to remove them from BIDS conversion, so I'm curious if there is a general term for other non-BIDS acquisitions

[dlevitas]

Hi @yarikoptic, I just wanted to ping this thread, since I'm unsure how to best handle these cases in ReproIn. Sorry for the barrage of questions

[yarikoptic]

1) For a regular fieldmap, I think just fmap would be good enough. IIRC we do not rely on any additional information and rely on information from dicom to deduce correct combination of files in every case. For pepolar pairs, you need to provide _dir-<AP|PA>

2) acq value is freeform, you can specify anything. BIDS doesn't allow - in the value though, so they would be replaced with X

3) if we do not recognize something following reproin convention, we skip it. I think that happens here: https://github.com/nipy/heudiconv/blob/master/heudiconv/heuristics/reproin.py#L547

in general, e.g. in case of 1 or 2 questions, I would just recommend to "try" on some phantom on some short sequence. That would tell you "if reproin/heudiconv works" and give shareable data to demonstrate if doesn't

[dlevitas]

Sounds good, once we have a working phantom ReproIn dataset, we'd be more than happy to share on DataLad. For reference, we'll probably be collecting phantom data to match this tutorial dataset, which contains two separate fmap acquisition types, so we'll see how ReproIn handles them.

[yarikoptic]

re tutorial

• why not to use miniconda with conda-forge channel? installation of all the tools would be much easier. dcm2niix and heudiconv are available through conda
• note that there are docker and singularity containers available for heudiconv and reproin. Might also simplify "getting started" and also would make more YODA friendly. FWIW, could even try going "YODA&datalad" all the way doing smth like https://github.com/ReproNim/containers/#a-typical-workflow

[dlevitas]

These are good points. At the time of writing the tutorial, I wasn't aware of those tools/setup, but if things go well with Reproin then I'll likely rewrite the section; Andy's very lenient with rewrites.

On Tue, Feb 2, 2021, 5:50 PM Yaroslav Halchenko notifications@github.com wrote:

re tutorial

• why not to use miniconda with conda-forge channel? installation of all the tools would be much easier. dcm2niix and heudiconv are available through conda
• note that there are docker and singularity containers available for heudiconv and reproin. Might also simplify "getting started" and also would make more YODA friendly. FWIW, could even try going "YODA&datalad" all the way doing smth like https://github.com/ReproNim/containers/#a-typical-workflow

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/ReproNim/reproin/issues/36#issuecomment-772068002, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF62JDZ3SANVOP34XFAY7E3S5B6SXANCNFSM4IQNZLQQ .