Fisheye lenses, exif data and projection
T. Modes
I added code to display the lens in the GUI. It is using the
information stored in the EXIF section to identify the lens (via the
exiv2 lib). With this information it would be possible to
automatically set the correct projection when adding images to Hugin.
But to implement this I need more information.
I need the lens type/name (as reported by hugin or exiv2) and the
projection you are using for this lens.
The lens name can be read inside Hugin (images tab) or you are using
exiv2 (run "exiv2 -pt image.jpg | grep Lens" and search for lens name
in the output, depending on the maker a different tag is shown).
So please post the lens names and the projection Hugin should set
automatic.
Thomas
PS: If the lens is not recognized by exiv2 (and therefore by hugin),
this will not work. In this case it needs to be fixed in exiv2 or the
lens information is not stored inside the EXIF header, e.g. for some
manual lenses. This can't be fixed by Hugin.
Harry van der Wolf
results from the Dutch jury:
Panasonic Lumix DMC-TZ10 (12x zoom):
$ exiv2 -pt 20110930-002.JPG | grep -i lens
Exif.Panasonic.ConversionLens Short 1 Off
My older Panasonic Lumix DMC-TZ5 (10x zoom) gives exactly the same:
Exif.Panasonic.ConversionLens Short 1 Off
My oldest Panasonic Lumix DMC-LX55 (3x zoom) gives also exactly the same:
Exif.Panasonic.ConversionLens Short 1 Off
I assume that every panasonic with a non-interchangeable zoom lens will show the same result.
Harry
T. Modes
feature was not intended. For these lenses the "standard" rectilinear
lens is correct and should not changed.
But for (interchangeable) fisheye lenses this rectilinear is a bad
starting point. So the idea was, if a fisheye lens was recognized from
the EXIF data to set the projection to a suitable projection and so to
reduce the risk of wrong user input.
Thomas
Harry van der Wolf
off course :). I reacted too fast. At the moment I read your mail I was importing photos from my camera after a nice afternoon and decided to react immediately. Not so smart.
Harry
Erik Krause
> I need the lens type/name (as reported by hugin or exiv2) and the
> projection you are using for this lens.
The ExifTool LensType lists contain the long names of the lenses
including whether it's a fisheye or not. F.e.
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html#LensType
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Nikon.html#LensID
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Pentax.html#LensType
> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Minolta.html#LensType
and more...
--
Erik Krause
http://www.erik-krause.de
Felix Hagemann
thanks for effort. Basically I see this as the foundation for a
feature that would be very, very welcome: Automatic loading of lens
profiles, either as hugin's ini files or even using lensfun...
I haven't had a chance to compile a development version but those are
the results using exiv2:
Tokina ATX 3,5-4,5/10-17 on a Canon cam:
Exif.CanonCs.LensType Short 1 Canon EF
20-35mm f/3.5-4.5 USM
Exif.CanonCs.Lens Short 3 10.0 - 17.0 mm
Sigma 8mm f/3.5 on a Canon as well:
Exif.CanonCs.LensType Short 1 Sigma 8mm
f/3.5 EX DG Circular Fisheye
Exif.CanonCs.Lens Short 3 8.0 mm
Projection is circular fisheye for both (as the Tokina is shaved and
on a fullframe). I guess an "i" line says it all:
Tokina 10-17mm:
i w2920 h4386 f2 v117.772439775232 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1
r-0.26688363778535 p6.42867375867582 y8.88850974602797 TrX0 TrY0 TrZ0
j0 a-0.076564228939927 b0.146416251483121 c-0.127273572255958
d3.29060949385297 e32.5427777981069 g0 t0 Va1 Vb-0.18283780242918
Vc0.141516026005642 Vd-1.72893502580412 Vx0 Vy0 S-571,3497,192,4260
Vm5 u10 n"fused_img_7119_ca.tif"
Sigma 8mm:
i w2920 h4386 f2 v188.893386867747 Ra-0.0238978080451488
Rb-0.00565842119976878 Rc0.0556895099580288 Rd0.0127557357773185
Re0.0257034469395876 Eev12.9657842161378 Er1 Eb1 r88.2204948922683
p-0.766704317808744 y7.84659018364293 TrX0 TrY0 TrZ0 j0 a-0.0364017
b-0.0961726510604123 c-0.025814 d4.67388 e29.6742 g0 t0 Va1
Vb-0.279826201600424 Vc-1.52248326430879 Vd-2.2738137786917 Vx0 Vy0
S80,2850,838,3608 Vm5 u10 n"jmg_4601_ca.tif"
Cheers
Felix
T. Modes
finally someone who understands me ;-)
> thanks for effort. Basically I see this as the foundation for a
> feature that would be very, very welcome: Automatic loading of lens
> profiles, either as hugin's ini files or even using lensfun...
see the following issues using lensfun from inside Hugin:
1.) Lensfuns reports only a very general lens type fisheye. Hugin
supports circular fisheye, full frame fisheye, orthographic,
stereographic, equisolid, Thoby fisheye.
2.) The crop rectangle/circle is not stored in the database.
3.) Lensfun does not natively build on windows (you can only cross
compile on linux for windows).
> I haven't had a chance to compile a development version but those are
> the results using exiv2:
>
> Tokina ATX 3,5-4,5/10-17 on a Canon cam:
> Exif.CanonCs.LensType Short 1 Canon EF
> 20-35mm f/3.5-4.5 USM
> Exif.CanonCs.LensType Short 1 Sigma 8mm
> f/3.5 EX DG Circular Fisheye
> on a fullframe). I guess an "i" line says it all:
(because exiv2 can't identify it correctly).
Thomas
Bruno Postle
>
>> thanks for effort. Basically I see this as the foundation for a
>> feature that would be very, very welcome: Automatic loading of lens
>> profiles, either as hugin's ini files or even using lensfun...
>
>Yes, that's the goal. I'm currently evaluating lensfun. Currently I
>see the following issues using lensfun from inside Hugin:
>1.) Lensfuns reports only a very general lens type fisheye. Hugin
>supports circular fisheye, full frame fisheye, orthographic,
>stereographic, equisolid, Thoby fisheye.
>2.) The crop rectangle/circle is not stored in the database.
>3.) Lensfun does not natively build on windows (you can only cross
>compile on linux for windows).
These things can be fixed as they seem to be the sort of thing that
lensfun should support. I hoped that this would make a good Summer
of Code project but nobody was interested.
We have a lot to gain from Hugin/lensfun integration: Hugin and
Calibrate Lens are the best tools for adding new camera/lenses to
the lensfun database, using the database to detect lenses will make
Hugin simpler and more reliable, and there is a wider community
around RAW converters that are already commited to using and
maintaining lensfun.
--
Bruno
Brent
for the Canon 15mm fisheye...
Looks like exiv2 -pt doesn't give much for RAW images:
Exif.Image.LensInfo Rational 4 15/1 15/1
0/0 0/0
But exiv2 -pa does give some more XMP data:
Exif.Image.LensInfo Rational 4 15/1 15/1
0/0 0/0
Xmp.aux.LensInfo XmpText 17 15/1 15/1
0/0 0/0
Xmp.aux.Lens XmpText 20 EF15mm f/
2.8 Fisheye
Xmp.aux.LensID XmpText 2 13
Xmp.crs.LensProfileEnable XmpText 1 1
Xmp.crs.LensManualDistortionAmount XmpText 1 0
Xmp.crs.LensProfileSetup XmpText 6 Custom
Xmp.crs.LensProfileName XmpText 42 Canon EOS
5D Mark II (Canon EF 15mm f/2.8)
Xmp.crs.LensProfileFilename XmpText 51 Canon EOS
5D Mark II (Canon EF 15mm f2.8) - RAW.lcp
Xmp.crs.LensProfileDigest XmpText 32
DEC51D6F0D78533546082B6E81D82EA2
Xmp.crs.LensProfileDistortionScale XmpText 1 0
Xmp.crs.LensProfileChromaticAberrationScale XmpText 3 100
Xmp.crs.LensProfileVignettingScale XmpText 3 100
And exiftool shows some other fields:
Lens Profile Enable : 1
Lens Manual Distortion Amount : 0
Lens Profile Setup : Custom
Lens Profile Name : Canon EOS 5D Mark II (Canon EF 15mm
f/2.8)
Lens Profile Filename : Canon EOS 5D Mark II (Canon EF 15mm
f2.8) - RAW.lcp
Lens Profile Digest : DEC51D6F0D78533546082B6E81D82EA2
Lens Profile Distortion Scale : 0
Lens Profile Chromatic Aberration Scale: 100
Lens Profile Vignetting Scale : 100
Lens Info : 15mm f/?
DNG Lens Info : 15mm f/?
Lens Type : Canon EF 15mm f/2.8 Fisheye
Lens Model : EF15mm f/2.8 Fisheye
Lens Drive No AF : Focus search on
Lens AF Stop Button : AF stop
Lens : 15.0 mm
Lens ID : Canon EF 15mm f/2.8 Fisheye
Lens : 15.0 mm (35 mm equivalent: 14.6 mm)
Images converted from RAW to TIFF using ACR or LR show similar fields.
Brent
David Haberthür
On 16.10.2011, at 16:12, T. Modes wrote:
> So please post the lens names and the projection Hugin should set
> automatic.
Sigma 8.0 mm on a Nikon D80: Circular Fisheye (iPhoto tells a bit more: http://cl.ly/BFCA) in portrait orientation.
Hugin was manually set to Circular Fisheye, the lens.ini is attached below.
Habi
kfj
> Hi all,
>
> I added code to display the lens in the GUI. It is using the
> information stored in the EXIF section to identify the lens (via the
> exiv2 lib). With this information it would be possible to
> automatically set the correct projection when adding images to Hugin.
> But to implement this I need more information.
> I need the lens type/name (as reported by hugin or exiv2) and the
> projection you are using for this lens.
I'm glad my first wish I ever expressed on this ML (which didn't even
receive an answer at the time) seems to be getting closer to
fulfilment:
http://groups.google.com/group/hugin-ptx/browse_thread/thread/cf6bba0d7babb4a5#
I haven't given your code a spin yet, but maybe while you're at it you
could pick up my suggestion to load a specific lens ini file when the
lens model exif tag is present or use default lens ini file if the
relevant exif data are missing. I think it should be fairly
straightforward to include code along the lines of:
- if exif lens type flag is found to be XXX
- then load <lens file path>/XXX.ini
- else if <lens file path>/default.ini exists
- then load <lens file path>/default.ini
- else proceed as ever before (ask the user)
This would help all users who work with fully manual lenses (like
myself, I use a Samyang 8mm which should be fairly common). This is my
only manual lens, and it'd save me the patching of the exif data which
I still would have to perform using the mechanism you've implemented.
The change would be transparent, as it's opt-in, and you wouldn't need
to have a database.
> The lens name can be read inside Hugin (images tab) or you are using
> exiv2 (run "exiv2 -pt image.jpg | grep Lens" and search for lens name
> in the output, depending on the maker a different tag is shown).
>
> So please post the lens names and the projection Hugin should set
> automatic.
intensive, as you have to keep a database somewhere with the lens
model - projection relations. Yet again I propose to use a mechanism
where a lens ini file is looked for in a predefined place which goes
by the name of <lens model>.ini
This way users can put their calibration data in a place where hugin
picks them up automatically. This does require the user to produce or
acquire the ini file rather than relying on an automatism, but it's
the better solution because it is less data-intensive as no database
is required.
If this approach were taken, not only the projection but also the lens
correction parameters the user deems correct would be at hand. Not
drawing these from a database is IMHO more appropriate since even if
lenses are 'the same' they may differ quite a bit from specimen to
specimen, not to mention that they may require quite different
calibration data when mounted on different bodies, even of the same
type, so a value from a database will usually be inferior to a value a
user arrives at by careful calibration of the actual hardware they
use.
In my experience the lens data taken from databases help some, but
they aren't as good as the data I've generated myself by careful
calibration - the values simply differ too much for each individual
case to successfully cover them with a database record. Of course the
mere projection can be derived from a database and will be correct,
but why not ge beyond that and use the simple machanism I propose to
have it all? And my proposed mechanism would also aloow to handle the
absence of the appropriate exif data gracefully. What do you think?
Kay
Brent
easier. It could also use camera serial number as a lookup
parameter, if that's included in the exif data.
One other detail though, is that the 'lens' is really a combination of
a lens and a body. Some of the 'lens' parameters, such as the
photometric scaling, and perhaps the lens shift parameters, are really
a function of the body not the lens. In the longer term view, it may
be appropriate to separate those as different ini files...
Brent
On Oct 25, 3:06 am, kfj <_...@yahoo.com> wrote:
> On 16 Okt., 16:12, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
>
> > Hi all,
>
> > I added code to display the lens in the GUI. It is using the
> > information stored in the EXIF section to identify the lens (via the
> > exiv2 lib). With this information it would be possible to
> > automatically set the correct projection when adding images to Hugin.
> > But to implement this I need more information.
> > I need the lens type/name (as reported by hugin or exiv2) and the
> > projection you are using for this lens.
>
> Hi Thomas!
>
> I'm glad my first wish I ever expressed on this ML (which didn't even
> receive an answer at the time) seems to be getting closer to
> fulfilment:
>
kfj
> Autoloading of .ini files is a great idea -- would make life much
> easier. It could also use camera serial number as a lookup
> parameter, if that's included in the exif data.
good candidate to delegate to a python script. The python interface
can be used from anywhere in hugin, it's not just for plugins. If the
routine looking at the exif values and deciding which ini file to load
was written in python, it'd be easy to modify and adapt to the
behaviour that's wanted, without having to do a recompile. It might
also have a set of behaviour patterns ready and chose from them based
on environment variables or other clues.
> One other detail though, is that the 'lens' is really a combination of
> a lens and a body. Some of the 'lens' parameters, such as the
> photometric scaling, and perhaps the lens shift parameters, are really
> a function of the body not the lens. In the longer term view, it may
> be appropriate to separate those as different ini files...
have a few annoying quirks. I never understood why it is necessary to
have two different ini files for landscape and portrait orientation
with the same lens. If the parameters were always reative to the
sensor, one could use the same. And that the lens shift parameters (d,
e) are given in pixels instead of a float factor around 1.0 - as a, b
and c - is also annoying. I think this is all legacy from the pto
format and changing it would mean breaking compatibility with the
existing format, so there's a great deal of inertia here.
As far as the lens-body combination goes, it seems to be the case that
even with every change of the lens the optical system comes out
slightly different - I was advised on this ML to reoptimize d and e
every time, because they won't come out the same from set to set even
with the same lens-body combination if the lens is taken off and put
on again. I'm not entirely certain if there is really a physical
difference or if the change in the d and e parameters the optimizer
generates may be due to content, rather - but the optimizer sure does
come up with different values each time.
Kay
kfj
> Hi all,
>
> I added code to display the lens in the GUI. It is using the
> information stored in the EXIF section to identify the lens (via the
> exiv2 lib). With this information it would be possible to
> automatically set the correct projection when adding images to Hugin.
> But to implement this I need more information.
>
> I need the lens type/name (as reported by hugin or exiv2) and the
> projection you are using for this lens.
Thomas, I'm manually patching the name of my Samyang fisheye into the
EXIF data, since it's a manual lens and the body knows nothing of it.
When I do that, I can set the Lens Model by assigning
-LensModel="Walimex Pro Fisheye 8mm"
but I cannot find a way of setting the Lens Type. I have the suspicion
that the Lens type is an integral number pertaining only to Canon
Lenses, and whatever string I pass it comes out 0. In exiv2 I get
IMG_3928.tif Exif.CanonCs.LensType Short 1 (0)
IMG_3928.tif Exif.CanonCs.Lens Short 3 9.0 mm
IMG_3928.tif Exif.Canon.LensModel Ascii 24 Walimex Pro
Fisheye 8mm
when I do what you propose:
> The lens name can be read inside Hugin (images tab) or you are using
> exiv2 (run "exiv2 -pt image.jpg | grep Lens" and search for lens name
> in the output, depending on the maker a different tag is shown).
Which tag does your code look up?
In the hugin images tab, I get Lens (0), as if the code was looking at
the Lens Type tag.
> PS: If the lens is not recognized by exiv2 (and therefore by hugin),
> this will not work. In this case it needs to be fixed in exiv2 or the
> lens information is not stored inside the EXIF header, e.g. for some
> manual lenses. This can't be fixed by Hugin.
This is why I patch the lens info with exiftool. I am using this
command:
exiftool -FNumber=8.0 -ApertureValue=8.0 -FocalLength="9.35 mm" -
LensModel="Walimex Pro Fisheye 8mm" -ShortFocal="9.35 mm" -
LongFocal="9.35 mm" -Lens="9.35 mm" -FocusDistanceLower="0.45 mm" -
FocusDistanceUpper="inf" -FocalLengthIn35mmFormat="14.96 mm"
<myimage.CR2>
maybe looking at the Lens Type tag is wrong, and the Lens Model tag,
which actually contains a string, so you can search against it in a
database, is better? Or is this only so with Canon bodies?
And, while I'm at it, I never got an echo on my proposals to autoload
lens.ini files based on the Lens Model EXIF tag. Maybe you didn't look
at my postings concerning the matter, they're in this thread just a
few up from here.
Kay
Tom Sharpless
While we are on the subject of automating lens calibration, it might
be appropriate to think about the shortcomings of the lens model in
libpano, which is unchanged since the 1994 version of PanoTools. 1)
it offers just two model lens curves, rectilinear and equal-angle
spherical; whereas in reality most short focal length lenses, whether
'normal' or 'fisheye', follow some other curve (the existence of the
"Thoby Projection" proves this is a practical issue); 2) the 3-
coefficient polynomial correction, that we rely on to take care of the
differences between the model and actual curves, is ambiguous (many
sets of coefficients can match the same lens) and somewhat unstable
(small changes in control point set can give big changes in the
polynomial); 3) worse, the correction polynomial is specific to the
size and orientation of the image array, so that PT calibrations are
not portable between cameras, or even between different resolution
settings of the same camera, or rotated copies of the same image.
It would not be hard to replace the PT lens model with one that is
free of those defects. That would let us have really useful,
shareable lens databases, and give us the full benefit of work like
Thomas's on automating the identification of lens and camera. It
should be noted that information about sensor dimensions and pixel
array formats remains just as important, but is no longer factored
into the "lens" calibration, so another database of camera
characteristics is an essential part of any solution.
For Panini-Pro, I developed a portable universal lens model, and
supporting lens and camera databases. I've had good experience with it
as a way to manually match my various fish-eye lenses and camera
formats. The lens model has 4 parameters: focal length (as given by
the manufacturer); curve shape, which 'zooms' continuously from
rectilinear through stereographic through equal-angle to equal-area;
and major and minor correction factors, which adjust a 4 term
polynomial, but in a way that does not allow wild deviations from a
realistic model. In addition of course the working lens/camera model
must know the physical and logical (pixel) dimensions of the camera
sensor (to support full camera calibration it also accepts optical
axis offsets and tilts). I haven't yet tried optimizing these
parameters from control points, but I am confident that would be a
stable process, as they simply cannot generate absurd curves.
Would anyone like to work with me on putting this model into libpano13
and setting up Hugin to test it? (Or perhaps calibrate-lens would be a
more suitable test bed). My Hugin build environment (for Windows) is
not up to date and I could use some help updating it. Plus I have
little time to program outside my primary commitment to Panini-Pro.
Merry Christmas and a Happy New Year,
-- Tom
kfj
> I cannot find a way of setting the Lens Type. I have the suspicion
> that the Lens type is an integral number pertaining only to Canon
> Lenses, and whatever string I pass it comes out 0. In exiv2 I get
>
> IMG_3928.tif Exif.CanonCs.LensType Short 1 (0)
> IMG_3928.tif Exif.CanonCs.Lens Short 3 9.0 mm
> IMG_3928.tif Exif.Canon.LensModel Ascii 24 Walimex Pro
> Fisheye 8mm
>
> Which tag does your code look up?
> In the hugin images tab, I get Lens (0), as if the code was looking at
> the Lens Type tag.
I dug a bit deeper and found (what I think is) the relevant section in
SrcPanoImage.cpp, line 371 ff.:
Exiv2::ExifData::const_iterator itr2 = Exiv2::lensName(exifData);
if (itr2!=exifData.end())
{
//we are using prettyPrint function to get string of lens name
//it2->toString returns for many cameras only an ID number
setExifLens(itr2->print(&exifData));
}
The code calls a convenience function from libexiv2, which "Provides
easy (high-level) access to some Exif meta data." The function is
defined in libexiv2's easyaccess.hpp:
//! Return the name of the lens used
EXIV2API ExifData::const_iterator lensName(const ExifData& ed);
This sounds just like the ticket and anyone would expect that it
should deliver a useful string, and not the silly (0) it does in the
case of my Canon with a manual lens. I found no easy access function
for the tag I think should be read, and I suppose libexiv2 is to
'blame' for the unexpected result. It may be possible to use a less
easy-access method to access the LensModel tag instead of the LensType
tag, but I haven't looked further than this, and I'm not sure if the
issue is the same with non-Canon bodies. Is there anyone else around
using manual lenses which the camera body has no idea of? What does
show up on your image tab's lens field - or have you never patched in
your lens' parameters, since there was no obvious immediate benefit?
Kay
T. Modes
some details how the lens is saved.
AFAIK the most cameras save the lens in the maker notes. There are
mainly 2 variants:
1) Saving the lens as a (coded) number (e.g. used by Nikon, Olympus)
2) Saving the lens as string (e.g. Panasonic)
For Canon there exists both variants:
* tag LensModel (0x0095): a string
* tag LensType (id depends on camera type): a number (int16s)
I assume that all newer Canon camera are using the LensType tag. The
string variant seems to be an older, now not used tag (Just guessing,
I have no Canon).
Saving the lens name as string would only work for the camera with
store the lens as string (item 2 above).
But I came to another solution:
EXIF specification version 2.3 introduced the tags Lens Specification,
Lens Make, Lens Model and Lens Serial Number.
The tag LensModel is a string and can therefore used for images of all
makers (don't mix this with the tag with same name in the Canon
makernotes).
Maybe some newer camera (compatible with exif version 2.3) do already
write this tag.
I modified the code to read first this new tag, if this is not found
then it should use the lens from the maker notes.
So you can use
exiftool -LensModel=YOUR LENS NAME image
to patch the image file.
Maybe it would be nice to update also Exif version, because the
LensModel is only defined in 2.3 and above (not 2.2), so use
exiftool -LensModel=YOUR LENS NAME -exifversion=0230 image
(For Canon it could be necessary to use -Exif:LensModel for forcing
the exif tag and not update the maker note tag).
> And, while I'm at it, I never got an echo on my proposals to autoload
> lens.ini files based on the Lens Model EXIF tag. Maybe you didn't look
> at my postings concerning the matter, they're in this thread just a
> few up from here.
I did not forget this, but this is postponed after the integration of
the lensfun library.
Thomas
JM
As someone who has stitched many thousands of panos using libpano, I'm well aware of the shortcomings that Tom describes both in terms of user frustration, and in terms of getting more globally useful standards which can be shared between people.
Jeffrey
kfj
> Hi Kay,
>
> some details how the lens is saved.
> AFAIK the most cameras save the lens in the maker notes. There are
> mainly 2 variants:
> 1) Saving the lens as a (coded) number (e.g. used by Nikon, Olympus)
> 2) Saving the lens as string (e.g. Panasonic)
>
> For Canon there exists both variants:
> * tag LensModel (0x0095): a string
> * tag LensType (id depends on camera type): a number (int16s)
> I assume that all newer Canon camera are using the LensType tag. The
> string variant seems to be an older, now not used tag (Just guessing,
> I have no Canon).
I have also looked into the matter a bit. I have come to the
conclusion that, at least in case of my Canon, LensType is a short
integer and codes for all different types of Canon lenses. Mind you,
Canon lenses. There are no numbers for other Lenses, and the various
exif-processing tools seem to have lists of which Canon lens number
should yield which string. I suppose I could have a Carl Zeiss lens
and there wouldn't be a number for it - let alone my Samyang fisheye.
I can write to the tag (with exiftool I can even write to the raw
file) but nothing will ever make a string from that tag that fits my
lens, unless I've overlooked something silly.
> Saving the lens name as string would only work for the camera with
> store the lens as string (item 2 above).
>
> But I came to another solution:
> EXIF specification version 2.3 introduced the tags Lens Specification,
> Lens Make, Lens Model and Lens Serial Number.
> The tag LensModel is a string and can therefore used for images of all
> makers (don't mix this with the tag with same name in the Canon
> makernotes).
> Maybe some newer camera (compatible with exif version 2.3) do already
> write this tag.
My Canon EOS 450D body does that. It writes the Canon-specific number
to it's Lens Type tag and the corresponding lens name string to the
Lens Model Text. That's where I got the idea to put my lens' name in
there, since the other tag wouldn't let me assign a useful value to
it. After all I was working towards a way to have a tag in the EXIF
data that would allow automatic loading of a lens.ini file, so I had
to find a way. Lens Type wouldn't play, so I took Lens Model. I wasn't
aware this was something new!
> I modified the code to read first this new tag, if this is not found
> then it should use the lens from the maker notes.
Brilliant! This sould make my life a bit simpler - and hopefully not
just mine. After all the Samyang fisheye isn't the only non-Canon lens
around. I'll pull the new code asap. Do you need data for the Samyang
8mm fisheye?
> So you can use
> exiftool -LensModel=YOUR LENS NAME image
> to patch the image file.
The ticket.
> Maybe it would be nice to update also Exif version, because the
> LensModel is only defined in 2.3 and above (not 2.2), so use
> exiftool -LensModel=YOUR LENS NAME -exifversion=0230 image
really? to me this looks as if it might have been around earlier
$ exiftool -exifversion -LensType -LensModel IMG_3929.tif
Exif Version : 0221
Lens Type : Unknown (0)
Lens Model : Walimex Pro Fisheye 8mm
> (For Canon it could be necessary to use -Exif:LensModel for forcing
> the exif tag and not update the maker note tag).
the tag is writable just fine with exiftool, and exiv2 does at least
know how to read it (it can't write CR2)
> > And, while I'm at it, I never got an echo on my proposals to autoload
> > lens.ini files based on the Lens Model EXIF tag. Maybe you didn't look
> > at my postings concerning the matter, they're in this thread just a
> > few up from here.
>
> I did not forget this, but this is postponed after the integration of
> the lensfun library.
I'm glad to hear that. I think recognizing lens types on image load is
a great help, and reading whole lens.ini files could be potentially
even more helpful.
Kay
kfj
> makers (don't mix this with the tag with same name in the Canon
> makernotes).
> Maybe some newer camera (compatible with exif version 2.3) do already
> write this tag.
> I modified the code to read first this new tag, if this is not found
> then it should use the lens from the maker notes.
>
> So you can use
> exiftool -LensModel=YOUR LENS NAME image
> to patch the image file.
open a project or try to load an image. Console output tells me that:
terminate called after throwing an instance of
'Exiv2::BasicError<char>'
what(): Ungültiger Feldname oder IFD-ID `LensModel', IFD-ID 5
Abgebrochen
This is correct. There is no such tag. In SrcPanoImage.cpp I found (in
line 375):
if(getExiv2Value(exifData,"Exif.Photo.LensModel",lensName))
...
the tag which should be read, in my case, is Exif.Canon.LensModel, and
when I modify the code to
if(getExiv2Value(exifData,"Exif.Canon.LensModel",lensName))
...
it works fine for me and the lens name I've patched into the EXIF data
shows correctly. But that is me, using a Canon Camera. Nevertheless, I
suppose that the important bit is that "Exif.Canon.LensModel" a valid
tag identifier string recognized by exiv2, and if the image isn't done
with a Canon camera, I suppose it'll just not find any value for it.
Maybe there are analogous tags in the maker-specific parts for other
manufacturers? Omitting the prefixes, i.e. only look for "LensModel"
instead of the fully qualified string, doesn't work (crashes as well).
Is the Samyang 8mm already in the database? And if so, what is the
string used to identify it?
Kay
T. Modes
> Thomas, the new code doesn't work for me. Hugin crashes as soon as I
> open a project or try to load an image. Console output tells me that:
>
> terminate called after throwing an instance of
> 'Exiv2::BasicError<char>'
> what(): Ungültiger Feldname oder IFD-ID `LensModel', IFD-ID 5
> Abgebrochen
>
> This is correct. There is no such tag. In SrcPanoImage.cpp I found (in
> line 375):
current version 0.22.
I committed a patch for exiv2 versions prior to 0.22
> the tag which should be read, in my case, is Exif.Canon.LensModel, and
> when I modify the code to
>
> if(getExiv2Value(exifData,"Exif.Canon.LensModel",lensName))
> ...
>
> it works fine for me and the lens name I've patched into the EXIF data
> shows correctly. But that is me, using a Canon Camera. Nevertheless, I
> suppose that the important bit is that "Exif.Canon.LensModel" a valid
> tag identifier string recognized by exiv2, and if the image isn't done
> with a Canon camera, I suppose it'll just not find any value for it.
> Maybe there are analogous tags in the maker-specific parts for other
> manufacturers? Omitting the prefixes, i.e. only look for "LensModel"
> instead of the fully qualified string, doesn't work (crashes as well).
The handling of the different makernote variants should be handled by
exiv2 and not by Hugin.
So Hugin is now using the general tag Lens Model (tag id 0xa434) - in
the general Exif header, available only with Exif 2.3 (Exif 2.2 is
missing this tag, if you don't trust, read the spec. Software which is
2.3 aware can read this tag, even if the exif version in the file
states a version prior to 2.3 (e.g. 2.21 in your case) - but there
could be programs, which check the exifversion in the file and read
only the tags which are available in this version -> so my comment
about updating also the exif version tag.).
This approach can be used for images of all manufacturers in the same
tag/tag id.
The tag Lens Model (tag id 0x0095, or Exif.Canon.LensModel) is
specific to Canon cameras and would only be necessary for manual
lenses (the other lenses are automatically identified by exiv2 by the
numeric tag Exif.CanonCs.LensType). Using Exif.Canon.LensModel would
be too specific. And it would require further patches for cameras of
other manufacturers.
Thomas
kfj
> > Thomas, the new code doesn't work for me. Hugin crashes
> That's only partially correct. Your exiv2 is too old. It is defined in
> current version 0.22.
> I committed a patch for exiv2 versions prior to 0.22
the latest source now.
> Have you read my mail? And have you understood it?
> The handling of the different makernote variants should be handled by
> exiv2 and not by Hugin.
because it's better now with the check for the exiv2 version in the
code, rather than simply crashing.
> So Hugin is now using the general tag Lens Model (tag id 0xa434) - in
> the general Exif header, available only with Exif 2.3 (Exif 2.2 is
> missing this tag, if you don't trust, read the spec.
> Software which is
> 2.3 aware can read this tag, even if the exif version in the file
> states a version prior to 2.3 (e.g. 2.21 in your case) - but there
> could be programs, which check the exifversion in the file and read
> only the tags which are available in this version -> so my comment
> about updating also the exif version tag.).
> This approach can be used for images of all manufacturers in the same
> tag/tag id.
> The tag Lens Model (tag id 0x0095, or Exif.Canon.LensModel) is
> specific to Canon cameras and would only be necessary for manual
> lenses (the other lenses are automatically identified by exiv2 by the
> numeric tag Exif.CanonCs.LensType). Using Exif.Canon.LensModel would
> be too specific. And it would require further patches for cameras of
> other manufacturers.
With your patch and the latest exiv2 built from source I'm now up and
running. During the compilation I got warnings along the lines of
/usr/bin/ld: warning: libexiv2.so.10, needed by ../../hugin_base/
libhuginbase.so.0.0, may conflict with libexiv2.so.11
but so far I've not noticed any ill effects. Thanks for your help.
You haven't mentioned it, so I ask again:
Is the Samyang 8mm stereographic fisheye already in the database? And
T. Modes
> Is the Samyang 8mm stereographic fisheye already in the database? And
> if so, what is the
> string used to identify it?
Thomas
kfj
"Samyang 8 mm f/3.5 Aspherical IF MC Fish-eye"
"Walimex Pro Fisheye 8/3.5"
see http://www.lenstip.com/160.11-Lens_review-Samyang_8_mm_f_3.5_Aspherical_IF_MC_Fish-eye_Summary.html
AFAIKT these are both the same lens, I bought mine as Walimex from
Amazon in Germany. If you think the strings are too long, feel free to
propose shorter versions - after all, since the lens name has to be
patched into the EXIF data we're free to choose whatever we want ;-)
I use the lens with projection set to stereographic, which seems to
fit fairly well. Is this all you need, or would you like lens
correction coefficients as well?
Kay
Tom Sharpless
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. And though the EXIF always identifies the camera, more
often than not it doesn't specify the sensor dimensions (among the
majors, only Canon consistently does this -- but it is not always
right for alternative image formats such as video).
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.
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. 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.
HAPPY NEW YEAR
--Tom
On Dec 23, 11:18 am, kfj <_...@yahoo.com> wrote:
> On 23 Dez., 14:25, "T. Modes" <Thomas.Mo...@gmx.de> wrote:
>
> > > Is the Samyang 8mm stereographic fisheye already in the database? And
> > > if so, what is the
> > > string used to identify it?
>
> > No. Currently there are only 2 fisheye lenses in the database.
>
> Okay. Make it two more then:
>
> "Samyang 8 mm f/3.5 Aspherical IF MC Fish-eye"
> "Walimex Pro Fisheye 8/3.5"
>
kfj
> 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.
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.
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.
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.
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