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

ENH: Add flag for STC reference time and set in all cases #2520

Merged
merged 6 commits into from
Sep 2, 2021

Conversation

effigies
Copy link
Member

This PR partially address #2477 by providing a flag --slice-time-ref that can take a float from 0-1 or special values "first" and "middle".

This also always sets the -tzero flag for 3dTshift (in cases where we run STC) to min + frac * (max - min), which will generally be frac * max. This should be the same as 3dTshift's default of mean(SliceTiming), as well as frac * max, but I update the text to be explicit as well.

Millisecond precision is used in reporting.

Closes #2516.

@@ -107,7 +107,7 @@ def init_bold_stc_wf(metadata, name='bold_stc_wf'):
inputnode = pe.Node(niu.IdentityInterface(fields=['bold_file', 'skip_vols']), name='inputnode')
outputnode = pe.Node(niu.IdentityInterface(fields=['stc_file']), name='outputnode')

LOGGER.log(25, 'Slice-timing correction will be included.')
LOGGER.log(25, f'BOLD series will be slice-timing corrected to an offset of {tzero:.3g}.')

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the example in lines 69/70 (2s TR, 0-0.9), this would then yield an offset of 0.45, correct? I think that printing/logging this as an output rather than the intended time offset (1s) may be a bit confusing. I'd opt for printing/logging the intended time offset.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what you mean by the "intended time offset" here. The default 3dTshift behavior sets tzero to the middle of the acquisition time (0.45), as does the proposed default behavior here. I'm not sure under what circumstances you would expect to see 1s.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for not being clearer! The point was that it would perhaps be easier for users to know what the temporal offset is not in terms of percent but in terms of time. Else they might be confused that putting in 0.5 for a TR of 2s returns 0.45 and not 1s. Hope that’s clearer?

Copy link
Member Author

@effigies effigies left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall I think this is ready to go. Please let me know if I haven't addressed your concerns, @martinhebart.

@effigies effigies added this to the 21.0.0 milestone Sep 1, 2021
@mgxd mgxd merged commit fbde5b6 into nipreps:master Sep 2, 2021
@nitschalex
Copy link
Contributor

Thanks for adding this @effigies!

@effigies effigies deleted the enh/stc_ref_flag branch September 8, 2021 15:47
effigies added a commit to effigies/fmriprep that referenced this pull request Sep 30, 2021
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

Successfully merging this pull request may close these issues.

Slice timing correction options
4 participants