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.
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 <[email protected]> wrote: > On 16 Okt., 16:12, "T. Modes" <[email protected]> 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: > > http://groups.google.com/group/hugin-ptx/browse_thread/thread/cf6bba0... > > 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. > > I think your approach goes along the lensfun road, which is data- > 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 -- 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
