Discuss: RegistrationParameterScalesFromPhysicalShift Usage -- Potential Physical Scale Dependence

[gdevenyi]

During discussion regarding optimizers in SimpleITK, I came upon the the RegistrationParameterScalesFrom* setting

https://discourse.itk.org/t/tuning-optimizer-s-for-almost-aligned-images/7676/13

I was having a tough time with the optimizer until I switched from RegistrationParameterScalesFromPhysicalShift to RegistrationParameterScalesFromIndexShift because it appears that step sizes for parameters are being derived from "real world" coordinates, in this case millimetres, which in high resolution/small animal data is inappropriate.

A review of the optimizer settings in ANTs indicates that RegistrationParameterScalesFromPhysicalShift appears to be the default.

I think the ANTs authors probably have a much deeper understanding of the underlying framework here, but should we consider changing this parameter?

[stnava]

We implemented both because they are both useful. I don’t think we can say ahead of time, which is the best for all scenarios. I suppose we could add a command line Parameter that would allow the user to select this index based approach as an option brian

…

On Tue, Dec 16, 2025 at 10:07 AM Gabriel A. Devenyi < ***@***.***> wrote: *gdevenyi* created an issue (ANTsX/ANTs#1931) <#1931> During discussion regarding optimizers in SimpleITK, I came upon the the RegistrationParameterScalesFrom* setting https://discourse.itk.org/t/tuning-optimizer-s-for-almost-aligned-images/7676/13 I was having a tough time with the optimizer until I switched from RegistrationParameterScalesFromPhysicalShift to RegistrationParameterScalesFromIndexShift because it appears that step sizes for parameters are being derived from "real world" coordinates, in this case millimeters, which in high resolution/small animal data is inappropriate. A review of the optimizer settings in ANTs indicates that RegistrationParameterScalesFromPhysicalShift appears to be the default. I think the ANTs authors probably have a much deeper understanding of the underlying framework here, but should we consider changing this parameter? — Reply to this email directly, view it on GitHub <#1931>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACPE7XTSTBXFMIWGRGZKTL4CAG2HAVCNFSM6AAAAACPGKHJASVHI2DSMVQWIX3LMV43ASLTON2WKOZTG4ZTIOJUGE3TCOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cookpa]

If I understand correctly, the purpose of the scales estimators is to provide a mapping between delta(parameter) and the index or physical "shift" of the transform. Does scaling the gradientStep achieve a similar result?

[cookpa]

That said, it is perhaps confusing that the gradientStep / scales estimator works on a physical shift for everything but SyN, which uses voxel units

[gdevenyi]

I think the relevant description of the role this parameter plays is here:
https://github.com/InsightSoftwareConsortium/ITK/blob/0e473cad0293a838ee9769011dae72ac42d3128b/Modules/Numerics/Optimizersv4/include/itkGradientDescentOptimizerv4.h#L42-L73

[cookpa]

By my reading of this, the learning rate is estimated via line search but is limited to the maximum step size in physical units. So Rigid[0.1] on a mouse brain might be more like Rigid[1] on humans.

What I'm struggling to understand is how the scales estimators are not working in physical space. The shifts used in the estimators should be small deltas, which are then normalized to get the actual scale.

It looks to me that the optimizer always interprets the scales in physical units:

this->m_LearningRate = this->m_MaximumStepSizeInPhysicalUnits / stepScale;

https://github.com/InsightSoftwareConsortium/ITK/blob/444c76169741bfcdb5eee294a20a71c5aae097f3/Modules/Numerics/Optimizersv4/include/itkRegularStepGradientDescentOptimizerv4.hxx#L233C1-L269C2

If the voxels are small then it follows that the physical stepScale (mm / parameter) will be much smaller than the voxel stepScale (voxels / parameter) for the same gradient. So the switch would explain why the learning rate doesn't blow up after you switch to index shift. But I don't understand why the physical calculation is bad.