On 17 Mrz., 21:36, Bruno Postle <br...@postle.net> wrote: > My questions are what is it for? and who is it for?
I am currently thinking of open source RAW converters mainly, but a command line tool for batch processing should have its uses as well. If Hugin can profit from lens data DB lookups, all the better, but compared to the effort of setting up a proper stitching project, manually loading lens data is not *that* big of a deal. Apart from that, distortion data can be determined automatically by Hugin in many cases anyway. > Who uses PTLens? barrel distortion in single-shot photos never > bothered me enough to want to correct it - Rather when I do want to > give a photo this much attention I'm as likely to want to recenter > and rotate it at the same time - Something that Hugin is well suited > for. Correct. However, considering modern 'hybrid' cameras (Micro Four Thirds, Samsung NX etc.) with ultra-compact lens constructions, distortion in raw images once again becomes a serious problem, e.g.: http://www.dpreview.com/reviews/olympusep1/page22.asp The commercial raw converters partially license the algorithms used by the camera manufacturers to replicate in-camera correction, but that is not always optimal (and the free projects --RawTherapee, Rawstudio, UFRaw etc.-- do not even have that option). > A lens database would be useful within a RAW converter, since the > converter is resampling the photo it makes sense to fix tca and > distortion at the same time - i.e. a database that RAW converters > can use transparently to improve results would be a good thing. Exactly (see above). > You could describe Hugin as primarily a tool that understands the > differences between a photo and the reality it represents - Being > able to stitch panoramas is a convenient result of that > understanding. So it is funny that Hugin doesn't have any > preconceived knowledge of real lenses and cameras, it generally has > to figure all this stuff out every time it runs - But we get by ok. > > Having said that, Hugin would be better if it knew all the image > parameters upon loading a photo, not least because it could use this > to improve control point detection. As I said, if my idea proves to be workable and Hugin can be adapted to make use of it, all the better. But ironically Hugin is the only software at the moment that can be used to _determine_ correction parameters-- maybe exactly because it does not assume anything about the physics of a photograph. > This is the real problem that lensfun faced, who is going to > maintain this database? Somebody has to accept and validate > contributions and this is a _lot_ of tedious work. The problem that lensfun faces is that it is neither easy nor straightforward to create your own datasets. If it is easy enough, quite a lot of people will probably even be happy to calibrate their lenses themselves (provided they do only have to do it *once*). Concerning validation: if I get data from someone concerning a lens to include it in the database, I cannot validate it without having the lens and/or several test shots (and it takes a lot of time, of course). So I can only trust user contributions, but I do not see this as a real problem. If a correction model is wrong, sooner or later there will be a bug report on it. The crucial point is the existence of proper DB maintenance tools. > This isn't as crazy as it sounds, the panotools a,b,c lens > parameters can't simply be averaged, but it seems that the lens > model that Tom Sharpless developed for calibrate_lens is suitable. I was unaware that calibrate_lens implements a new correction model as well. I will have a look, not least because Photoropter will have to 'learn' about it... > i.e. collect a lot of data and build the database statistically with > a minimum of human input, the shipped database would then represent > the cameras and lenses in use in the real world rather than those > with owners who can be bothered to contribute. I do not think that this will work. First of all, a *lot* of people distrust software sending 'feedback' or the like to some servers without intervention. Second, identifying a lens is not trivial and very often requires at least some minimal amount of user input. Not to mention adapted lenses (no EXIF data at all) and 'new' lenses that are not yet present in the database. You might end up with an ugly mess instead of a usable database. Regards, Robert -- 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
