[ENH]: Introduce get_template for getting templates #298
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!298
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/get-template"
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 introduces a new function
junifer.data.get_template()to get template space images viatemplateflow, tailored to a target data.Codecov Report
Attention:
2 linesin your changes are missing coverage. Please review.Additional details and impacted files
89.15% <89.47%> (-0.01%)Flags with carried forward coverage won't be shown. Click here to find out more.
100.00% <100.00%> (ø)100.00% <ø> (ø)90.47% <88.88%> (-9.53%)Should be merged after #297
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreWe need to get the "closest resolution" here
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreThe
closest_resolutionfunction takes a list of valid resolutions, but we don't have that info right away. For that we need an extra scraping of the templateflow metadata which adds a bit of overhead. I don't get the complete rationale, maybe I can implement it in a different way if I understand correctly.@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreThe idea of that function is to tell you which is the resolution of the parcellation/mask/etc that you need to use for the image you have.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreWe are already getting the resolution for the template required from the target data and it needs to be int for templateflow. If templateflow doesn't have that, it throws an error. So in that case, we need to resample.
Also
closest_resolutionworks for parcellations and masks as we already know the available resolutions for them.@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreExactly, basically the
closest_resolutionfunction will tell you which one to get in case you don't have the resolution of your image@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreBut in our case, we have it and we fetch accordingly.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreno, we don't have "any" resolution. We have some resolutions. Templateflow is the same. We have A, B, C and D as resolutions. Let's say our image is in resolution E. We need to get the "closest" to E following the criteria defined in the "closest resolution" function.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreSo there are two options:
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreJust to put it here,
closest_resolutionis used in functions likeload_parcellationandload_maskwhere one can choose the resolution, but in functions likeget_parcellationandget_mask, we use the target's resolution to resample the data obtained viaload_*functions.@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreJunifer needs to able to run without network connections. My take is to scrape on the first time and save in the
junifer_datadirectory (if we follow the scrape option).My issue with hard-coding the resolutions is what might happen if templateflow adds a new resolution. We might need to update the code.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreTemplateflow does the caching so should be able to work without network connection. To make this clean and work in a global way, it's better to have something like a
junifer precachecommand which downloads required data for datagrabber, parcellations, masks and template spaces.@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignore100% agree with the
precache. I though of calling itprefetch. And that's why everything that is donwloaded (like parcellations) are stored in thejunifer_datadirectory, to make it explicit and permanent across nodes/sessions/users.In this case, check which of the above solutions works best in your opinion.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreI would want to make a separate PR tackling this specific feature and come back to
get_templatethen. What do you think?@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreDo you mean
precache? Yes, that's a totally separate PR.@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreYes.
For this PR, the scraping won't be optimal until we have precache.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreFirst we make it work, then we optimise.
@ -92,0 +160,4 @@klass=RuntimeError,)else:return nib.load(template_path) # type: ignoreThe latest commits should address your concern.