Difference between revisions of "User:Klaus/Improving Hugin"
From PanoTools.org Wiki
(writing a wish list) 
(reply  no offense taken at all) 

(4 intermediate revisions by 2 users not shown)  
Line 1:  Line 1:  
* include antialiasing interpolators  * include antialiasing interpolators  
* add a r^4 term to the a*r^3+b*r^2+c*r+d distortion correction (because the r^4 term like b*r^2 has correct symmetry whereas a and c terms are largely unphysical)  * add a r^4 term to the a*r^3+b*r^2+c*r+d distortion correction (because the r^4 term like b*r^2 has correct symmetry whereas a and c terms are largely unphysical)  
+  : Why that? The formula applies to the radius of the image, which means it is always symmetrical. a and c terms work great to correct for special types of distortion ([[Wavy distortionwavy one]] f.e.) <small>[[User:Erik KrauseErik Krause]] 22:07, 21 July 2009 (UTC)</small>  
+  ::Yes, it does work to some extend, but it is phenomenology only.  
+  ::Mathematically, assuming the lense mapping function to be holomorphic is rather close to reality, without a singularity at r=0. Less stringent, but along the same line is the symmetry argument that flipping the sign, r > r, and adding 180 degrees to the angle, ought to give you the same output values. Polar coordinates need special treatment at r=0, but for the sake of reasoning one can go to (x,y) cartesian coordinates. Terms for a and c require sqrt(x^2+y^2), sqrt() has a singularity at 0 but the lense does not, so a<>0 and c<>0 introduce a behaviour the lense does not have.  
+  ::A few days ago we were discussing the equivalence of different camera models on the huginptx list. One has to compare them to (a*r^3+b*r^2+c*r+d)*r and one finds only odd powers of r in these. There must be a reason (but such heuristic argument I would not buy standalone).  
+  ::And there is a practical issue. Of course we are talking of effects at the pixel level, but I did some tests last weekend and found that the (a,b,c) parameter set for my camera lense actually varies if I choose the placement of my Control Points in different ways. Imagine, you were to follow measurement prescription 1 and find a focal length of 50mm, then you follow measurement prescription 2 and find a focal length of 45mm. Exaggerated and simplified analogy, yes, but that is the situation I could confirm with my lense for the (a,b,c) parameter set.  
+  ::In practice, I remember a stitch with one lone CP in a corner, which was misaligned by 3 pixels. Finding the sharpness ok, Finetune working fine, CA not spoiling either I now do put this to the deficiency of the (a,b,c) parametrisation in panotools.  [[User:KlausKlaus]] 14:01, 22 July 2009 (UTC)  
+  ::: Sorry, I misunderstood. However, distortion doesn't necessarily need to by rotational symmetric anyway, as shown on [http://www.stoske.de/digicam/Artikel/verzeichnung.html], hence one radial model might be as bad as the other. The panotools model seems one of the most widely used  probably hundreds of thousands of panoramas where stitched using it, and my impression was that Prof. [[Helmut DerschDersch]] choose it deliberately  which doesn't mean of course that it can't be enhanced... <small>[[User:Erik KrauseErik Krause]] 19:01, 22 July 2009 (UTC)</small>  
+  :::: Recently on huginptx in the thread "What is optimized FOV really?" we discussed lense models and how to compare Bouguet camera model with Dersch/panotools model. Bouguet does introduce nonrotationallysymmetric terms indeed. Choosing three polynomial coefficients is not too stupid, it is only with deeper mathematical insight that one understands why the even coefficients tend to become zero when one uses "enough" polynomial coefficients. And I do remember that at the time Dersch got hassled not because his model was bad quality, but because others had their inferior software protected by dubious patents.  [[User:KlausKlaus]] 15:57, 23 July 2009 (UTC)  
* allow simultaneous use of both flatfield polynomial and dustmap file  * allow simultaneous use of both flatfield polynomial and dustmap file  
−  * implement orthographic projection (benefits from antialiasing interpolators)  +  * <s>implement orthographic projection (benefits from antialiasing interpolators)</s> <small>implemented in Hugin 0.8.0 [[User:KlausKlaus]] 16:51, 21 July 2009 (UTC)</small> 
[[User:KlausKlaus]] 14:30, 29 May 2008 (CEST)  [[User:KlausKlaus]] 14:30, 29 May 2008 (CEST) 
Latest revision as of 15:57, 23 July 2009
 include antialiasing interpolators
 add a r^4 term to the a*r^3+b*r^2+c*r+d distortion correction (because the r^4 term like b*r^2 has correct symmetry whereas a and c terms are largely unphysical)
 Why that? The formula applies to the radius of the image, which means it is always symmetrical. a and c terms work great to correct for special types of distortion (wavy one f.e.) Erik Krause 22:07, 21 July 2009 (UTC)
 Yes, it does work to some extend, but it is phenomenology only.
 Mathematically, assuming the lense mapping function to be holomorphic is rather close to reality, without a singularity at r=0. Less stringent, but along the same line is the symmetry argument that flipping the sign, r > r, and adding 180 degrees to the angle, ought to give you the same output values. Polar coordinates need special treatment at r=0, but for the sake of reasoning one can go to (x,y) cartesian coordinates. Terms for a and c require sqrt(x^2+y^2), sqrt() has a singularity at 0 but the lense does not, so a<>0 and c<>0 introduce a behaviour the lense does not have.
 A few days ago we were discussing the equivalence of different camera models on the huginptx list. One has to compare them to (a*r^3+b*r^2+c*r+d)*r and one finds only odd powers of r in these. There must be a reason (but such heuristic argument I would not buy standalone).
 And there is a practical issue. Of course we are talking of effects at the pixel level, but I did some tests last weekend and found that the (a,b,c) parameter set for my camera lense actually varies if I choose the placement of my Control Points in different ways. Imagine, you were to follow measurement prescription 1 and find a focal length of 50mm, then you follow measurement prescription 2 and find a focal length of 45mm. Exaggerated and simplified analogy, yes, but that is the situation I could confirm with my lense for the (a,b,c) parameter set.
 In practice, I remember a stitch with one lone CP in a corner, which was misaligned by 3 pixels. Finding the sharpness ok, Finetune working fine, CA not spoiling either I now do put this to the deficiency of the (a,b,c) parametrisation in panotools.  Klaus 14:01, 22 July 2009 (UTC)
 Sorry, I misunderstood. However, distortion doesn't necessarily need to by rotational symmetric anyway, as shown on [1], hence one radial model might be as bad as the other. The panotools model seems one of the most widely used  probably hundreds of thousands of panoramas where stitched using it, and my impression was that Prof. Dersch choose it deliberately  which doesn't mean of course that it can't be enhanced... Erik Krause 19:01, 22 July 2009 (UTC)
 Recently on huginptx in the thread "What is optimized FOV really?" we discussed lense models and how to compare Bouguet camera model with Dersch/panotools model. Bouguet does introduce nonrotationallysymmetric terms indeed. Choosing three polynomial coefficients is not too stupid, it is only with deeper mathematical insight that one understands why the even coefficients tend to become zero when one uses "enough" polynomial coefficients. And I do remember that at the time Dersch got hassled not because his model was bad quality, but because others had their inferior software protected by dubious patents.  Klaus 15:57, 23 July 2009 (UTC)
 Sorry, I misunderstood. However, distortion doesn't necessarily need to by rotational symmetric anyway, as shown on [1], hence one radial model might be as bad as the other. The panotools model seems one of the most widely used  probably hundreds of thousands of panoramas where stitched using it, and my impression was that Prof. Dersch choose it deliberately  which doesn't mean of course that it can't be enhanced... Erik Krause 19:01, 22 July 2009 (UTC)
 allow simultaneous use of both flatfield polynomial and dustmap file

implement orthographic projection (benefits from antialiasing interpolators)implemented in Hugin 0.8.0 Klaus 16:51, 21 July 2009 (UTC)
Klaus 14:30, 29 May 2008 (CEST)