Resample to T1w or use q/s-form for ``space-T1w`` BOLD outputs?

[oesteban]

After working on #1646 and consideration of https://github.com/poldracklab/fmriprep/issues/1376#issuecomment-470464912 I wanted to open the question whether the space-T1w images should be resampled into T1w space (as they are currently generated) or maybe we should just update the s/q-form headers to let the user do the resampling when needed.

Maybe adding a modifier to the --output-spaces keyword would be appropriate. No modifier means resampling (current behavior), but --output-spaces T1w:xform would enable this other option.

WDYT @jooh, @effigies?

[satra]

@oesteban - just to clarify, you mean keep the moving image in its original resolution?

[oesteban]

Essentially yes (provided that by moving image you mean the BOLD run). Since the co-registration to the T1w is affine, the proposal would be to compose the appropriate affines (headers and registration) and rewrite the s/q-form matrix of sub-01_task-rest_run-1_space-T1w_bold.nii.gz files.

A question would be whether we want to limit the t1-bold coregistration to only 6 parameters, so that we can keep setting both q and s forms to the same affine.

[satra]

@oesteban - bbregister allows 9 and 12 dof registration. as long as you don't enable that, you should be ok with restricting to 6.

[oesteban]

Yep. Alternatively, we could restrict to 6 only when susceptibility distortion was not corrected for (although I'm of the opinion that only 6 parameters should be allowed).

[effigies]

I don't think we have to add a new keywords to --output-space. It looks like we have two cases:

1) 6-dof BOLD-T1w registration, which can be done with less interpolation by updating the header. 2) >6-dof BOLD-T1w registration, which requires resampling.

How about we do the header update if --bold2t1w-dof 6, and resample otherwise? Is there ever any advantage to resampling in case 1?

Also, I think 9-dof could be done if you're willing to update the voxel sizes in the header, but that might not be accepted practice...

[oesteban]

Sorry, I probably mixed up conversations.

Problem 1 is whether we should/want to add the possibility of avoiding resampling of space-T1w_*_bold derivatives, assuming we want to keep the current behavior. That would require two things:

1. Adding some language to the CLI (and hence, the T1w:xform proposal)
2. Ensuring we can actually just rewrite the xforms because the registration was 6-dof. If we still want to keep 9-dof, then we would only write the s-form (deviating from what we've been doing as standard for fMRIPrep this far).

Problem 2 would go beyond the scope of how outputs should be written. In this case the question would be whether we want to allow >6-dof for T1w-to-BOLD registration. I'm inclined to think that it should be 6-dof only (regardless what we decide in terms of resampling/xforms).

[effigies]

My question was whether there's any good reason to keep around the resampling behavior for 6-dof, thus necessitating another --output-space keyword. Now that I come to think of it, however, it's because if you want to look at a voxel across runs, you need them to be resampled to a common space.

This is somewhat frustrating, as I'd rather our CLI not turn into antsRegistration and become its own programming language.

[oesteban]

Now that I come to think of it, however, it's because if you want to look at a voxel across runs, you need them to be resampled to a common space.

I failed to describe this as the background for Problem 1 this clear, thanks.

This is somewhat frustrating, as I'd rather our CLI not turn into antsRegistration and become its own programming language.

Totally :D

[mgxd]

@oesteban i think this can be closed after nipreps/smriprep#219?

[oesteban]

Nope, this is a different suggestion. The idea here is whether conversions should be resampled or use the s/q-form instead. It is related, but not exactly the same.