Hey Pablo

Happy New Year!

Can you explain anything about how hugin is meant to negotiate FOV  with libpano?  The general Panini is unusual in that its max hFOV varies with the eye distance parameter, and I see some odd behavior under the hugin preview windows.   In particular the vFOV jumps down at each update.

g.P. also depends on converting the equirectangular source image to absolute angles in radians -- linearly proportional is not enough -- which I'm not sure is happening yet.  That would mean a distanceparam (or a stand-in for it) that is independent of the hFOV setting.   I'm confident I can work around any such problem inside libpano; but do you know if hugin takes any interest in distanceparam?

I wonder why there are not separate source and dest distanceparams in PT?

Best, Tom

On Tue, Jan 5, 2010 at 3:43 PM, Pablo d'Angelo <pablo.dangelo@web.de> wrote:
Thomas Sharpless wrote:

> Still wrestling with the inverse general panini code and the math on
> which it is based.  But should have it working soon.  Using PTmender for
> most tests, as you suggested.

I have just added a pano_trafo utility program to hugin, which is
probably also useful for testing the coordinate transforms. This will
let you make some test case coordinate files and transform them easily.

I tried to add it to libpano13, but the parser of libpano13 was not
suitable for that, and I didn't want to duplicate the very strange
things that PTmender does when parsing a script file.


This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
PanoTools-devel mailing list