>On 22 Sep., 23:22, Bruno Postle <[email protected]> wrote: > The 'any arrangement' mode doesn't assemble stacks, it blends each > exposure level into a separate layer, then fuses them together as a > final step - i.e. it is suitable when you have shot at different > exposures, want to exposure fuse them, but don't necessarily have > a series of 'stacks'.
Thanks for pointing that out. I never used this one much, so I got confused about what precisely it does. > On Thu 22-Sep-2011 at 23:40 -0700, kfj wrote: > >The current behaviour is misleading, since a user who has assigned > >stacks will expect that an 'exposure fusion from stacks' will in > >fact fuse these stacks, and not some stacks the program makes up > >itself. > Hugin will fuse these stacks that have been manually assigned. The > problem is that it gives no indication what it is doing, and then > people assume it is doing something else altogether... So you say, but what if (just hypothetically) a manually composed stack were to contain images which don't overlap by 70%? And don't tell me that this is 'incredibly corner-case'. Good software design tries to encompass all eventualities and not just the standard situations. 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. What it doesn't indicate is that it isn't even looking at the stacks you've assigned in the project and it's just doing it's own 70% thing. I couldn't figure out why on earth it was doing what it was doing until you told me why. > 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. Often an innovator can't see all consequences of the innovation, and feedback can help bring the innovation to a state where everyone is happy with it. That nobody is complaining about something is no good indication for something being as it should be either. In fact, if I made bug reports from every glitch I find in hugin I'd spend a good deal of my time doing so. Most of the time I'm just too busy to bother, or I'm so used to it that my workflow already takes it into account and works around it. I was hoping that my criticism was constructive, since it showed that there was a problem using the software as-is. Your comment makes out as if I was just nagging and my contribution was pointless: > I think your incredibly corner-case example (shooting bracketed at > two different resolutions) ... This is where my problem became apparent, but it isn't quite as corner- case as you make it seem. When I do standard 360X180 panoramas with a single (stereographic fisheye) lens (with stacks), I tilt the lens up some for the sky, and then I do two shots down with opposite yaw which have the nadir plus a bit at the bottom - all of this in portrait. I deliberately don't point the zenith shot straight into the sky or the nadir shots straight to the ground, so as to have enough overlap with the six shots around I do. While this should be a pretty common procedure, it puts the zenith and nadir shots within the range of the 70 percent automatism, resulting in the zenith or nadir images (which, in my case, aren't necessary best-matched with the rest, shooting freehand) being automatically fused with the one or the other of the six unpitched images. Again, I can work around the problem by masking bits, but the process would be much more straightforward if I could have hugin blend merely the stacks I've assigned - or set the automatism to a different number, say 90%, in the preferences. Without masking the output is wrong, there's no two ways about it. 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 ;-) Then I can make a version for myself with the figure adapted to my needs. 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
