One question is e.g.: What is the exact meaning of the hfov (horizontal 
field of view): Is it the angle measured from the left of the leftmost 
pixel area to the right of the rightmost pixel or from the mid of the left 
to the mid of the right pixel ?

The formulas in the optimizer are faily complicated. But assume that for a 
pixel the angle between the optical axis and the ray going through the 
"reference point" of the pixel area was calcualted, call it alpha. Assume 
the y coordinate is so that the y position is in the middle   [[  y = 
(H-1)/2 if the reference point of each pixel is in the middle of the pixel 
area ]].

Assume in the optimizer the angle alpha is calculated as:
alpha = arctan( (x- (W-1)/2) / ((W-1)/2) * tan(hfov) ) 
This would indicate that the reference point is in the middle of the pixels.

If the calculation would be:
alpha = arctan( (x - W/2) / (W/2) * tan(hfov) )  
This would indicate that the reference point is in the left (and upper) 
pixel area. 

The actual formulas are more complicated, but it should be possible to get 
this information out of them.

[email protected] schrieb am Sonntag, 15. Mai 2022 um 19:56:31 UTC+2:

> Maybe I'm misunderstanding something important, but:
>
> On Sun, May 15, 2022 at 1:29 PM Florian Königstein <[email protected]> 
> wrote:
>
>>
>> I suggest looking at first at the code of the geometrical optimizer 
>> (fastPTOptimizer or libpano13). Probably most of the code with the math 
>> concerning the CP coordinates is the original code of Prof. Helmut Dersch. 
>> Somewhere the pixel coordinates together with the hfov will be converted 
>> into angles on the unit sphere or maybe normed coordinates on some "image 
>> plane". This could be a good place to look. Maybe I find the time and will 
>> look myself.
>>
>
> I cannot see how any of that (the optimizer) needs to be consistent 
> regarding this question with any other part of hugin.  I think the 
> optimizer would only need to be consistent with itself.  The consistency 
> question matters elsewhere.
>
> One significant need for consistency of this definition should be between 
> the fine tuning code (which I haven't looked at myself yet) and the 
> magnifier display.  On a low res monitor, the consistency between the 
> magnifier and the 200% zoom mode should matter.  On my higher res displays, 
> with the hugin++ options of 400% and 800% zoom, consistency matters across 
> the 3-way: fine tuning vs. zoom vs magnifier.
>
> If there is any significant difference in effective resolution between 
> images (a Z translation value or an actual resolution difference), then the 
> blending code has a very serious need for consistent definition vs fine 
> tuning.  I'm hoping to make some changes in blending creating a need for 
> that consistency even without any resolution difference.
>
>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/hugin-ptx/d86a690b-45f1-4850-a2c0-bd2101923fc3n%40googlegroups.com.

Reply via email to