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

Anisotropic template resolutions #1037

Closed
thijsdhollander opened this Issue Jul 5, 2017 · 4 comments

Comments

@thijsdhollander
Member

thijsdhollander commented Jul 5, 2017

...aren't fun or anything we'd like to have in our studies. We saw them recently popping up everywhere. The reason is mraverageheader and the changes made to it, that were (I believe) intended to deal with slice angulations larger than 45 degrees. As I mentioned over email, I understand the issue and the how/why what has happened here, but in context of population_template, I don't think it still makes as much sense, especially since non-rigid alignment still happens... and actually even in the absence of that too. The gist being that we don't know the resolution relative to the anatomy, and it's the latter that defines what can reasonably be encoded in a template without stretching the information content in the data. I could write up a paper about it, but I don't have the time, and I believe everyone that's into this understands all arguments from all (historical) sides enough now. Here's a few copy-pastes of my earlier email for added value:

.... due to mraverageheader obviously. A very quick inspection shows that it works with "projected resolutions". Even with the "-resolution max" option, this will happen: it does choose the maximum, but still of projected resolutions, so in any realistic case with slice angulations, you'll get an anisotropic template resolution that is strictly lower than the isotropic (upsampled) resolution of 1.25mm^3 that we typically feed in. ....

....

.... I understand the trouble with the resolutions, and I do understand the incentive behind the logic of the projections, but this is not what we want in practice for an FBA study, I would personally say. While from a sort of scientific "mraverageheader" point of view, there may be correct reasons, there are valid scientific arguments for why population_template can happily work with the original, or even perfectly even higher, resolutions. All an mraverageheader step in this context should really do, is generate a grid at an average orientation. The resolution of that grid becomes a separate matter in the context of building a template. It's not my call, but if I were you, I'd simply give population_template a voxel size option, and immediately set the grid (e.g. provided my mraverageheader) to that resolution via any means (e.g. just resize it or something). If the user doesn't provide the voxel size option to population_template, I would personally have it be an isotropic resolution that yields an (isotropic) voxel volume that is the same as the average volume of all input voxel sizes. This is the safest unbiased resolution you can argue for: especially note that the non-rigid registrations actually undermine any arguments for the current projected resolutions. Based on the original grids only, you've got no anisotropic information on resolutions relative to the anatomy of input subjects, relative to how those anatomies become (locally) oriented after warping into the final template. But for unbiased registration, and even more so unbiased tractography and CFE afterwards, the best you can go for is an isotropic template resolution, even when the input resolutions are anisotropic, and even if the latter happens in a case without slice angulation (because that still doesn't inform you about the resolution relative to the anatomy). The nice thing about such a default is that if we input e.g. isotropic 1.25mm^3 voxels, we'll again automatically get that same resolution in the template. ....

....

Just my 2 cents. Happily proceed as you wish... I assigned some random people to get input going. I labelled it "critical" because a lot of people over here have recently used population_template and have the effects of this in their FBA pipeline. If those need to be redone, that's quite a bit of computation time, and also a bit of people-time.

@maxpietsch

This comment has been minimized.

Show comment
Hide comment
@maxpietsch

maxpietsch Jul 5, 2017

Member

Anisotropic template resolutions aren't fun or anything we'd like to have in our studies. We saw them recently popping up everywhere. The reason is mraverageheader and the changes made to it, that were (I believe) intended to deal with slice angulations larger than 45 degrees.

mraverageheader has never produced isotropic voxel grids if the input images do not have identical voxel to scanner transformations. However, the changes I made to mraverageheader (which were merged into master with RC1) produce coarser voxel grids than previously which was an unintended side-effect of the changes I made to accommodate large rotations between input images.

For registration, there is always a tradeoff between potential bias, data size and loss of information due to undersampling. Imagine two input images with identical transformations but different voxel sizes. Currently, the average grid uses the average voxel size of the two input images which should be unbiased but loses information of the higher resolved image. Using the highest resolution would bias it towards one image. One could argue that super-resolving both images is sensible, especially for nonlinear registration but this increases the computational, memory and storage cost and might introduce undesired side effects during registration such as being stuck in local minima if the original voxels were very anisotropic.

I'd simply give population_template a voxel size option, and immediately set the grid (e.g. provided my mraverageheader) to that resolution via any means (e.g. just resize it or something). If the user doesn't provide the voxel size option to population_template, I would personally have it be an isotropic resolution that yields an (isotropic) voxel volume that is the same as the average volume of all input voxel sizes.

I agree, I don't think there is a principled way of defining the "best" grid size so we should provide a sensible default and offer the option to change it. Using the average voxel volume and isotropic voxels is not ideal for anisotropic voxels. If you prefer isotropic voxels, I'd suggest using the smallest voxel edge length which is at or above the Nyquist sampling density depending on the relative orientation of the input images.

For the template, it very much depends on the input data's resolution and on the Jacobian of the warp fields what a sensible default is. I don't have much experience with FBA but for analysis in subject-space, I suspect that since we already suggest to upsample the input data, spatial frequency content beyond that of the original data's is unlikely to contribute meaningful information especially as in template space we're likely limited by the anatomical resolution and variability.

But for unbiased registration, and even more so unbiased tractography and CFE afterwards, the best you can go for is an isotropic template resolution, even when the input resolutions are anisotropic...

Can you elaborate on the bias you'd expect to see with anisotropic voxels?

Anyway, I'll add an option to population_template to resize the average space grid to whatever the user wants or deems to be fun. I'd prefer to add those changes to the registration_multi_contrast branch as it is my current work in progress branch which includes many changes to population_template such as multi-tissue template generation. I don't see the urgency of merging to master as a resampling of the template before the final subject to template registration should be enough for FBA but if you really deem it critical then I can also port to the current master branch.

Member

maxpietsch commented Jul 5, 2017

Anisotropic template resolutions aren't fun or anything we'd like to have in our studies. We saw them recently popping up everywhere. The reason is mraverageheader and the changes made to it, that were (I believe) intended to deal with slice angulations larger than 45 degrees.

mraverageheader has never produced isotropic voxel grids if the input images do not have identical voxel to scanner transformations. However, the changes I made to mraverageheader (which were merged into master with RC1) produce coarser voxel grids than previously which was an unintended side-effect of the changes I made to accommodate large rotations between input images.

For registration, there is always a tradeoff between potential bias, data size and loss of information due to undersampling. Imagine two input images with identical transformations but different voxel sizes. Currently, the average grid uses the average voxel size of the two input images which should be unbiased but loses information of the higher resolved image. Using the highest resolution would bias it towards one image. One could argue that super-resolving both images is sensible, especially for nonlinear registration but this increases the computational, memory and storage cost and might introduce undesired side effects during registration such as being stuck in local minima if the original voxels were very anisotropic.

I'd simply give population_template a voxel size option, and immediately set the grid (e.g. provided my mraverageheader) to that resolution via any means (e.g. just resize it or something). If the user doesn't provide the voxel size option to population_template, I would personally have it be an isotropic resolution that yields an (isotropic) voxel volume that is the same as the average volume of all input voxel sizes.

I agree, I don't think there is a principled way of defining the "best" grid size so we should provide a sensible default and offer the option to change it. Using the average voxel volume and isotropic voxels is not ideal for anisotropic voxels. If you prefer isotropic voxels, I'd suggest using the smallest voxel edge length which is at or above the Nyquist sampling density depending on the relative orientation of the input images.

For the template, it very much depends on the input data's resolution and on the Jacobian of the warp fields what a sensible default is. I don't have much experience with FBA but for analysis in subject-space, I suspect that since we already suggest to upsample the input data, spatial frequency content beyond that of the original data's is unlikely to contribute meaningful information especially as in template space we're likely limited by the anatomical resolution and variability.

But for unbiased registration, and even more so unbiased tractography and CFE afterwards, the best you can go for is an isotropic template resolution, even when the input resolutions are anisotropic...

Can you elaborate on the bias you'd expect to see with anisotropic voxels?

Anyway, I'll add an option to population_template to resize the average space grid to whatever the user wants or deems to be fun. I'd prefer to add those changes to the registration_multi_contrast branch as it is my current work in progress branch which includes many changes to population_template such as multi-tissue template generation. I don't see the urgency of merging to master as a resampling of the template before the final subject to template registration should be enough for FBA but if you really deem it critical then I can also port to the current master branch.

@bjeurissen

This comment has been minimized.

Show comment
Hide comment
@bjeurissen

bjeurissen Aug 18, 2017

Member

I noticed the issue of anisotropic voxels is not limited to mraverageheader and population_template.

E.g. simplymrregister-ing two volumes with identical and isotropic voxel sizes (e.g. 2.40 x 2.40 x 2.40) now generates a --nl_warp_full image with anisotropic voxel sizes (strictly larger than the native voxel sizes, e.g. 2.49 x 2.64 x 2.66), where it used to produce isotropic voxel sizes at the original image resolution.

So I am not sure that fixing population_template completely addresses the issue.

Member

bjeurissen commented Aug 18, 2017

I noticed the issue of anisotropic voxels is not limited to mraverageheader and population_template.

E.g. simplymrregister-ing two volumes with identical and isotropic voxel sizes (e.g. 2.40 x 2.40 x 2.40) now generates a --nl_warp_full image with anisotropic voxel sizes (strictly larger than the native voxel sizes, e.g. 2.49 x 2.64 x 2.66), where it used to produce isotropic voxel sizes at the original image resolution.

So I am not sure that fixing population_template completely addresses the issue.

@maxpietsch

This comment has been minimized.

Show comment
Hide comment
@maxpietsch

maxpietsch Aug 21, 2017

Member

Internally 'mrregister' uses an average space grid with voxel sizes that depend on the original input voxel sizes and the two voxel to scanner transformations. This is done to avoid bias towards any one input image as I've written above.

The voxel size is larger than the input voxel size as the spatial resolution decreases with the rotation of the average space away from the original voxel grid. This, of course, is only a valid argument for linear registration as the resolution also depends on the warp field itself for nonlinear registration.

I think it is sensible to default to write the warp field as it was used for registration as mrtransform allows to regrid to any template image if so desired. Nonetheless, we could add an option to set the warp voxel spacing to a user-defined value similarly to population_template. I am not sure how though. Simply resizing the average space voxel grid after linear registration might bias the nonlinear registration initially if the input images have different resolutions but similar header transformations. Resizing after registration causes additional interpolation of the warp field which then might be interpolated again if it is used to transform not to the mid-space. Suggestions?

Member

maxpietsch commented Aug 21, 2017

Internally 'mrregister' uses an average space grid with voxel sizes that depend on the original input voxel sizes and the two voxel to scanner transformations. This is done to avoid bias towards any one input image as I've written above.

The voxel size is larger than the input voxel size as the spatial resolution decreases with the rotation of the average space away from the original voxel grid. This, of course, is only a valid argument for linear registration as the resolution also depends on the warp field itself for nonlinear registration.

I think it is sensible to default to write the warp field as it was used for registration as mrtransform allows to regrid to any template image if so desired. Nonetheless, we could add an option to set the warp voxel spacing to a user-defined value similarly to population_template. I am not sure how though. Simply resizing the average space voxel grid after linear registration might bias the nonlinear registration initially if the input images have different resolutions but similar header transformations. Resizing after registration causes additional interpolation of the warp field which then might be interpolated again if it is used to transform not to the mid-space. Suggestions?

@Lestropie

This comment has been minimized.

Show comment
Hide comment
@Lestropie

Lestropie May 11, 2018

Member

Closed by #1052

Member

Lestropie commented May 11, 2018

Closed by #1052

@Lestropie Lestropie closed this May 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment