MATLAB Answers

Brian
1

rotation constraint in imregtform

Asked by Brian
on 20 Aug 2019
Latest activity Edited by Matt J
on 20 Aug 2019
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!

  0 Comments

Sign in to comment.

1 Answer

Answer by Matt J
on 20 Aug 2019
Edited by Matt J
on 20 Aug 2019

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.

  2 Comments

Brian
on 20 Aug 2019
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
on 20 Aug 2019
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)

Sign in to comment.