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
