Max Lyons Forums

[TKSharpless]

Hi Max,

While revising autopano-sift-c to work with PTAssembler project files, I noticed (for the first time) that PTAsm lets you specify whether a fisheye lens is of the equal-angle or equal-area (equisolid-angle) type. Neither Hugin nor PTGui does that.

However I was disappointed to see that PTAsm computes the hfov wrong for the equisolid case -- the reported fov corresponds to the 35mm equivalent f.l. instead of the actual one. And this bad hfov value goes into the project file.

I would also like to suggest to you, as I am to everyone who develops PT family software, that we stop using hfov to specify angular resolution, and store primary data (lens focal length plus either crop factor or focal plane pixel spacing) in our project files
(or even better, store the focal length in pixels, which is the quantity all angle calculations depend on).

Because hfov also depends on an image dimension and the lens projection function, both of which are inadequately specified in the PT script scheme, it can be hard to get the right focal length in pixels when you need it; and all sorts of confusion and trouble arise, both for users and programmers. Sticking to independent primary data, and computing secondary quantities like hfov from those as and when needed, would go a long way toward clearing that up.

Working with Hugin, PTAsm and PTGui project files side by side has only confirmed my conviction that something needs to be done about this, and soon. It is unbelievable how many kluges and unsafe assumptions one must make when passing "hfov" around a tool chain.

For example: if the EXIF specifies an image orientation, PTGui not only displays it that way, but also records its dimensions that way in the project file, along with the corresponding hfov. So then to figure the "real hfov" one has to compare the dimensions recorded in the project to the ones in the image file, and make an adjustment if they disagree.

For example: many a user of Hugin has had the bad experience of having image alignment go all to pieces when he crops an image, for that changes the calculated hfov -- though not, of course, the angular resolution of the image.

For example: PTGui assumes all fisheyes are equal-area, and calculates hfov on that basis; Hugin assumes they are equal-angle, and uses that formula to compute hfov. So if you put Hugin's hfov into PTGui, or vice versa, each will display an incorrect lens focal length (and both will use wrong image angles).

I could go on for many pages. The bottom line is I'm fed up with flaky kluges and yearning for some simplicity and order. What do you say?

Best Regards, Tom

[Bart]

[maxlyons]