You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make the archive more consistent and lightweight, it would be very effective to allow the user to query for arbitrary resolutions.
Implementation details
The TemplateFlow Archive would only keep the highest resolution of any given template. This has two nice side-effects: i) we will not hold-up any template for not having low-resolution conversion --this is, for instance, happening in the case of the UNCInfant template--; and ii) we do not need to have conversions for any object with a conversion at a higher resolution.
The template_description.json should keep the prescriptions of the original lower-resolution conversion (i.e., matrix size, zooms, and origin) so that it is still possible to generate those conversions with the exact same details they were originally designed with.
Whenever the client's API is queried with a resolution:
a. If the resolution is the highest, the original template files are returned.
b. If the resolution identifier (following BIDS-Derivs conventions) matches one of those kept in the template_description.json file, then resampling is done to that particular resolution.
c. If the resolution is some different type of object (we can think of migrating the Space object from niworkflows to here, or some such), then templateflow generates a new resampling scheme that matches whatever the user-specified. This can be just zooms, zooms + shape, and zooms + shape + origin.
Atlases can be queried for just coordinates (i.e., no grid necessary).
Resampling / interpolation
Uses nitransforms with the identity transform.
Potential pitfalls / downsides
This proposal adds enormous flexibility to users, complicating a bit the responsibility to ensure the reproducibility of downstream results. There are some strategies that could help ease this problem (i.e., trying to stick with the defaults whenever possible), this is a feature that could be easily misused.
Upshots
The archive is more lightweight
Conversions are more consistent (there are even cases where the different resolutions of a template are inconsistent)
Reduces a lot of frictions when using templates
Helps researchers do the right thing (e.g., querying for the label of any given coordinates should be always done at the highest resolution available).
Summary
To make the archive more consistent and lightweight, it would be very effective to allow the user to query for arbitrary resolutions.
Implementation details
template_description.json
should keep the prescriptions of the original lower-resolution conversion (i.e., matrix size, zooms, and origin) so that it is still possible to generate those conversions with the exact same details they were originally designed with.a. If the resolution is the highest, the original template files are returned.
b. If the resolution identifier (following BIDS-Derivs conventions) matches one of those kept in the
template_description.json
file, then resampling is done to that particular resolution.c. If the resolution is some different type of object (we can think of migrating the Space object from niworkflows to here, or some such), then templateflow generates a new resampling scheme that matches whatever the user-specified. This can be just zooms, zooms + shape, and zooms + shape + origin.
Resampling / interpolation
Uses nitransforms with the identity transform.
Potential pitfalls / downsides
This proposal adds enormous flexibility to users, complicating a bit the responsibility to ensure the reproducibility of downstream results. There are some strategies that could help ease this problem (i.e., trying to stick with the defaults whenever possible), this is a feature that could be easily misused.
Upshots
Requesting for comments: @satra, @effigies, @yarikoptic, @wiheto, @rciric.
The text was updated successfully, but these errors were encountered: