Why does transformation matrix compute varying results?

Hi there,

I am interested in computing the transformation matrix of a series of images using Matlab's estimateGeometricTransform().

I am using a set of 2D images where a dot is almost centered on a blank canvas. With each increment of my scene image, I compare the matched ORB features of my reference and respective Scene image. I have attached my reference and sample test images.

From Scene 1 to Scene 5 image, you can see the dot gradually moves up in the y-axis. So I anticipated to see my translation vector along the y-axis to increase while the other variable in the transformation matrix remain the same. However that is not the case. I have attached my transformation matrices when I compared each Scene image with the Reference image.

Although the dot moves forward in only y-axis, all variables in the computed transformation matrix are changing without a consistent pattern. What could be causing unstable output of the results?

[Helia Sh]

On the Matlab tutorial (https://de.mathworks.com/help/vision/examples/find-image-rotation-and-scale-using-automated-feature-matching.html) for estimating the transformation matrix, it says "you may see varying results of the transformation computation because of the random sampling employed by the MSAC algorithm". Does it explain the anomally that I'm seeing in the tform results?

Although the dot moves forward (in only y-axis) in each incremental frame, all variables in the computed transformation matrix are changing without a consistent pattern.

[KALYAN ACHARJYA]

Be Specific quaestion please? Read here

[Helia Sh]

@KALYAN ACHARJYA thank you for your suggestion. I have updated my query. Please let me know if you require additional information.

Answer 1

[Matt J]

What could be causing unstable output of the results?

Probably because there are infinite solutions. For example, any initial rotation of the circular black dot, followed by a y-translation, results in the same image and therefore would be a valid solution.

[Helia Sh]

@ Matt J why should the system detect any rotation?

[Matt J]

Because your dot is rotationally symetric. The algorithm therefore faces an ambiguity when deciding if and how much the dot should be rotated.

[Helia Sh]

Fair enough. Please let me know if you have any shapes to recommend or techniques to implement that could give me a more stable transformation matrix.

The position of the dot was changing at an even distance across the frames. It is still not clear why the translation vectors of the transformation matrix are changing so dramatically (sometimes detecting shifts in a factor of 10) and oscillating between positive and negative.

showMatchedFeatures() displays a more realistic tracking of the features. I have attached these results.

Thanks!

[Matt J]

It is still not clear why the translation vectors of the transformation matrix are changing so dramatically (sometimes detecting shifts in a factor of 10)

But you've seen for yourself that the transformation matrices that you are getting do bring the dot successfully to the desired location, just as a direct translation along the y-axis would. That should make it very clear that there are many possible transformations that work. If we agree that there are multiple solutions for every position of the dot, then why do you expect to see a particular pattern in the solutions chosen by the code?

and oscillating between positive and negative

Because, for example, instead of translating forward in the y-direction by +10, I could equivalently translate by -10 and then perform a rotation of 180 degrees about the starting location of the dot. Both of these transformations would bring the dot to the same spot.

Alternatively, I could translate in the direction 10*[-1,-1]/sqrt(2) and then rotate 135 degrees to reach the same spot. There are infinite possible translation/rotation combinations that would work with many possibilities for the signs of the numbers.