On August 17, 2010 04:15:35 am rok senk wrote: > > I think Yuv hit is on the head, Hugin is not a load and use program, > > rather one designed for techs and coders rather than casual > > panographers. > > I see this problem differently.
me too. Hugin is designed for the *discerning panographer*. Knowing your focal length multiplier is not a tech or coders issue, it's a panographer issue (as in: know your gear). It is a code issue only in as far as the software sets hard coded default values that are wrong in many cases. A more elegant solution would be for these default values to be preferences; and for the software to ask the user to enter them on the first interaction. > Before recently i had to insert value for focal length multiplier > manually. Now hugin simply assumes it is 1. It took me a while to find > this. > > in my eyes this is a bug, a regression. +1. I am not sure yet how it happened, why, and how to fix it, but it starts itching me. What camera are you using? EXIF support is not overall the same, although if EXIF is not available, the software should ask, not randomly guess. But first, I stand corrected: I experienced two errors combined. One was bad EXIF data in my input images (my bad). The regression compounded it. Because I am a discerning enough panographer (although I qualify as "casual" nowadays - have not had much time for pano shooting/stitching in more than a year) it was easy for me to work around this annoyance. But it should not happen in the first place. This regression is similar to what I perceived as a regression a few years ago with the setting of default lens type. Over time I learned to live with the quirk, but I admit that I prefer an empty field to be filled by the user than a wrongly pre-filled field. It is a design problem. Currently Hugin takes input for granted, especially default input. It should not. We need less assumptions and more / smarter ways to validate guesses. For this, the process needs to be broken down into more steps than just detect control points across the board, optimize across the board, stitch. Some sort of control point detection should be run before even considering type of lens, focal distance, crop factor, to validate such inputs / defaults. At the detection level detect first for time-adjacent pictures rather than blindly across the board. This will yield more information to make better estimates: - if there are groups of disconnected pictures, it is likely to be a multi-row project with "carriage return" between rows (but it could also be multiple set of unrelated panoramas) - if the sequence is all connected, it is likely to be either a single-row project or a "snake pattern" multi-row - of course there is still the possibility of garbage-in (read: shooting all over the place with a logic that is not understandable to Hugin at this point, such as following a bird flying around the sphere. Garbage is not meant in a negative way in this context). This kind of provisional detection can enrich/improve the guesses made based on other information available such as number of pictures loaded, time stamps (preferably from EXIF, fall-back from the filesystem), file names (alphabetic sorting), etc. - as well as blind defaults. Same thing with the optimizer: an "auto" mode should not just make a single optimization run, but rather a multi-staged approach: first optimize for positions only. Then check if the images at one end overlap images at the other end. If they do, validate by detecting control points between the border-left and border-right images. If there are no CP detected, this is most likely a partial panorama with wrong field of view / crop factor. If they do overlap, add these newly detected CPs for the next optimization run. And so on. Yuv
signature.asc
Description: This is a digitally signed message part.
