Lens Correction in PanoTools - Revision history

Zarl: Reverted edits by Koae (Talk) to last version by Tksharpless

2011-11-10T12:01:30Z

Reverted edits by Koae (Talk) to last version by Tksharpless

Koae: /* Lens Correction in PanoTools */

2011-11-10T09:53:47Z

‎Lens Correction in PanoTools

Tksharpless: /* Fully Portable Corrections */

2011-01-24T17:16:34Z

‎Fully Portable Corrections

Tksharpless: /* Fully Portable Corrections */

2011-01-24T17:09:03Z

‎Fully Portable Corrections

Tksharpless: /* Fully Portable Calibrations */

2011-01-24T16:46:10Z

‎Fully Portable Calibrations

Tksharpless: /* Fully Portable Corrections */

2011-01-24T02:37:46Z

‎Fully Portable Corrections

Tksharpless: /* Fully Portable Corrections */

2011-01-24T02:36:38Z

‎Fully Portable Corrections

Tksharpless: /* Fully Portable Corrections */

2011-01-24T02:34:20Z

‎Fully Portable Corrections

Tksharpless: /* Portable Correction Coefficients */

2011-01-24T02:27:29Z

‎Portable Correction Coefficients

Tksharpless: /* Fully Portable Corrections */

2011-01-24T02:24:59Z

‎Fully Portable Corrections

@@ Line 3: / Line 3: @@
 =Lens Correction in PanoTools=
-The PanoTools library implements an effective, but rather idiosyncratic method for correcting lens projections, that causes a good deal of puzzlement.  Lens parameters optimized for one image format generally do not work for a different format; even rotating a set of images 90 degrees before aligning them produces different and incompatible lens parameters.  One would expect that there must be a way to convert either of those parameter sets to a common form, that would apply equally well to both formats, or indeed to any image taken with the same lens.  To see how that might be done, I have made a detailed analysis of PanoTools lens correction computations, based on the code in historic as well as current versions of libpano and helpful discussions with Helmut Dersch.  [http://ca.bestessays.com/ paper writing service]
+The PanoTools library implements an effective, but rather idiosyncratic method for correcting lens projections, that causes a good deal of puzzlement.  Lens parameters optimized for one image format generally do not work for a different format; even rotating a set of images 90 degrees before aligning them produces different and incompatible lens parameters.  One would expect that there must be a way to convert either of those parameter sets to a common form, that would apply equally well to both formats, or indeed to any image taken with the same lens.  To see how that might be done, I have made a detailed analysis of PanoTools lens correction computations, based on the code in historic as well as current versions of libpano and helpful discussions with Helmut Dersch.
 ==Why Lens Correction?==

@@ Line 3: / Line 3: @@
 =Lens Correction in PanoTools=
-The PanoTools library implements an effective, but rather idiosyncratic method for correcting lens projections, that causes a good deal of puzzlement.  Lens parameters optimized for one image format generally do not work for a different format; even rotating a set of images 90 degrees before aligning them produces different and incompatible lens parameters.  One would expect that there must be a way to convert either of those parameter sets to a common form, that would apply equally well to both formats, or indeed to any image taken with the same lens.  To see how that might be done, I have made a detailed analysis of PanoTools lens correction computations, based on the code in historic as well as current versions of libpano and helpful discussions with Helmut Dersch.
+The PanoTools library implements an effective, but rather idiosyncratic method for correcting lens projections, that causes a good deal of puzzlement.  Lens parameters optimized for one image format generally do not work for a different format; even rotating a set of images 90 degrees before aligning them produces different and incompatible lens parameters.  One would expect that there must be a way to convert either of those parameter sets to a common form, that would apply equally well to both formats, or indeed to any image taken with the same lens.  To see how that might be done, I have made a detailed analysis of PanoTools lens correction computations, based on the code in historic as well as current versions of libpano and helpful discussions with Helmut Dersch.  [http://ca.bestessays.com/ paper writing service]
 ==Why Lens Correction?==

@@ Line 103: / Line 103: @@
 The focal length in pixels must be known in order to compute, or to apply, any lens calibration, portable or not.  Physically, this quantity depends on lens focal length and camera properties.  Today, equipment manufacturers' specifications usually provide the needed data:
 :	<math>\textstyle F_{pixels} = F_{mm} \frac {sensor\ width\ in\ pixels} {sensor\ width\ in\ mm}</math>.
-Alternatively, the EXIF data from most modern high-end cameras includes the "focal plane resolution" field, which gives the physical pixel size directly.
+Alternatively, the EXIF data from most high-end cameras includes the "focal plane resolution" field, which gives the physical pixel size directly.
-In any practical calibration scheme F is actually an adjustable parameter.  However the fitted value is expected to be quite close to the one given by the physical specifications, which would of course be used as the initial value.  The main uncertainty is how accurately the nominal lens focal length reflects the true one, because for digital cameras the focal plane resolution is known exactly.  With <math> h </math> the width of a pixel in mm, the portable form of the fitted lens focal length is
+In any practical calibration scheme <math>\textstyle F_{pixels} </math> is actually an adjustable parameter.  However the fitted value is expected to be quite close to the one given by the physical specifications, which would of course be used as the initial value.  The main uncertainty is how accurately the nominal lens focal length reflects the true one, because normally the focal plane resolution is precisely known.
 :	<math>\textstyle F_{mm}  =  h F_{pixels} =  h e</math>, scale factor e defined above.
 To adapt a portable correction to a given image it is only necessary to calculate <math>\textstyle F_{pixels} </math> from the calibrated <math>\textstyle F_{mm} </math> and the the pixel size associated with the image.

@@ Line 107: / Line 107: @@
 In any practical calibration scheme F is actually an adjustable parameter.  However the fitted value is expected to be quite close to the one given by the physical specifications, which would of course be used as the initial value.  The main uncertainty is how accurately the nominal lens focal length reflects the true one, because for digital cameras the focal plane resolution is known exactly.  With <math> h </math> the width of a pixel in mm, the portable form of the fitted lens focal length is
 :	<math>\textstyle F_{mm}  =  h F_{pixels} =  h e</math>, scale factor e defined above.
 To adapt a portable correction to a given image it is only necessary to calculate <math>\textstyle F_{pixels} </math> from the calibrated <math>\textstyle F_{mm} </math> and the the pixel size associated with the image.
-To adapt a portable correction to a given image it is only necessary to calculate <math>\textstyle F_{pixels} </math> from the calibrated <math>\textstyle F_{mm} </math> and the the pixel size associated with the image.  As a fall-back when no pixel size is specified, <math>\textstyle F_{pixels} </math> can be calculated from hfov and image width as libpano does now.  If hfov was fitted on the same image format, this will be the correct value; so portable corrections would not invalidate existing scripts in presently correct use cases.
-Unfortunately PanoTools does not now use any physical parameters.  As it stands now, fully portable corrections would have to be calculated, saved and restored by front-end software that has access to the camera's sensor size.  But if physical pixel size and focal length were added to the PanoTools parameter set, libpano could handle fully portable corrections autonomously.
+Unfortunately PanoTools does not now use any physical parameters, so fully portable corrections would have to be calculated, saved and restored by front-end software that has access to focal length and pixel size.  But if those were added to the PanoTools parameter set, libpano could handle fully portable corrections autonomously.

@@ Line 97: / Line 97: @@
 Along with the ideal function A2Nsource(), which gives N as a function of angle, this constitutes a portable lens correction function.
-==Fully Portable Calibrations==
+==Fully Portable Corrections==
 To make a lens correction fully portable also requires expressing the fitted focal length in physical units rather than in pixels.
-The focal length in pixels must be known in order to compute, or to apply, any lens calibration, portable or not.  Physically, this quantity depends on lens focal length and camera properties.  In most cases today, equipment manufacturers' specifications provide the needed data:
+The focal length in pixels must be known in order to compute, or to apply, any lens calibration, portable or not.  Physically, this quantity depends on lens focal length and camera properties.  Today, equipment manufacturers' specifications usually provide the needed data:
 :	<math>\textstyle F_{pixels} = F_{mm} \frac {sensor\ width\ in\ pixels} {sensor\ width\ in\ mm}</math>.
-In any practical calibration scheme F is actually an adjustable parameter.  However the fitted value is expected to be quite close to the one implied by these physical specifications, the main uncertainty being how accurately the nominal lens focal length reflects the true one.
+Alternatively, the EXIF data from most modern high-end cameras includes the "focal plane resolution" field, which gives the physical pixel size directly.
-−
-With <math> h </math> the width of a pixel in mm, the portable form of the fitted lens focal length is
+In any practical calibration scheme F is actually an adjustable parameter.  However the fitted value is expected to be quite close to the one given by the physical specifications, which would of course be used as the initial value.  The main uncertainty is how accurately the nominal lens focal length reflects the true one, because for digital cameras the focal plane resolution is known exactly.  With <math> h </math> the width of a pixel in mm, the portable form of the fitted lens focal length is
 :	<math>\textstyle F_{mm}  =  h F_{pixels} =  h e</math>, scale factor e defined above.
-To adapt a portable correction to a given image format it is only necessary to calculate <math>\textstyle F_{pixels} </math> from the calibrated <math>\textstyle F_{mm} </math> and the the format's pixel size.
+To adapt a portable correction to a given image it is only necessary to calculate <math>\textstyle F_{pixels} </math> from the calibrated <math>\textstyle F_{mm} </math> and the the pixel size associated with the image.  As a fall-back when no pixel size is specified, <math>\textstyle F_{pixels} </math> can be calculated from hfov and image width as libpano does now.  If hfov was fitted on the same image format, this will be the correct value; so portable corrections would not invalidate existing scripts in presently correct use cases.
-Unfortunately PanoTools does not use any physical parameters.  So as it stands now, portable lens calibrations would have to be calculated, saved and restored by front-end software that has access to the camera's sensor size.  But if physical pixel size were added to the PanoTools parameter set, libpano could handle portable lens calibrations autonomously.
+Unfortunately PanoTools does not now use any physical parameters.  As it stands now, fully portable corrections would have to be calculated, saved and restored by front-end software that has access to the camera's sensor size.  But if physical pixel size and focal length were added to the PanoTools parameter set, libpano could handle fully portable corrections autonomously.
-  -- 23 Jan 2010 T K Sharpless
+  -- 24 Jan 2010 T K Sharpless
 [[Category:Community:Project]]

@@ Line 82: / Line 82: @@
 and the fitted coefficient values would be portable.
-Altenratively the current non-portable coefficients can be converted using data available inside libpano.  With
+Alternatively the current non-portable coefficients can be converted using data available inside libpano.  With
 :	<math>\textstyle k = \frac d {r_0}</math>,
 :	<math>\textstyle w' =  w k </math>,