PS To better appreciate the confusion and frustration surrounding the present use of hfov, have a look at thread "landscape and portrait images can't share a lens" http://groups.google.com/group/hugin-ptx/browse_thread/thread/28a5045378339593/0064ce17755c1fda#0064ce17755c1fda
On Jul 18, 11:13 am, Tom Sharpless <[email protected]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
