At the bottom of the "autopano-sift-c memory leaks" thread I said:
> Just to push the envelope a little, could we possibly make Hugin > compute hfov from the actual lens focal length and the camera's sensor > dimensions or focal plane resolution, when those are known? This > would work best of course if we had a good lens and camera data base, > something that could greatly enhance Hugin's mass appeal. > However focal plane resolution data are present in the EXIF from some > (though not all) cameras nowadays, and when present should be taken > advantage of. The EXIF standard states that these parameters are to > be used, with f.l., to compute angular field of view. On further consideration, what about ending our dependence on "hfov" altogether? I suspect Dersch chose this way of specifying the angular resolution because it is fairly easy to guess, and because back in the early '90s it was not easy to find out the sensor size or pixel density of the average digital camera. But hfov depends on both angular resolution and the lens projection function, so there are two ways to get it wrong. Whereas focal length is a pure magnification factor, equivalent to angular resolution at image center and independent of the projection function -- that is what makes it a useful number for characterizing lenses of all types. The only problem is that we need the focal length in pixels, but the lens is marked in mm. So we need another piece of information: the focal plane pixel density in pixels/mm. That number is often given in the EXIF file (typically in pixels/ inch); or it can be computed from image dimensions (pixels) and sensor dimensions (mm); or from image dimensions, field of view, and an assumed projection function, as Hugin does now. That last choice is the worst, because it makes f.l. depend on a possibly poorly known, empirically calibrated projection function. Moreover the fact that "hfov" changes with image orientation causes a lot of confusion, both for users and programmers. So how about we do ourselves a favor: declare "focal length in pixels" to be a primary image parameter; compute that from whatever information is available when setting up a project, and put it in the .pto file? This wouldn't require anyone to give up hfov, but would open the way for doing things better. I don't think it would be hard to implement this enhancement in libpano, where the f.l. in pixels is already used throughout, under the name "distance parameter". About Hugin I can't say. 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
