In general, it probably is best to calibrate your specific lens in Hugin,
particularly if it's one you use a lot for panorama work.
Of course, getting your clients to do that may be another matter entirely.
On April 2, 2020 12:20:41 AM HST, Klaus Foehl wrote:
>You need not be so pessimistic. Typical alignment deviations are in the
>3 to 5 pixels ballpark at the edge, and can go up to 15 pixels in the
>corner for a particular "bad" lens (meaning the hugin abc model cannot
>cope with that lens), all using the barrel distortion parameter b. Now
>do the maths for an image 4000 pixels wide with 40 degrees field of
>view. 10 pixels still give you 1/10 degrees.
>
>Another issue are EXIF-provided lens parameters. If hugin takes them as
>gospel (view not optimised) in the way it does, one may be wrong in
>focal length by a few percent. The way to calibrate this is to take a
>360-degrees panoramic and let hugin determine the parameter v, and
>possibly the full set of parameters for your individual camera lens.
>
>On 30.03.20 15:37, 'ChameleonScales' via hugin and other free panoramic
>
>software wrote:
>> Ok. It's fine if it doesn't get that precise. I can work with around
>1 degree if the software doesn't allow for less.
>>
>> The point is that having a scaling feature would allow me to
>fine-tune the scale based on what I know.
>>
>> Since I superimpose my panorama to imported terrain and map data in
>Blender, I can see when a building or hill should be slightly more to
>the left or right on the photo, then adjust the FOV in Blender using
>the slider I made, and I know this FOV to be correct. I just don't know
>an easy enough way to give this back to Hugin so it exports a corrected
>version.
>>
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Monday, March 30, 2020 10:35 AM, Klaus Foehl
> wrote:
>>
>>> As you are talking sub-degree precision, there is an inherent
>limitation
>>> in the hugin lens model or abc parametrisation. From the
>Brown-Conradi
>>> model, a mathematically sound distortion description, hugin
>implements
>>> only one of the non-trivial parameters, which is parameter b.
>>>
>>> Parameters a and c are not in Brown-Conrady, for polar coordinates
>they
>>> are mathematically not sound, and in practice their use does not
>lead to
>>> the quantitative alignment improvement an extra good parameter would
>>> provide.
>>>
>>> To add to it, I have seen situations where the use of a and c
>parameters
>>> have made things observably bad. If parameters b and the offset
>>> parameters d and e provide you with enough precision, then fine,
>then
>>> hugin is a really good tool for you.
>>>
>>> On 30.03.20 09:37, 'ChameleonScales' via hugin and other free
>panoramic
>>> software wrote:
>>>
Unless I'm missing some geometrical effect, it doesn't seem to me
>that you would have to re-optimize it given that the transformation
>should precisely preserve the panorama's sewing just like in the
>animation above, so as I understand it, control point distances should
>only change proportionally to the scale you apply. But correct me if
>I'm wrong.
As for getting it right in the first place, in my use case, I have
>to superimpose a panorama to its virtual 3D environment in Blender and
>I need sub-degree precision on the HFOV.
I don't think any software could make such a precise guess with the
>photos I get from my clients.
>>> --
--
David W. Jones
gnomeno...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
Sent from my Android device with F/LOSS K-9 Mail.
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/B6AE1F4B-BACF-430C-9281-88D9A429BF62%40gmail.com.
