0

I am trying to write an algorithm that rotates one square around its centre in 2D until it matches or is "close enough" to the rotated square which started in the same position, is the same size and has the same centre. Which is fairly easy.

However the corners of the square need to match up, thus to get a match the top right corner of the square to rotate must be close enough to what was originally the top right corner of the rotated square.

I am trying to make this as efficient as possible, so if the closeness of the two squares based on the above criteria gets worse I know I need to try and rotate back in the opposite direction.

I have already written the methods to rotate the squares, and test how close they are to one another

My main problem is how should I change the amount to rotate on each iteration based on how close I get

E.g. If the current measurement is closer than the previous, halve the angle and go in the same direction otherwise double the angle and rotate in the opposite direction?

However I don't think this is quite a poor solution in terms of efficiency.

Any ideas would be much appreciated.

John Traynor
  • 13
  • 3
  • What is your data? How is it stored/represented? – Steve Tjoa Nov 21 '10 at 13:48
  • Why don't you just calculate the angles at which the rotated square has its sides? This is trivial trigonometry in O(1). – liori Nov 21 '10 at 13:51
  • Its just stored as four co-ordinates, and I am not calculating the angles because it is a much larger problem than what has been described in which approximation is the best method. – John Traynor Nov 21 '10 at 13:59
  • So approximate it, but you know what angle you want to end up at, so just run the angular difference to zero by any method you like - linear, second-order, exponential decay, whatever. – Mike Dunlavey Nov 21 '10 at 20:27

3 Answers3

0

How about this scheme:

Rotate in 0, 90, 180, 270 angle (note that there are efficient algorithm for these special rotations than the generic rotation); compare each of them to find the quadrant you need to be searching for. In other word, try to find the two axis with the highest match.

Then do a binary search, for example when you determined that your rotated square is in the 90-180 quadrant, then partition the search area into two octants: 90-135 and 135-180. Rotate by 90+45/2 and 180-45/2 and compare. If the 90+45/2 rotation have higher match value than the 180-45/2, then continue searching in the 90-135 octant, otherwise continue searching in the 135-180 octant. Lather, Rinse, Repeat.

Each time in the recursion, you do this:

  1. partition the search space into two orthants (if the search space is from A to B, then the first orthant is A + (A + B) / 2 and the second orthant is B - (A + B) / 2)
  2. check the left orthant: rotate by A + (A + B) / 4. Compare.
  3. check the right orthant: rotate by B - (A + B) / 4. Compare.
  4. Adjust the search space, either to left orthant or the right orthant based on whether the left or right one is have higher match value.
Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
0

Another scheme I can think of is, instead of trying to rotate and search, you try to locate the "corners" of the rotated image.

If your image does not contain any transparencies, then there are four points located at sqrt(width^2+height^2) away from the center, whose color are exactly the same as the corners of the unrotated image. This will limit the number of rotations you will need to search in.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
0

...also, to build upon the other suggestions here, remember that for any rectangle you rotate around its center, you only need to calculate the rotation of a single corner. You can infer the other three corners by adding or substracting the same offset that you calculated to get the first corner. This should speed up your calculations a bit (assuming [but not thinking] that this is a bottleneck here).

Pedery
  • 3,632
  • 1
  • 27
  • 39