In my development branch (feature/deformable-surfaces), I just fixed a bug in irtkGenericRegistrationFilter::GuessParameter which uses the input resolution of the images instead of the resolution of the target at the final level. Usually these are identical, but when a user specified final level resolution, e.g., because of very high slice thickness to use more or less isotropic resolution, this can result in two large gradient steps still based on the high slice thickness which can produce very bad rigid/affine registration results because the first step leaves the images with almost no overlap.
In my development branch (feature/deformable-surfaces), I just fixed a bug in
irtkGenericRegistrationFilter::GuessParameterwhich uses the input resolution of the images instead of the resolution of the target at the final level. Usually these are identical, but when a user specified final level resolution, e.g., because of very high slice thickness to use more or less isotropic resolution, this can result in two large gradient steps still based on the high slice thickness which can produce very bad rigid/affine registration results because the first step leaves the images with almost no overlap.