On Jan 6, 11:07 am, Jeffrey Martin <[email protected]> wrote: > Right. If anything, Diagonal FOV should be used. But it's not. So on that > note, let's scrap it all and do it the right way :-)
'Doing it the right way' is not so easy in practice, because it has to be based on reliable lens calibration data. From the user's point of view the whole problem is how to make it convenient to get and use such data. First, you need to know the lens's focal length in pixels, which is determined by its physical focal length and the physical size of a pixel. When dealing with high quality equipment, it is probably safe to accept the manufacturer's specifications for pixel size and focal length; but reliable figures are not available for many cameras and lenses. Then, you need to know the radial projection function of the lens. There are no manufacturer's specs for that; and measuring it physically is very demanding work. The best we can do in most cases is to use our stitchers to estimate the curve, based on aligning a 360 degree panorama with lots of overlap. That is really not so hard: I recently calibrated 4 fisheye lenses that way, at 7 different focal lengths, in about half a day's work (but I had been using those lenses for between 3 months and 3 years, before I finally got around to calibrating them! ) Since I used a PT- based stitcher, the results are polynomial coefficients describing the deviation of the lenses' curves from the function r = f * theta, where f is focal length, r and f are in pixels, and theta is in radians. Or would be, except that the PT polynomial has been tweaked to hold the r value corresponding to half the smaller image dimension constant. It is straightforward to calculate the coefficients of the preferable polynomial, that has constant unit slope at image center (and so does not alter the apparent focal length). To do that you need the factor by which PT multiplied the 'ideal radius' input to the polynomial -- which unfortunately it neither prints nor saves. The tweak is the result of "FOV-think": PT effectively optimizes the angle of view corresponding to the fixed radius, rather than the focal length. It is easier to use FOV this way, as if it were a primary lens parameter, than to compute it from first principles. And very tempting to do so, because if it starts from a plausible FOV, the optimizer can get a good alignment without knowing the pixel size or lens FL. However, on the basis of a good deal of experience of writing as well as using lens correction software, I can assure you that this approach is not sound, and leads to many difficulties. The new (free) Adobe Lens Profile Creator tool offers an alternative calibration method based on better principles. Its profiles are very nearly independent of the camera on which the lens is calibrated, and work fine when the same lens is used on other cameras. It is more difficult to do than the stitcher-based method, but gives better corrections, including TCA and vignetting. Moreover, there are already a lot of ready made profiles available, and more coming. At present the profiles are in XML, so one could use them outside Adobe Camera Raw. I expect Adobe will obfuscate them eventually, so now is probably a good time to collect them. By Spring I hope to release a new ''Panini" lens correction tool that tries to deal with some of these problems. Regards, Tom -- 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
