On 26 Dez., 15:29, Tom Sharpless <[email protected]> wrote:
> A useful lens calibration database has to identify the lens, and the
> camera sensor format (physical pixel dimensions). It is a sad fact
> that EXIF data often don't identify the lens, especially if you use
> 'foreign' lenses; and that what ID there is is largely manufacturer-
> specific.
As Thomas has had a hard time explaining to me ;-) libexiv2 in the
latest version now handles the LensModel tag in a maker-independent
way, so you can access it as "Exif.Photo.LensModel". And this is a
string, not some index into a maker-specific list as the common
LensType tag. This may, once it's trickled down to mainstream, offer a
convenient location to put the lens information; the very latest hugin
already looks at it if the libexiv2 version is recent enough. One
can't reasonably expect every lense's ID to show up in the EXIF - how
would the camera know about it, unless there's some sort of
information exchange? (Of course, if it's merely another maker's lens
and communicates with the body there is no excuse...). Nevertheless,
patching it in is easily done with exiftool or the likes of it.
> Consequently I think it is a mistake to put too much effort into
> deconstructing EXIF files, and trying to make a 'universal' database.
> Instead, we should aim for a personal database that 'learns' to
> correctly guess the lens and pixel size based on what a given
> photographer actually uses, using EXIF data and image dimensions, and
> resolving uncertainties by having the user select from short, relevant
> lists of possibilities. I could live with that.
I agree with you. This is why I keep going on about mechanisms for
loading lens.ini files triggered by information in the EXIF data. Say
you have a lens X, with the Exif LensModel tag set to "X", the
mechanism would try and load "X.ini" from a specific folder, resort to
a default "default.ini" from the same folder if "X.ini" can't be found
and use the old mechanism as a fallback if neither can be found or the
behaviour isn't activated in the preferences (so the mechanism is opt-
in and user-configurable).
> Of course, given a suitable standard for portable lens calibrations,
> such a system could still free the average user from having to
> calibrate his own lenses.
I'm not sure if this is true. I think that there is enough variation
even within lenses from the same series that the calibration data from
one type 'X' lens may be wrong for another type 'X'. The situation
becomes even more difficult when it comes to changeable lenses, as the
same holds true for bodies, and also the precise position of the lens
(resulting in lens shift parameters d and e) can allegedly vary every
time the lens is taken off and put back on again. So a value from a
database can only serve as a starting point in case there's nothing
better, but for really accurate results you have to calibrate your own
equipment with it's specific features.
> Adobe's 'lens profiles' scheme works well
> for both fisheye and normal lenses, and since it is an open standard,
> we could use it too. And get the benefit of a big base of published
> calibrations. It is presently hampered by a rather difficult
> calibration program and by a less than fully useful implementation of
> lens corrections in ACR; however the calibration data format is
> perfectly sound and could support other correction software and other
> calibration tools. Or we could use my "ULM". The important things
> are to get reliable transfer of usable calibrations from originator to
> user, and to support all lenses, including fish-eyes.
Any mechanism to help setting the lens parameters right without manual
intervention would be a great help. Even the first step of setting the
projection type to something sensible based on the LensModel tag would
be a great help already, since it would free me from having to code
stuff like
if [[ "$FLENGTH" == "9.4 mm" ]]
then
pto_gen -p 10 -f 137 -o ...
else
pto_gen -o ...
fi
which is really a nuisance and one can't reasonably expect the average
user to do. I'd be sceptical about using commercial companies' tools,
though; they might decide the next day you can't use their stuff
anymore and there you go, you've coded for nothing, or you only get a
body of data which eventually becomes obsolete (you know which lens
database I mean). It could be used as a starting point, though.
BTW - since you mention your ULM, I googled it and I landed on the
Panini Pro Website. There was a Panini version without the Pro once,
but it seems to have been abandoned? No matter if I get the tar ball
from SF or pull the svn repo, all I ever get is 0.71.104, which
doesn't work very well on my system (like, it crashes when I try and
open a file...). Any chance you'd let something more recent trickle
down to FOSS eventually? Or am I looking in the wrong place?
You proposed earlier to have a go at creating a modified libpano
version using your universal lens model. I'd be intersted in
experimenting with it, but I don't know libpano very well, which is
why I haven't yet volunteered to help you. I've been tinkering myself
with image warping recently and found it a rewarding topic. If you
have more specific ideas about what sort of help you could do with,
there's a chance I might be able to participate. It's just that the
libpano sources are about as inscrutable as hugin's, and I usually
feel great trepidation when it comes to trying to make sense of them.
If you could point me at specific locations where you'd think your
code could be placed, I might be able to grasp more easily what would
have to be done and judge whether I'd feel comfortable to help.
Kay
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
