[BUG]: Correct path propagation logic for ReHoEstimator and ALFFEstimator #286
No reviewers
Labels
No labels
CRITICAL
Stale
WIP
bug
concept
coordinate
dataset
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
maintenance
maps
marker
mask
on hold
parcellation
preprocess
question
ready
storage
template-space
triage
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
juaml/junifer!286
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/reho-falff-path-propagation-native"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR fixes the path propagation logic for
ReHoEstimatorandALFFEstimatorbased on the input data space. If the input data space is "native", the original input data path is passed down for further use inget_coordinates()(as of now) for transforming coordinates to subject-"native" template space, else the actual ReHo and (f)ALFF map paths are passed down.Codecov Report
Attention:
4 linesin your changes are missing coverage. Please review.Additional details and impacted files
100.00% <ø> (ø)89.44% <75.00%> (-0.09%)Flags with carried forward coverage won't be shown. Click here to find out more.
76.19% <ø> (ø)90.00% <ø> (ø)92.59% <ø> (ø)93.10% <ø> (ø)93.93% <75.00%> (-1.94%)68.18% <75.00%> (-0.90%)I don't fully agree with this solution though. I still do believe that the data and the path should point to the same object.
Nevertheless, this is a patch for the current main branch.
I would like to see this fixed when we have multi-mni space support. In that case, the img2imgcoord could simply get the T1w of the right space from templateflow and then we will not need this patches.
Can you please create an issue so we rollback this hack in the future?
I don't have a better solution atm, please do share if you have a better one. I agree with you that the data and the path should point to the same object. The next thing we want is multi-MNI template space support, so if the solution is not too convincing, we can close this PR and get the multi-MNI support which would fix this as well. Of course, if you think we go with this, I'll make an issue to revert this.
For the moment this works and it's ok. I just want to document that this needs to be removed when multi-MNI space is added.