PPS
On Jul 20, 10:24 pm, Tom Sharpless wrote:
> PS I was wrong about that last. PTAsm lets you choose between the
> equal-angle and equal area fisheye models, which is the right thing to
> do.
>
However it computes fov wrong for the equal area fisheye, so it's not
useful.
> -- Tom
>
> On Jul
PS I was wrong about that last. PTAsm lets you choose between the
equal-angle and equal area fisheye models, which is the right thing to
do.
-- Tom
On Jul 20, 4:08 pm, Tom Sharpless wrote:
> Hi
>
> All of this indecision about which image axis to link to "fov" is
> unnecessary and misleading,
Hi
All of this indecision about which image axis to link to "fov" is
unnecessary and misleading, because fov is properly a secondary
quantity, derived from the following primaries: focal length (in
pixels); image width (ditto); lens projection function (angle vs.
radius).
A sensible image proce
On Mon 20-Jul-2009 at 07:53 -0700, Bart van Andel wrote:
>
>Maybe FOV should be treated differently based on the lens type. This
>does make sense, as for circular fisheye the given (or guessed) fov of
>the lens is only the fov of the circle, not of the full frame.
This is how ptgui does it.
Hugi
Maybe FOV should be treated differently based on the lens type. This
does make sense, as for circular fisheye the given (or guessed) fov of
the lens is only the fov of the circle, not of the full frame. The
image loading screen could be adapted to show a small helpful picture
to denote how the fov
Klaus Foehl wrote:
> On 18 July, 17:13, Tom Sharpless wrote:
>
>> On further consideration, what about ending our dependence on
>> "hfov" altogether?
>>
>
> Firstly I would suggest to use something like dfov, diagonal fov which
> would be independent of portrait or landscape photo orienta
Perhaps the easiest (to understand) solution, at least for the
landscape vs portrait mode problem, is to take max(HFOV, VFOV), in
other words, the FOV of the greatest dimension. This is pretty easy to
guess from a user perspective in case of missing EXIF information.
I've thought about a DFOV as w
Hello Tom et al.,
On 18 July, 17:13, Tom Sharpless wrote:
> On further consideration, what about ending our dependence on
> "hfov" altogether?
Firstly I would suggest to use something like dfov, diagonal fov which
would be independent of portrait or landscape photo orientation. But
of course o
On Sun 19-Jul-2009 at 00:38 +0200, J. Schneider wrote:
>
>By the way: Do they carry any information (in metadata) about the
>projection and field of view when they are finished? To be used when
>either taken as input again or by the user for any other purpose.
Not with nona/hugin currently, the P
Hi Bruno
On Jul 18, 2:05 pm, Bruno Postle wrote:
> Yes focal length is independent of image orientation, but it is
> meaningless to anyone who hasn't learnt the 'craft' of photography.
>
> The different sensor-size thing combined with 'equivalent' focal
> length numbers is a real mess - At le
> Plus there are also whole classes of images that you might use as
> input for hugin where 'focal length' has no physical meaning:
>
> - perspective drawings and paintings
> - 3d computer renderings
> - any output image created by hugin
By the way: Do they carry any information (in metadata) ab
On Sat 18-Jul-2009 at 08:13 -0700, Tom Sharpless wrote:
>
>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
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
13 matches
Mail list logo
