Concatenating different runs

[arokem]

Some protocol/scanner combinations require starting the scanner multiple times (as an example, some GE scanners cannot collect more than 150 (160?) volumes in a single scan, so if you want to collect HCP-like data, you're going to have to scan (at least) twice.

How to handle this? My suggestion:

1. Within each run, register the b=0 volumes to the first b=0 volume in the run.
2. Compute a mean b=0 for each run.
3. Register the mean b=0 volume from runs 1...n to the mean b=0 in run 0.
4. Move all the volumes in each run by applying the registration computed in step 3 for that run.
5. Concatenate all the volumes from step 4 across runs and register each volume to the overall mean b=0 volume, storing the combined transformation for each volume (including that computed in step 3 + that computed in step 5).

The advantage of this algorithm is that I think that it might work well for different situations (e.g., a subject who moved a lot between runs, vs. a subject who stayed very still, where the main difference would be the magnitude of the transformation computed in step 3).

Risks I can think of are asymmetric propagation of error between different runs (run 0 vs other runs in particular), but I would have think more about that.

Other thoughts/suggestions?

[arokem]

I should say, this goes hand in hand with a proposed change to the BIDS spec to allow multiple runs of diffusion within a session.

[arokem]

Tagging in @jyeatman for his thoughts: I think that you've collected a lot of data in this format (e.g., different runs with different b-values). If I remember correctly, your approach in the past has been to separately preprocess each run and then combine after preprocessing. What are your thoughts on the procedure outlined here?

[oesteban]

Looking forward to Jason's opinion. And agree with @arokem that it feels best to process each run separately.

[oesteban]

I should say, this goes hand in hand with a proposed change to the BIDS spec to allow multiple runs of diffusion within a session.

Working on this right now. It seems the run- entity is allowed for DWI. I'm trying to think whether additional metadata would be appropriate and I might take a stab at bids-standard/bids-specification#239 and bids-standard/bids-specification#263 at once.

[jyeatman]

Yes there are many times when you would want to concatenate separate runs. Ariel's proposed pipeline is good. Here are some examples of when we concatenate across separate runs:
-Many older scanner softwares can only collect 1 b-value in a run. So multi-shell data is collected across separate runs but should (usually) be concatenated for analysis
-Reversed phase encode volumes are usually collected in separate runs

A general way to solve this might be a user input that notes which volumes to concatenate and which to process separately

[oesteban]

Interesting thread @dPys linked from the shared document https://community.mrtrix.org/t/organizing-data-for-dwipreproc/1846/10

[oesteban]

Comments on the proposed procedure:

1. Within each run, register the b=0 volumes to the first b=0 volume in the run.

Questions:

• Run an initial N4 step on each to make brain-extraction and registration more reliable? Can the B1 field be assumed constant within runs? Can it across runs? (if so, you could use the field estimated on the first b=0)
• Independently brain-extract each b=0 before registration?
• Run regression to the mean (within the brain mask) of the first b=0 to account for signal drift?
• Tool for registration:
  • MCFLIRT (FSL) is noncommercial BUT, we could almost copy and paste from fMRIPrep.
  • 3dVolreg (AFNI) does not play nicely with oblique datasets (ENH: Setting up a battery of tests nipy/nitransforms#9)
  • antsMotionCorrect misses Nipype interface ([FIX] Replace FSL mcflirt with AFNI 3dVolReg fmriprep#1354 (comment))

2. Compute a mean b=0 for each run.

• Run N4 to remove B1 bias field on each average, using the brain mask for a more accurate estimation?
• Re-calculate a more precise brainmask?

/cc @josephmje - how do you see these steps 1 & 2, in light of #25?

3. Register the mean b=0 volume from runs 2...n to the mean b=0 in run 1.
4. Move all the volumes in each run by applying the registration computed in step 3 for that run.
5. Concatenate all the volumes from step 4 across runs and register each volume to the overall mean b=0 volume, storing the combined transformation for each volume (including that computed in step 3 + that computed in step 5).

I'd like to propose an alternative here:
3. Run registration within each run to the average b=0 of that run.
4. Run registration between b=0 averages.
5. Combine transforms obtained in 3 and 4, instead of resampling data ("move") before the final registration step.

If there is a basis to think an overall registration step would be interesting, the resampling and registration step would still be a refinement option. If the registration tool we finally choose can take a list of affine transforms for initialization, then this overall registration step would certainly be a good option.

[arokem]

On Sun, Jan 12, 2020 at 6:27 PM Oscar Esteban ***@***.***> wrote: Comments on the proposed procedure: 1. Within each run, register the b=0 volumes to the first b=0 volume in the run. Questions: - Run an initial N4 step on each to make brain-extraction and registration more reliable? Can the B1 field be assumed constant within runs? Can it across runs? (if so, you could use the field estimated on the first b=0)

I think that this would depend on how much motion occurred (?) In general, I am not sure that I understand why you would apply bias correction to DWI. In most applications I can think of, one normalizes the DWI by the b=0 and this would presumably divide out the bias term(?)

- Independently brain-extract each b=0 before registration? Yes. That seems like a good idea. - Run regression to the mean (within the brain mask) of the first b=0 to account for signal drift? - Tool for registration: - MCFLIRT (FSL) is noncommercial BUT, we could almost copy and paste from fMRIPrep. - 3dVolreg (AFNI) does not play nicely with oblique datasets ( nipy/nitransforms#9 <nipy/nitransforms#9>) - antsMotionCorrect misses Nipype interface (nipreps/fmriprep#1354 (comment) <nipreps/fmriprep#1354 (comment)> )

One more option is to use the DIPY affine registration (see https://dipy.org/documentation/1.1.1./examples_built/affine_registration_3d/). It's a Python + Cython only implementation that should be very similar to `antsMotionCorr`

1. Compute a mean b=0 for each run. - Run N4 to remove B1 bias field on each average, using the brain mask for a more accurate estimation? - Re-calculate a more precise brainmask? /cc @josephmje <https://github.com/josephmje> - how do you see these steps 1 & 2, in light of #25 <#25> ? 1. Register the mean b=0 volume from runs 2...n to the mean b=0 in run 1. 2. Move all the volumes in each run by applying the registration computed in step 3 for that run. 3. Concatenate all the volumes from step 4 across runs and register each volume to the overall mean b=0 volume, storing the combined transformation for each volume (including that computed in step 3 + that computed in step 5). I'd like to propose an alternative here: 3. Run registration within each run to the average b=0 of that run. 4. Run registration between b=0 averages. 5. Combine transforms obtained in 3 and 4, instead of resampling data ("move") before the final registration step.

I need to think about this a bit more, but that sounds right to me.

…

If there is a basis to think an overall registration step would be interesting, the resampling and registration step would still be a refinement option. If the registration tool we finally choose can take a list of affine transforms for initialization, then this overall registration step would certainly be a good option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#43?email_source=notifications&email_token=AAA46NVV34E7WHTPSSOJJX3Q5PGQPA5CNFSM4JVOZUI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXLX5Q#issuecomment-573488118>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA46NTI57V4JUGGXM3EFNTQ5PGQPANCNFSM4JVOZUIQ> .

[oesteban]

In general, I am not sure that I understand why you would apply bias correction to DWI. In most applications I can think of, one normalizes the DWI by the b=0 and this would presumably divide out the bias term(?)

I'm not suggesting doing the bias correction on the DWI, just the b=0 - and because it potentially makes registration more robust.

Since the average b=0 will be used to normalize DWI signal (in model fitting, i.e., beyond the scope of dMRIPrep potentially), it makes sense to keep the INU corrected b=0 internal for registration processes and only expose the average b=0 that the user will use for normalization (and canceling out the INU).

One more option is to use the DIPY affine registration (see https://dipy.org/documentation/1.1.1./examples_built/affine_registration_3d/). It's a Python + Cython only implementation that should be very similar to antsMotionCorr

Is that implementation actually using ANTS underneath? If so, I'd rather stick with Nipype with the hopes that the next version of the workflow will allow us to do really cool stuff.

I need to think about this a bit more, but that sounds right to me.

Yup! food for though tomorrow :)

[oesteban]

Okay, friends, I took a stab and drafted something for the BIDS specs. Please send your feedback to bids-standard/bids-specification#622.

I will try to address the actual problem stated originally (i.e., how to encode the intent of the researcher regarding the combination of dwi runs) in another separate PR today or tomorrow.

[oesteban]

We just touched sideways on the topic in our latest meeting, but I think dMRIPrep should not attempt to combine these runs at all.

I think our push in the BIDS spec has been very positive. With those changes and dMRIPrep's outputs, it will be possible for researchers to combine data the right way.

Closing the issue (feel free to reopen if you don't agree with this take)