radial correction
dmg
I got curious about how radial correction is computed and did a small test.
From Helmut's description (remember, he implemented the code):
http://www.all-in-one.ee/~dersch/barrel/barrel.html I learned that the
correction is
dd + cr + br^2 + ar^3 (found in the function radial).
Noticed the first parameter dd. In the page above is referred as d,
but d in panotools has a different meaning.
As he explains, to avoid scaling the sum of dd + c + b + a = 1.
This is supported by the code. dd is computed from a, b and c to
satisfy the invariant.
Now, look at the following test:
http://turingmachine.org/~dmg/temp/test_grid.zip
It looks as if, in the case of the 2 rectangular images, there is
scaling, but not in the squarish image.
In the code, the scale of the image is normalized as 1/2 the smallest
of dimensions. This means the image is not scaled with respect to the
longest dimension,
but it is scaled with respect to the shortest dimension. Now, this
example is a bit extreme because the ration width to length is 2. But
even if it was 1.5 (as with
36mm cameras) the different is significant.
I suspect helmut did this because most people shoot panoramas with the
camera in portrait mode. This way the "horizontal" field of view,
remains unchanged
after the correction has been applied.
With this information we should be able to computer a, b and c
parameters from imatest data (such as the ones published at photozone:
http://www.photozone.de/canon-eos/336-canon-ef-35mm-f14-test-report--review?start=1)
What about the samyang 8mm lens? This radial correction is made before
the photo is remapped to its native projection. One would need to
either: calibrate the lens using the typical methods, or do some math
and approximations
to come to the estimation of these parameters based on the formulas
above. Remember, the lens is closer to stereographic (which we have
implemented in panotools), do not use for this one a typical
equidistant.
Samyang should donate us a couple of lenses to be able to properly
test the code. It has never been used.
--dmg
---
Daniel M. German
http://turingmachine.org
dmg
is in landscape mode might have interesting repercussions during
optimization.
I wonder if a better solution would be to scale with respect to the
corner of the frame.
-dmg
--
Stefan Peter
Hash: SHA1
Hi Daniel
Am 03.01.2011 12:24, schrieb dmg:
> Samyang should donate us a couple of lenses to be able to properly
> test the code. It has never been used.
>
I have a Samyang 8mm. Let me know if you need test pictures (and what
they should contain). If required, I could even be convinced to lend it
to a developer.
Regards
Stefan Peter
- --
In theory there is no difference between theory and practice. In
practice there is.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNIcKoAAoJEBgqi52L7+L/I7kH/RTxGT2jmQ9lLrOJtgxa8WbV
BZlOkvND9ESvnhCjPSXtFFSHbjPMbppnSes/YzAqq2ZcF7Zsjrp9rIQlKrA/YmTc
Vodfm5VzfbGdaKwaal7KNUAMTVEmU+3owVTHGBOa0b2nbPlWIrr11Jm4Gww4UnZO
y3M1COixtANfM8EHJhkGqZvonEnfNId455nQDGIneGCsx6veYGMSOySGUdIShrtn
RSq0r2++N8c9MAEvBlT7A41z+9Zem7NWi6Wu9Kpp58f+E9PVC4a7iFg/2+2UcQCD
pntJR+qfcAtZOfyDeK+QmIgPqtw/KjB2kDu4MplwidHa8viDy0QZq4ntVy9SQf0=
=qI0C
-----END PGP SIGNATURE-----
Bruno Postle
>thinking aloud, the fact that the field of view changes when the image
>is in landscape mode might have interesting repercussions during
>optimization.
In practice the polynomial changes the angular distance between
adjacent stitching seams whatever the photo orientation. The fact
that the angular distance between the sides of a portrait photo
doesn't change isn't that interesting since we rarely use the data
at the sides.
>I wonder if a better solution would be to scale with respect to the
>corner of the frame.
...and abandon the a,b,c polynomial while we are at it. There are
definitely better lens models, the question is do we need the pain
involved with changing from the existing model?
--
Bruno
Jim Watters
> field of view changes when the image is in landscape mode might have
> interesting repercussions during optimization.
> I wonder if a better solution would be to scale with respect to the
> corner of the frame.
a lens.
We need to decide on shortest, longest, or diagonal.
>> I got curious about how radial correction is computed and did a small test.
>>
>> [snip]
>> It looks as if, in the case of the 2 rectangular images, there is
>> scaling, but not in the squarish image.
>>
>> In the code, the scale of the image is normalized as 1/2 the smallest
>> of dimensions. This means the image is not scaled with respect to the
>> longest dimension, but it is scaled with respect to the shortest
>> dimension. Now, this example is a bit extreme because the ration
>> width to length is 2. But even if it was 1.5 (as with 36mm cameras)
>> the different is significant.
>>
>> I suspect helmut did this because most people shoot panoramas with the
>> camera in portrait mode. This way the "horizontal" field of view,
>> remains unchanged after the correction has been applied.
I was sure it was the longest dimension used. I had to go back and check. You
are right it is shortest. I thought that if shooting portrait and instead of
using the minimum number of images needed to make a pano a whole bunch of images
used and cropped down narrow strips of only a few degrees each the same abc
values could be used. But this is not the case.
>> --dmg
>>
>> ---
>> Daniel M. German
>> http://turingmachine.org
--
Jim Watters
http://photocreations.ca
dmg
> definitely better lens models, the question is do we need the pain involved
> with changing from the existing model?
We can leave it as is, and provide a better model, but what would the
alternatives be?
--dmg
>
> --
> Bruno
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to
> hugin-ptx+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/hugin-ptx
Bruno Postle
>> ...and abandon the a,b,c polynomial while we are at it. There are
>> definitely better lens models, the question is do we need the pain involved
>> with changing from the existing model?
>
>We can leave it as is, and provide a better model, but what would the
>alternatives be?
It has been pointed out that the polynomial should only consist of
even numbered powers, both for speed and for mathematical soundness.
The distortion could be a function of angle and not proportion of
width of image. This would make discussions about whether to use
diagonal, width or height irrelevant. Also a single lens would have
the same parameters regardless of sensor size.
Tom Sharpless wrote a system that used a spline rather than a
polynomial curve, this is what is implemented in calibrate_lens. In
principle this would be more stable when optimising and faster when
rendering.
--
Bruno
Tom Sharpless
On Jan 3, 5:45 pm, Bruno Postle <br...@postle.net> wrote:
> On Mon 03-Jan-2011 at 10:49 -0800, Daniel M. German wrote:
>
> >> ...and abandon the a,b,c polynomial while we are at it. There are
> >> definitely better lens models, the question is do we need the pain involved
> >> with changing from the existing model?
>
> >We can leave it as is, and provide a better model, but what would the
> >alternatives be?
>
> It has been pointed out that the polynomial should only consist of
> even numbered powers, both for speed and for mathematical soundness.
>
correction function; since R is always >= 0 the odd symmetry is never
manifested. But skipping powers is probably a good idea, just because
it makes the coefficients a bit more independent, which I think is the
real issue. Most numerical analysts would recommend using some sort
of orthogonal functions, rather than powers of R, which are highly
correlated.
> The distortion could be a function of angle and not proportion of
> width of image. This would make discussions about whether to use
> diagonal, width or height irrelevant. Also a single lens would have
> the same parameters regardless of sensor size.
>
the radial polynomial, to keep one dimension of the image fixed, is
not a good idea when dealing with lens correction. It mixes a linear
scale factor -- analogous to focal length -- into what should properly
be a dimensionless function. The practical effect is that the focal
length computed by PanoTools depends on the image dimensions. But it
is absurd to think that putting a different sensor behind a lens can
change its focal length.
In physical optics the focal length of a lens is defined as the first
derivative of radius with respect to angle (mm/radian), measured at
the optical axis. That is independent of both the size of the image
and the shape of the lens's projection function; it is a pure scale
factor on the angle <=> radius mapping. Thus the dimensionless
'normalized radius', R = radius / focal length, can be corrected by a
polynomial that is also independent of the physical scale of the
image. The proper normalization for that polynomial is unit slope at
zero radius, that is, first order coefficient == 1.
> Tom Sharpless wrote a system that used a spline rather than a
> polynomial curve, this is what is implemented in calibrate_lens. In
> principle this would be more stable when optimising and faster when
> rendering.
>
tabulating it as a spline makes it quick to evaluate in either
direction. But that doesn't change the problem of finding the right
polynomial. It is still necessary to optimize the polynomial before
converting it to spline tables -- directly optimizing the spline is no
good as it has far too many, highly correlated parameters.
I have just been wrestling with the issue of radial correction, as I'm
implementing a 'universal' lens model for Panini. Well, not really
universal, but I think a few steps forward. Its mapping of angle <=>
'ideal' radius can approximate all known lens types -- it is
continuously adjustable from rectilinear thru stereographic thru equal-
angle spherical to equal-area spherical, by a single parameter. The
ideal radius R is in units of 1/focal length. The 'observed radius'
is a polynomial in R with 3 coefficients, a,b,c. But the coefficients
are interpreted differently, depending on the calibration source --
Panini, PanoTools, or Adobe Lens Profiles. The Panini and PT
polynomials are 2nd, 3rd, 4th order; the Panini is normalized to unit
slope while the PT is normalized to keep a particular radius constant
( PT and Panini coefficients can be interconverted ). Adobe
coefficients are 2nd, 4th and 6th order, with slope normalization.
The package will also compute TCA and vignetting corrections as
polynomials in R, using PT or Adobe calibrations. And of course it
can tabulate the angle<=>radius mapping as a pair of splines. All
this is backed by a 'personal' camera and lens database that can store
multiple calibration records per lens (keyed by focal length and f-
number) and knows what lenses go with what cameras, at what average
shift and tilt. No wonder it is taking me so long to finish Panini
V1 :p.
BTW one of the best treatments of lens calibration and correction I've
seen is this article, brought to my attention last year by Michel
Thoby: http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37251/1/03-0869.pdf.
It has a clear and thorough treatment of 'entrance pupil shift' and
describes a parameterized ideal angle-to-radius function more elegant
than mine. Needs serious study, but worth it.
Cheers, Tom
Jeffrey Martin
Bart van Andel
On Thursday, January 6, 2011 5:09:06 AM UTC+1, Tom Sharpless wrote:
> It has been pointed out that the polynomial should only consist of
> even numbered powers, both for speed and for mathematical soundness.
>
I'm not convinced there is anything wrong with odd powers in a radial
correction function; since R is always >= 0 the odd symmetry is never
manifested.
Rogier Wolff
On Thu, Jan 06, 2011 at 04:45:26AM -0800, Bart van Andel wrote:
>
> On Thursday, January 6, 2011 5:09:06 AM UTC+1, Tom Sharpless wrote:
> >
> > > It has been pointed out that the polynomial should only consist of
> > > even numbered powers, both for speed and for mathematical soundness.
> > >
> > I'm not convinced there is anything wrong with odd powers in a radial
> > correction function; since R is always >= 0 the odd symmetry is never
> > manifested.
> >
>
> Isn't there? There is a sharp discontinuity in (the derivative of) any
> odd-powered polynomial, when mirrored around the Y-axis. Since R can only
> have positive values, this discontinuity will happen at the image "center"
> which is used to compute R from. Therefore, it makes sense to avoid odd
> powers.
Ok. So the function y = x has exponent 1, and is not suitable. There
is a sharp corner at x=0, which mathematically manefests itself as a
discontinuity of the derivative:
dy/dx = 1 where x > 0
and = -1 where x < 0 (and undefined for x=0)
Now the derivative of
y = x ^3
is
y = 3 x^2
which after mirroring in x=0 becomes....
dy/dx = 3 x^2 where x > 0
and = 3 (-x)^2 where x < 0
which simplifies to
dy/dx = 3 x^2 for all x.
Even if we're talking about even powers, where the simplification
doesn't work, the value of the derivative is always zero at x=0, so
the derivative won't be discontinuous.
So I understand why the first power is bad, but why the third and
fifth?
(I'm thinking that this is for correcting lens distortions of the form
where pixels belonging at r,theta end up at r',theta on the sensor,
with r' = f (r), and f (x) = x + .... and we're talking about the
.... part Correct?)
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
kfj
On 6 Jan., 11:36, Jeffrey Martin <360cit...@gmail.com> wrote:
> I fully agree that this hFOV and vFOV nonsense should stop. It is really
> annoying for beginners and experienced folks alike!
can't even figure out that the same lens can be used for both
landscape and portrait mode. If it was at least 'fov along the longer
image edge' or 'diagonal field of view' ...
Kay
Jeffrey Martin
Jim Watters
thinking aloud, the fact that the field of view changes when the image is in landscape mode might have interesting repercussions during optimization. I wonder if a better solution would be to scale with respect to the corner of the frame. -dmg
http://panotoolsng.586017.n4.nabble.com/What-is-the-actual-Field-of-View-tt3175092.html
Some lenses eg. the 10.5mm Nikkor on full frame can give you a good stitch with a fairly wide range of fov because of the magnification effects of a, b and c eg. from 190 to 200. So I usually force the optimizer to accept a fov of 196 and an a of -0.16 until towards the end of the optimisation process. Only after I iterate point pair elimination and get the error average down to 3 or 4 pixels do I start to optimise fov and a, b and c generally. But for many purposes a wide fov range of values might look ok with that lens. PeterM
Aron H
On Jan 5, 11:09 pm, Tom Sharpless <tksharpl...@gmail.com> wrote:
>....
> seen is this article, brought to my attention last year by Michel
> Thoby:http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37251/1/03-0869.pdf.
> It has a clear and thorough treatment of 'entrance pupil shift' and
> describes a parameterized ideal angle-to-radius function more elegant
> than mine. Needs serious study, but worth it.
>
> Cheers, Tom
I will in the future. I just wanted to mention that two sources of
widely-used lens calibration are from Jean-Yves Bouguet:
http://www.vision.caltech.edu/bouguetj/calib_doc/
and OpenCV:
http://opencv.willowgarage.com/documentation/camera_calibration_and_3d_reconstruction.html
The Caltech link includes a bunch of references and related links, and
IIRC justified using the even-power polynomials based on optic
characteristics, as well as numerical stability.
I discovered that if you limit Hugin to the 'b' parameter, and the
Caltech package to just the 'r^2' parameter, and scale the radial term
appropriately, they do indeed get the same answer - Caltech from
pictures of checkerboards, and Hugin from calibrating a 360 panorama.
Encouraging....
Regards,
Aron
Tom Sharpless
On Jan 6, 11:07 am, Jeffrey Martin <360cit...@gmail.com> wrote:
> Right. If anything, Diagonal FOV should be used. But it's not. So on that
> note, let's scrap it all and do it the right way :-)
be based on reliable lens calibration data. From the user's point of
view the whole problem is how to make it convenient to get and use
such data.
First, you need to know the lens's focal length in pixels, which is
determined by its physical focal length and the physical size of a
pixel. When dealing with high quality equipment, it is probably safe
to accept the manufacturer's specifications for pixel size and focal
length; but reliable figures are not available for many cameras and
lenses.
Then, you need to know the radial projection function of the lens.
There are no manufacturer's specs for that; and measuring it
physically is very demanding work. The best we can do in most cases
is to use our stitchers to estimate the curve, based on aligning a 360
degree panorama with lots of overlap.
That is really not so hard: I recently calibrated 4 fisheye lenses
that way, at 7 different focal lengths, in about half a day's work
(but I had been using those lenses for between 3 months and 3 years,
before I finally got around to calibrating them! ) Since I used a PT-
based stitcher, the results are polynomial coefficients describing the
deviation of the lenses' curves from the function r = f * theta,
where f is focal length, r and f are in pixels, and
theta is in radians. Or would be, except that the PT polynomial has
been tweaked to hold the r value corresponding to half the smaller
image dimension constant. It is straightforward to calculate the
coefficients of the preferable polynomial, that has constant unit
slope at image center (and so does not alter the apparent focal
length). To do that you need the factor by which PT multiplied the
'ideal radius' input to the polynomial -- which unfortunately it
neither prints nor saves.
The tweak is the result of "FOV-think": PT effectively optimizes the
angle of view corresponding to the fixed radius, rather than the focal
length. It is easier to use FOV this way, as if it were a primary
lens parameter, than to compute it from first principles. And very
tempting to do so, because if it starts from a plausible FOV, the
optimizer can get a good alignment without knowing the pixel size or
lens FL. However, on the basis of a good deal of experience of
writing as well as using lens correction software, I can assure you
that this approach is not sound, and leads to many difficulties.
The new (free) Adobe Lens Profile Creator tool offers an alternative
calibration method based on better principles. Its profiles are very
nearly independent of the camera on which the lens is calibrated, and
work fine when the same lens is used on other cameras. It is more
difficult to do than the stitcher-based method, but gives better
corrections, including TCA and vignetting. Moreover, there are
already a lot of ready made profiles available, and more coming. At
present the profiles are in XML, so one could use them outside Adobe
Camera Raw. I expect Adobe will obfuscate them eventually, so now is
probably a good time to collect them.
By Spring I hope to release a new ''Panini" lens correction tool that
tries to deal with some of these problems.
Regards, Tom
Tom Sharpless
On Jan 7, 11:01 am, Aron H <aron.hel...@gmail.com> wrote:
> On Jan 5, 11:09 pm, Tom Sharpless <tksharpl...@gmail.com> wrote:>....
> > BTW one of the best treatments of lens calibration and correction I've
> > seen is this article, brought to my attention last year by Michel
> > Thoby:http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/37251/1/03-0869.pdf.
> > It has a clear and thorough treatment of 'entrance pupil shift' and
> > describes a parameterized ideal angle-to-radius function more elegant
> > than mine. Needs serious study, but worth it.
>
> > Cheers, Tom
>
> Sorry I don't have time to go digest all of this discussion; hopefully
> I will in the future. I just wanted to mention that two sources of
> widely-used lens calibration are from Jean-Yves Bouguet:http://www.vision.caltech.edu/bouguetj/calib_doc/
> IIRC justified using the even-power polynomials based on optic
> characteristics, as well as numerical stability
rectilinear lens (ideal pinhole model) and won't work for fisheye or
extreme wide angle lenses. Such packages generally aim for much finer
correction than is needed in pictorial photography, the goal being to
measure the scene with sub-pixel accuracy. This perhaps justifies
their narrow range of applicability.
Gennery was not the first to design a unified calibration scheme for
all physically realizable lenses, but he did a very good job of it.
His main goal was surveying Mars stereoscopically through a pair of
fisheye lenses, to a precision comparable to what could have been
achieved with very high quality but uncalibrated long-focal-length
lenses.
PanoTools and Adobe Lens Profiles adopt the practical approach of
separating lenses into two classes: 'normal' (rectlinear) and
'fisheye', and using a different calibration model for each class.
Modern camera lenses have such a variety of projections that more than
two classes might be justified. However the PT and Adobe calibrations
work well enough in practice to satisfy most photographers.
>
> I discovered that if you limit Hugin to the 'b' parameter, and the
> Caltech package to just the 'r^2' parameter, and scale the radial term
> appropriately, they do indeed get the same answer - Caltech from
> pictures of checkerboards, and Hugin from calibrating a 360 panorama.
> Encouraging....
>
Best,
Tom
Tom Sharpless
On Jan 6, 8:17 am, Rogier Wolff <rew-googlegro...@BitWizard.nl> wrote:
> On Thu, Jan 06, 2011 at 04:45:26AM -0800, Bart van Andel wrote:
>
> > On Thursday, January 6, 2011 5:09:06 AM UTC+1, Tom Sharpless wrote:
>
> > > > It has been pointed out that the polynomial should only consist of
> > > > even numbered powers, both for speed and for mathematical soundness.
>
> > > I'm not convinced there is anything wrong with odd powers in a radial
> > > correction function; since R is always >= 0 the odd symmetry is never
> > > manifested.
>
> > Isn't there? There is a sharp discontinuity in (the derivative of) any
> > odd-powered polynomial, when mirrored around the Y-axis. Since R can only
> > have positive values, this discontinuity will happen at the image "center"
> > which is used to compute R from. Therefore, it makes sense to avoid odd
> > powers.
>
> Ok. So the function y = x has exponent 1, and is not suitable. There
> is a sharp corner at x=0, which mathematically manefests itself as a
> discontinuity of the derivative:
>
> dy/dx = 1 where x > 0
> and = -1 where x < 0 (and undefined for x=0)
of y = x is +1 everywhere.
There are no discontinuities in any of the derivatives of non-negative
powers of x.
Regards,
Tom
Klaus
I have to second Bruno in noting the shortcomings of the current
camera model.
And my vote is also for implementing a mathematical model that well
describes real life images from real life lenses.
> You are thinking of y = abs(x) = sqrt( x^^2). The first derivative
> of y = x is +1 everywhere.
> There are no discontinuities in any of the derivatives of non-negative
> powers of x.
dimensional R2 space. For convenience one uses polar coordinates
radius and phi angle but one can transform back into cartesian
coordinates. Now one finds that for odd coefficients this introduces
the sqrt(x^2+y^2) factor and hence some higher (partial) derivatives
at point (0,0) are undefined.
Does it matter in practice: the experience with my Canon A610 is Yes.
I find it limits the alignment quality when doing panoramas. And I
even resort of not using the a and c parameter. Adding a and c locally
improves alignment but at the cost of higher misalignment in areas
without control points.
Recently I had to measure the height profile of a reflective surface.
While the lense self-calibration from partially overlapping pano
photos would have worked well in principle, and the Finetuning
algorithm would have been accurate enough, I estimated the abc
parametrisation to be problematic and the use of solely the b
parameter not accurate enough. In the end I resorted to a non-camera
method.
With a proper lense model the camera would have been a very accurate
angle measuring device and a sequence of only a few photos would have
already recorded all the necessary data including calibration data.
Regards
Klaus
Bruno Postle
>
> I have to second Bruno in noting the shortcomings of the current
> camera model.
Yes it has obvious technical shortcomings, but I'm not certain they
are actually a problem in practice. Switching Hugin to a different
system for would be very disruptive.
--
Bruno
Tom Sharpless
But (having looked into the matter lately) I strongly agree that
revising libpano is not the way to get that. Libpano was designed to
support panorama stitching, not lens calibration. Its way of
representing and optimizing lens parameters is not what an optical
theoretician would prescribe, but it does get the job of aligning
images done very well, thank you. The fact that the resulting
parameters don't apply to images having different dimensions is an
inconvenience only if you make it one, by trying to use them for that.
What I would suggest is to add 'portable' lens calibration at the
level of Hugin, which can be done with at most minor changes to
libpano. The first step would be very easy: converting saved lens
parameters to suit the image at hand. The key to this is storing the
original image dimensions, along with (hfov,a,b,c,d,e). Hugin now
does store at least the width, but uses it only to put up a warning
when you try to apply the lens to an image of a different width.
Instead (or rather, in addition) it should rescale hfov to suit the
new width, which is straightforward using the calibration parameters
and existing libpano functions. That may or may not be a valid
operation, for several possible reasons, however it is valid in all
the common use cases: the image was rotated 90 degrees, or was taken
at a different camera resolution, or with the lens on a different
camera. So this would be a big help to the average Hugin user at
little cost. PTGui is already doing something like this (but without
the warning message).
The next step would be to make it possible to import calibrations from
other sources. I'm thinking of Adobe Lens Profiles in particular; but
it should be easy to accommodate correction polynomials from any
source, if the user is able to pick the source from a list and willing
to enter the coefficients by hand. To apply these foreign
calibrations, libpano would need a new radius correction mode (and
stack routine) for each polynomial style. There is already a var
that selects a radial mode, and the coefficients could go in existing
slots.
It would need some thought whether 'lens' optimizations could be
allowed when using an imported calibration. Certainly, it would not
be feasible to get 'exportable' lens calibrations without heavily
revising libpano; but I have a feeling the libpano model could be used
in tandem with a foreign one, just to better align the current pano.
Anyhow, one required basis for such improvements is a unified
database, that can store any calibration Hugin can use. This should
not be so hard to set up. I'm well along with something of the kind
for Panini, that uses the ini file-based app settings facility of Qt.
It is just a personal-scale db, but that is what I think is wanted
here.
Cheers, Tom