PTLense Database Update?
Anthony Bak
Where I could get an updated PTLens Database? Is there an updated
release planned soon?
I recently purchased a canon sd800 and it appears to suffer from quite
a bit of distortion due to it's wide angle lens. I would like to
write a script using clens to automatically fix photos as I upload
them to my computer (I'm running gentoo linux)
Thanks
Daniel M. German
Hi Anthony,
As far as I know, the database is not being updated. But this is
something that needs to be improved, so perhaps we should try to
update it. The problem, however, is that most of us use only 1 or 2
lenses, and rarely use a P&S camera. We would need the users to
calibrate their cameras/lenses and submit their results.
dmg
Anthony> I'm new to these tools and this forum.
Anthony> Where I could get an updated PTLens Database? Is there an updated
Anthony> release planned soon?
Anthony> I recently purchased a canon sd800 and it appears to suffer from quite
Anthony> a bit of distortion due to it's wide angle lens. I would like to
Anthony> write a script using clens to automatically fix photos as I upload
Anthony> them to my computer (I'm running gentoo linux)
Anthony> Thanks
Anthony>
--
Daniel M. German
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
Pablo d'Angelo
>
> Hi Anthony,
>
> As far as I know, the database is not being updated. But this is
> something that needs to be improved, so perhaps we should try to
> update it. The problem, however, is that most of us use only 1 or 2
> lenses, and rarely use a P&S camera. We would need the users to
> calibrate their cameras/lenses and submit their results.
Yes, this would be an very important resource. For this we can either have a
special maintainer, or maybe a web-application that lets users submit their
parameters (for example, the lens ini files produced by hugin).
Actually I'd like to see a good database that also includes the vignetting
and response curve behavior, so that this can be used for both kinds of
correction. This implies that many calibrations, with different aperture
settings and focal lengths need to be done.
This would be of great value for automatic correction of images. I'd like to
support such a thing from hugin as well, but I didn't have the time to work
on this so far.
Obviously, calibration accuracy will vary with the user experience, but by
allowing multiple entries for the same lens by multiple people might be a
way to work round that issue.
ciao
Pablo
Pablo d'Angelo
Note that fulla (distributed with hugin) is a better tool to correct
images than clens (which actually uses the coefficients in a slightly wrong
way and might not fully correct the distortion).
> Maybe we should start to dream a little... What would be the
> "ultimate" calibration database. What kind of calibration methods
> should it support?
In the order of importance:
1. radial lens distortion (for multiple focal lengths (and maybe focus
settings)), like the current PTLens database
2. type of lens (so that fisheye images can be automatically
rectified, if desired)
2. Vignetting correction (as in hugin)
3. TCA correction coefficients (maybe for multiple focal lengths, needs to
be checked)
4. Camera response curve, required for very accurate vignetting correction.
Depends on several camera settings, probably to many variables to be truly
useful in the general case.
> How should the data be entered.
Probably by uploading the data though a web-interface :-)
If somebody with some time is available as a maintainer and would
do some quality control on the submitted projections, then maybe a web
interface is not required. Depending on the amount of people contributing,
it might be workable, if somebody can spare ~ 2-4 hours every week for this,
once the infrastructure is in place.
> When we get our list of features, then we should perhaps prioritize
> them (support this kind of calibration first, no web interface etc).
>
> Just to get us started.
>
> What are the best methods to calibrate?
1. distortion: Using the straight line control points in hugin. PTLens had a
useful manual on this, I don't know if its still available.
Some weeks ago Rik Littlefield also made an analysis how many lines are needed:
http://www.nabble.com/Correction-of-Complex-Optical-Distortions-tf3014719.html#a8425523
2. vignetting calibration: the new vignetting + exposure correction in hugin
(I hope I can finish integration into hugin it this week).
3. TCA: I have written some octave scripts that can estimate TCA very
precisely, given an image with a diagonal checkerboard. I'm currently
working with Michel Thoby on this for testing fisheye lenses, but I
hope to have the time to properly release that. Another option would
be to use the method described at http://hugin.sf.net/tutorials/tca
or the PTShift program, if photoshop is available.
> Should we support more then one method?
Do you mean more than one way to describe distortions?
I'd say we should stick to the panotools or hugin ways of
modelling the defects. They are more than adequate for
the usual photographer.
In photogrammetry, more elaborate models than the
simple radial distortion model used by panotools are known.
However, they are harder to calibrate properly, and they
would probably be too accurate (for our use) anyway and require
recalibration once you shake or rotate your camera ;-)
> If it's user submitted through a web site should there be ratings
> attached to the quality of the calibration?
Yes, this is needed, maybe the users should also upload the source
images they have used for calibration as well as their hugin/Panotools
script file, so that the results can be checked, or recalibrated
if the original calibration was not good.
As this is an extended version of the database, we will either need
to extend the PTLens format or define a new one (for example based on XML).
Finally, to really get this off the ground, the database should be
used by other programs such as ufraw, digikam and other tools that are
popular for managing/process digital photos. We should contact them, since
they might have resources we a currently lacking. Also we will reach a
larger user base and the database can be filled much faster then (I hope).
I'd love to participate in this, but given the work with the google summer
of code and other hugin related work, I can only contribute my opinion every
now and then.
ciao
Pablo
Pablo d'Angelo
> At the very end you bring up a good point. Is it to late to make a
> google summer of code project out of this? Its seems like a good
> candidate.
Hmm, it is a bit late unfortunately. I should have thought about that before
the student application deadline..
ciao
Pablo
Arnd Baecker
[...]
> Finally, to really get this off the ground, the database should be
> used by other programs such as ufraw, digikam and other tools that are
> popular for managing/process digital photos. We should contact them, since
> they might have resources we a currently lacking. Also we will reach a
> larger user base and the database can be filled much faster then (I hope).
Yes, that would indeed be great - for example
there is a wish for digikam to integrate clens support
http://bugs.kde.org/show_bug.cgi?id=98651
So maybe a tool which just depends on panotools
(and not hugin as well, if that is possible?) would
be very useful.
Best, Arnd