rotation constraint in imregtform

Is there a method to apply more explicit (e.g. not rigid/similarity/etc) constraints on the optimization in imregtform?

I have a video with periodic features that is rotating and translating. The use of 'rigid' in imregtform typically works when registering between frames. Occassionally, however, the optimized tform "skips" to the next set of features and rotates the registration by ~10 degrees. This causes errors for registerting subsequent (downstream) frames. Is there a way to limit the bounds on the optimization space? I can limit the search radius growth and number of iterations to control the final search radius, but end up severely restricting the number of iterations that can be performed.

Would one of the other image registration pipelines work better for this application? Image registration approaches shows intensity-based as the only one that supports both nonrigid (important for another part of the workflow) transforms and fully automatic (there are a lot of videos!) workflow. If another framework may work better, I'm definitely willing to try it.

Thanks in advance for your help!

Answer 1

[Matt J]

I don't have a clear picture of the "skips" you are refering to, but it vaguely sounds like it could be addressed by setting the InitialTransformation parameter more judiciously. Since you say the the rotations/translations are periodic, you should have a pretty good idea where the search should start in any given frame.

But to answer your question, no, imregtform unfortunately offers very little control over the optimization.

[Brian]

Thanks Matt! It sounds like something custom may be in order unfortunately.

I can set the InitialTransform [very] accurately, as this is high-speed video and there is typically only a few pixels of XY translation and less than a degree of rotation between frames. More or less - reuse of the transformation from the previous set of frames with some prediction. This is working very well 'most' of the time.

As for the skips, it's effectively a polar grid moving relative to the camera. Since the grid is identical when rotated ten degrees, the optimization converges on a transformation with a rotation of eleven or twenty-one degrees when it should have only rotated one degree.

Thanks again!

[Matt J]

Okay, well why don't you extract the rotation angle, theta, from the registered tform and do a modulo-10 normalization:

theta = mod(theta,10)