Hello, On 29 July, 18:20, Thomas Sharpless <[email protected]> wrote: > I hope you don't mind that I have forwarded this reply also to hugin-ptx.
Perfectly fine by me. A few annotations before I leave for one week of holidays... First I tried a mapping function, for simplicity r=tan(theta), theta range 0-45 degrees, using a polynomial approximation. Approximation with linear, cubic, quintic and heptic terms: Standard deviation = 1.38953481E-05 Approximation with linear, quadratic, cubic and quartic terms: Standard deviation = 2.12137268E-04 Approximation with linear, cubic, and quintic terms: Standard deviation = 1.89170188E-04 Approximation with linear, and cubic terms: Standard deviation = 2.54516649E-03 So with three odd terms one reaches about the same quality as with four terms like in the panotools model, and four odd terms is one order of magnitude better. So for your lense model, if you want to use a unified approach, I would suggest you use an ansatz like x=i*(c1+i*i*(c3+i*i*(c5+i*i*c7))) > But even with a rectilinear lens, the control point positions in a typical > panorama alignment simply do not provide enough information about the radial > error to fit a 3-term polynomial to it. So the optimizer is guaranteed to > find a different set of a,b,c values given different sets of CPs. They > characterise the particular arrangement of control points as much as they do > the lens. I disagree. There _is_ enough information in the control points, but the model (in our case the panotools model) is too tight and hence the positioning of the CPs matters. Currently optimising all for two images needs 3 degrees of freedom for relative alignment, 4 dofs for radial mapping, and maybe 2 dofs for lense axis. Each normal CP is worth 2 dofs, so with 5 CPs you are already in the game, any further CPs just improve your quality. > Which is why I think the way to improve lens correction in panorama > stitching is first of all to use adequate calibration procedures to > deterimine the actual characteristics of our lenses, and use calibrated lens > correction parameters for all stitching. Nothing wrong with lense calibration, but my impression in using customer-grade cameras is that your lense moves in and then out again, and your calibration has changed. Hence if I have the opportunity to have two partial overlapping photos, and you have these when shooting a panorama, I prefer to derive the lense parameters from the actual stitching material. > They could even control "fudge functions" that are better than the radial > polynomial for fixing the real misalignment problems. Depending on camera, zoom, not to forget lense repair I find I need more than the radial polynomial. In hugin there are the e,f parameters available, and using them improves alignment indeed, at least with my camera lenses. > We hope to develop an automated calibration based on analyzing the curvature > of lines in the image that are in reality straight. This is a valid goal if you only have one photo available. > Certainly it will not be able to determine the quintic correction you > mention, or shear corrections, or transverse chromatic aberration. My assessment is that there is enough information in partial overlapping image pairs. > But if it delivers a reliable correction of radial error to +/- 0.5 pixel, I > will > consider it a success, and would expect it to help real photographers make > better panos. With images from my Canon A610 I am already in that range, and I find that the smallest errors are somewhere half way between wide angle and tele for the zoom lense. My educated guess is that the quintic (and maybe higher orders) are minimal there, possible changing sign there. Of course one needs a benign situation, no parallax error etc. > I expect calibrate_lens to finally deliver a lens model having 3 or 4 fitted > parameters, most likely depending on a nominal lens type selected by the > user. Probably only two of those parameters will be coefficients of a > radius polynomial. We will try a lot of models, though, and use whatever > seems to give the most consistent results. Sure. Best to try to see what real life lenses are like. Maybe you can even run some kind of competition with photo pairs 50% overlap, and use the Finetune from hugin to get a good set of CPs which you then read from the pto file into your software. All the best with your project, and read you after the holidays Klaus P.S. x=2*sin(theta/2) is even more benign 4xodd: Standard deviation = 3.2292812E-12 3xodd: Standard deviation = 5.89860021E-09 2xodd: Standard deviation = 6.205268E-06 4xmixed: Standard deviation = 2.32420554E-07 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
