I have talked about this problem associated with APP 2.5 B2 before but problem still exist in APP 2.5 RC1. The problem is simple, the APP 2.5 engine always detects panoramas with a higher RMS than the APP 2.0.9 engine does. That means (and also proved by my own eyes) APP 2.0.9 is positioning the images better than APP 2.5 can. Does anyone have the same problem? Try the same set of images on both engines and you will understand what I mean. Maybe the final anti-ghost rendering can help the problem but isn't it better to start off editing with a panorama well detected?
Settings are default: -Detection quality: Standard -Control Points: 50 Panorama Editor: -Interpolation: Bilinear -Blending: Linear
This really depends a lot on the internal parameters we setup in autopano. The RMS is not the absolute measure for quality of stitch. You need also to visually analyse the overlapping zone to be sure that the 2.0.9 version is doing better/worth than the 2.5 serie. - First test that can be done, open a panorama with cp generated from 2.0.9 and optimize it in 2.5 : it should not change a lot but be a little better ( meaning, the optimizer in 2.5 serie is better than the 2.0.9 version ). - Second test, detect the panorama with 2.0.9 and with 2.5 and compare visually the cp generated. As this has been tuned a little, it will change a little.
Globally, what I found out comparing 2.0 and 2.5 serie, the visual quality has improved even in presence of false CP ( sometimes, we got false CPs ). You can see that in gigapan mode, even if you can have a lot of red links ( with only 1 CP ), it doesn't change a lot the visual quality of stitching. That's because the way we optimize the panorama is robust to isolated wrong CP. Now, in the present of a serie of wrong CP ( for example a moving car that has been detected instead of the background ), it will generate stress in the grid of link and will result is a massive presence of red along this link but also all links around that one. It's a question of power : 1 wrong link doesn't count for much compared to the 100 good one around, but 50 wrong CPs will.
Anyway. So RMS is a good indicator of the quality, but not the ultimate one ( comparing 2.54 versus 2.34 won't really make sense, if something else has changed, for example the number of CP used ). In the case you are having, I guess the real explanation and answer will come from an analysis of your case ( if you can share it here ).
1st test: Honestly, it is very easy to see the optimization in 2.5 is less good than 2.0.9. 2nd test: What you said is true, 2.5 is doing better cp's, for example, no cp's for clouds and the sky.
So I would say instead of a problem with cp detection, it is the problem of the optimizer.
The optimizer problem may be associated with a strange phenomenon I found. After I detected the panorama, I saved and closed it. When I opened it again, the RMS changed (as well as the overlapping). Doing no editing, I saved, closed and opened it again, the RMS changed again. So, I decided to do a test, from the first detection, I repeated the "1.save 2.close 3.open" process for 15~20 times. The RMS I got ranged from 2.44 to over 8. I also checked the cp's, they did not change at all, just the optimization. When the RMS was 2.44, the panorama was well-stitched but when the RMS is 8, it was really bad. I did the same thing in 2.0.9, no such change was found.
In order to help you understand better my problem, I emailed the set of images I was testing to you (because they are too large to be put here).
Last edited by atelescope on Thu Dec 16, 2010 6:39 am, edited 1 time in total.