-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loop homography rejects large numbers of valid pairs #12
Comments
The spread of control the points is also odd. |
Issue of bands of control points noted above appears to be in the decimation algorithm. To de-aggregate the control points, the resulting control points are divided into N x N pixel zones. The default is 100 x 100, but can be user specified. The "best" control points are selected from each zone. To ensure the desired spread of the resulting control points over the overlap area, a pseudo random deterministic pattern is used to randomize the zone order when building the final list of surviving control points. It appears as if this process is favoring a particular horizontal or vertical zone index. This results in a narrow stripe of control points. Fewer zones means more control points are selected from those zones used, encouraging the small scale clumping. |
Adjusting the hash to be a repeatable permutation based on std::shuffle and std::mt19937 resolved the control point banding issue. This did not resolve the --loopfilter issue. |
What is happening is that an image is being paired with multiple essentially identical images owing to the pattern being approximately the same size as the tiles. Here is an example of the pairing of one image to its next row neighbors: In this instance loop homography fails to resolve conflicting overlap. The correct pair is 4-->24. The current algorithm is not capable of reliably identifying the correct one. If the tiles have perfect horizontal and vertical alignment, as from a robotic stage, using --rowsizetolerance 0 would eliminate pairs 4-->23 and 4-->25 which would "solve" the problem. For example, in the series c test tiles, loop 4-->5-->25-->24-->4 would be valid. as would many of of the ilk N-->N+1-->N+21-->N+20-->N. It may be that these loop options are not being checked. |
The 4-->5-->25-->24-->4 loop shows an error of 1000+, but each pair appears to be properly aligned individually. Its not obvious as to what is causing the huge error with the transitive error calculation. Added trace level output so the homography matrix and the test point can be followed. |
The loop homography reports an invalid pair because a sub loop reports an error.
|
( "Error" reported in debug output was computed as an average, there were inconsistencies in the way the debug output reported this info between various versions of sibling functions. Correcting some of that. ) |
Take loop R1C1 --> R1C2 --> R2C2 --> R2C1 --> R1C1 with overlapping edges. The overall loop is low error. However sub loops, such as R1C1 --> R1C2 --> R2C2 --> R1C1 would include a pair ( e.g. R2C2 --> R1C1 ) overlapped via a corner. It appears in the series c and series d test tile sets the corners are misaligned. The subloop check requires all sub-loops be consistent as well. This specifically to catch these sorts of situations. This requirement may be too strict. The takaway is that the loop homography code is working, its just algorithmically not doing what we want in this case. Next steps would be determining why the corner overlaps are bad, confirming that --rowsizetolderance 0 which would eliminate corner overlaps "fixes" the issue. |
The current algorithm cannot distinguish between what appear to be well aligned images. Essentially there are three equally good pairs for this particular test case. Using --rowsizetolerance 0 does in fact eliminate the spurious pairs. This made visible several other secondary issues with this tile set. Namely that the these blurry images push the limits of Akaze. |
Project with 20 x 20, lrtb pattern, 30% overlap, 1:1 aspect ratio tiles. AKAZE and ORB identify many valid pairs, about 70% of valid pairs are rejected by loop homograph.
On inspecting logs it is seen that none of the loops are valid and the pair is voted as bad.
INFO: Pair ( 5, 6 ) Loop = {4,5,6,25,4} Error = 1006.49 INFO: Pair ( 5, 6 ) Loop = {5,25,6,5} Error = 1009.01 INFO: Pair ( 5, 6 ) Loop = {26,5,6,27,26} Error = 1009.18 INFO: Pair ( 5, 6 ) Loop = {5,26,6,5} Error = 1009.6 INFO: Pair ( 5, 6 ) Loop = {5,26,27,6,5} Error = 1010.43 INFO: Pair ( 5, 6 ) Loop = {25,4,5,6,25} Error = 1011.01 INFO: Pair ( 5, 6 ) Loop = {25,5,6,26,25} Error = 1013.64 INFO: Pair ( 5, 6 ) Loop = {5,25,26,6,5} Error = 1014.07 INFO: Pair ( 5, 6 ) Loop = {24,5,6,25,24} Error = 1742.9 INFO: Pair ( 5, 6 ) Loop = {6,25,26,5,6} Error = 2022.4 INFO: Pair ( 5, 6 ) Loop = {26,5,6,25,26} Error = 2027.1 INFO: Pair ( 5, 6 ) Loop = {26,5,6,7,26} Error = 2039.51 INFO: Pair ( 5, 6 ) Loop = {5,6,7,26,5} Error = 2039.51 INFO: Pair ( 5, 6 ) Loop = {5,24,25,6,5} Error = 2467.58
INFO: Pair ( 5, 6 ) Votes: Bad = 1 L2 = 0 L1 = 0 L0 = 0 Status: PAIR BAD
This seems related:
INFO: Pair ( 24, 25 ) Loop = {24,4,5,25,24} Error = 2407.03
However all of the individual pairs seem valid:
The text was updated successfully, but these errors were encountered: