-
Notifications
You must be signed in to change notification settings - Fork 52
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: Make default native resolution explicit #494
Conversation
Best reviewed: commit by commit
Optimal code review plan
|
Codecov Report
@@ Coverage Diff @@
## master #494 +/- ##
==========================================
+ Coverage 62.86% 62.94% +0.07%
==========================================
Files 42 42
Lines 5098 5098
Branches 742 740 -2
==========================================
+ Hits 3205 3209 +4
+ Misses 1739 1735 -4
Partials 154 154
Continue to review full report at Codecov.
|
bbcb1ca
to
be05b4e
Compare
8f7df56
to
d830e55
Compare
This looks fine, but I'm missing where it changes anything but filenames. |
niworkflows/utils/spaces.py
Outdated
if ( | ||
val not in NONSTANDARD_REFERENCES | ||
and not val.split(':')[0].startswith('fs') | ||
and ":res-" not in val | ||
and ":resolution-" not in val | ||
): | ||
# by default, explicitly set volumetric resolution to native | ||
val = ":".join((val, "res-native")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@effigies res-native is already handled correctly, so this change just appends it to the output spaces by default if no resolution is specified
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I realize I have been pretty unclear on this one. When I said IMHO, spaces set via the --output-spaces
option should always fill a res-native
if no resolution modifier is specified I didn't mean that ReferenceSpace
should have always a res-native
. In other words, I would leave the responsibility of setting the res-native
when resolution is missing to the cli module of fMRIPrep.
This solution has a lot of potential side-effects. Have you tested it locally?
Check #334 |
@oesteban actually this shouldn't have much side effects, since the only time
that looks useful, but don't see how we can leverage it here - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I see your points. I'm most concerned about whether we are already sticking the res-
entity into the space input of the DataSinks. If so, then I think it is time to give them (the DataSinks) the love they deserve.
Also, I'm not convinced we should always drop the res-native
bit. If there are other resolutions we might as well keep it. DYT?
This case is not similar to space, for which there is indeed one space matching the original image (and therefore, since there's no change on the property, it should not be added to the filename).
if self.inputs.space and '_res-native' in self.inputs.space: | ||
# strip native tag | ||
self.inputs.space = self.inputs.space.split('_')[0] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just drop the resolution entity in the connection? Or the resolution entity is currently crammed into the space input in fMRIPrep and you are working around that hacky solution (honestly, I can't remember)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the resolution is appended to the space input, a hack we implemented to allow multiple resolutions of the same template
@@ -660,10 +660,14 @@ def __call__(self, parser, namespace, values, option_string=None): | |||
spaces.checkpoint() | |||
for val in values: | |||
val = val.rstrip(":") | |||
# Should we support some sort of explicit "default" resolution? | |||
# https://github.com/nipreps/niworkflows/pull/457#discussion_r375510227 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we keep this reference and add a reference to this PR as comments?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure
I went back and forth here - ultimately I went with the route of least changes to the documentation. Do we want to make this explicit now (its been implicit for a long time) at the cost of renaming the expected output files? If we have other resolutions, those others will have the |
I'm also bouncing back and forth on this one. WDYT @effigies ? |
I would lean toward keeping it invisible. res/den are only required to distinguish from another file. The goal of BIDS is not to put all relevant metadata in the file name but to help people quickly distinguish files. All other resolutions will have a |
great, thanks for the reviews! |
Sets the default value of volumetric references resolution to native.
Originally discussed in #457 (comment), looks it is needed.
Addresses nipreps/fmriprep#2060
nipreps/fmriprep#2000