I tend to agree that the notion of a stack should cover both the control-point generation algorithm and the enfuse or HDR process. It's unclear to me why one would want to do these two stages with a different stacking arrangement. But even if they have an edge-case reason to do so, they could assign one stacking, run cpfind, then change the stacking before running enfuse.
In addition, the auto-detect idea would simplify the interactions with the program -- as it is now, stacks have to be manually assigned. By using an auto detect feature the creation of stacks is simplified and the choice later during enfuse is more transparent. I was noticing just today that that's a pain to keep doing, (especially since it also links the image yaw,roll,pitch when images are stacked and that has to be undone manually). I also think 90% is a more likely threshold. BTW, note that overlap is not symmetric when the images are unequal size; A may overlap B by 90% but B may not overlap A by 90%! The larger overlap direction should also control the order of the files when align_image_stack is called so that it can more efficiently find grid points for alignment. Brent On Sep 26, 9:55 am, kfj <[email protected]> wrote: > On 26 Sep., 01:02, Bruno Postle <[email protected]> wrote: > > > On Sat 24-Sep-2011 at 00:41 -0700, kfj wrote: > > > >Hugin gives a clear indication of what it's doing, you just have to > > >watch the stitcher's output to see that it's putting together stacks > > >with sets of images which you haven't specified. > > > This output is useful, but it is not suitable for a GUI tool. It > > isn't acceptable to have to watch the entire stitching stage just to > > figure out how Hugin is handling bracketed stacks and exposure > > layers. > > I agree. There is no other indication of what's happening (apart from > the output image, of course). > > > >> Actually the automatic detection of overlap for stacks works very > > >> well, it was relatively recently implemented and replaced a much > > >> cruder overlap test (which nobody ever complained about either). > > > >I did not say that the overlap detection was in any way flawed. My > > >criticism is with the use of the detected overlap. And that something > > >works well is no reason it can't be improved. > > > The first step here is for the tool to tell you what it is doing, it > > is pointless having extra switches and levers if there is no > > feedback to tell you what they do - This would be a real disservice > > to users, making the software actually worse. Hugin already has too > > many options that are completely opaque. > > I'd make 'autodetect stacks' a menu entry. After autodetection, a > message box can inform the user of the autodetection's result. If the > autodetection's result is reflected in the assigned stack numbers in > the images tab, the user can assess whether the automatism succeeded > and modify the stack assignment, if need be - and it would be also > possible to undo it. This is one menu entry - if it's not a button (of > which I feel there are too many) I'd not consider it clutter. > > At the same time it would reduce the concept of stacks to one: stacks > which can be manually set or autodetected, with visibitlity of the > effect in the images tab, rather than having two concepts - the one > named 'stacks' in the UI which the user can interface with but have no > effect except in CP detection and the 'secret stacks' from the 70% > automatism which aren't shown or modifiable, but are the ones that are > actually used for exposure fusion. > > > (A solution might be to do something different if stack numbers have > > been manually assigned, but this still needs some way of showing the > > user what is happening) > > I think this would be the most logical way to proceed: > > - If no stacks are defined (or, in hugin's notion, if every image is > in it's own stack), and 'exposure fusion from stacks' is chosen, hugin > should refuse to proceed and display a message along the lines of 'no > stacks defined - to fuse stacks, please assign the images to stacks or > use the 'autodetect stacks' command'. > > - If stacks are already defined, no matter by what mechanism, the > 'exposure fusion from stacks' could just go ahead without further ado. > > > When the overlap threshold was first implemented (there is a similar > > hard-coded EV threshold to establish exposure layers), we discussed > > making it an option, but noboby ever asked for it - and it wasn't > > implemented because Hugin needs to move in the direction of just > > doing the right thing rather than adding GUI clutter every time a > > new feature is added. > > > >Since you know of the automatism, would you be so kind as to point me > > >to the location in the code where the 70 percent is specified? I've > > >searched for files with 70, but there are quite a few (I hope they > > >aren't hardcoding other bits I'll later stumble upon ;-) > > > There are _lots_ of hard-coded bits. This is the '0.7' in > > getHDRStacks() in > > src/hugin_base/algorithms/panorama_makefile/PanoramaMakefilelibExport.cpp > > Thanks. I've put the threshold up to 90% here and that works for my > 360X180 from just the fisheye shots. > > Changing the threshold does not help with my initial problem with > images from different lenses. I feel that if one image is totally > within another one (or by 70% inside the other one) but the image > sizes differ by 300%, this should not be considered a match, since the > maximum overlap as seen when the other image is taken first can't be > more then 30%. The detection should at least be symmetric. > > 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
