Kay, Just a suggestion. Make two pto files. One with 8mm and one with 18mm. Now merge these pto using hugin merge project and than stitch. I once forgot to capture sky in my 18mm but i added sky from another panorama this way and hugin blended it well.
But you are right stack working in hugin must be improved. Hugin should also detect bracketing/stack from exif. One more thing for handheld panoramas there must be option to enfuse_allign option for stacks. On Fri, Sep 23, 2011 at 11:40 AM, kfj <[email protected]> wrote: > On 22 Sep., 23:22, Bruno Postle <[email protected]> wrote: > > > As I understand it, Hugin only uses the stack numbers for linking > > positions during optimisation. > > I am not using the stacks to position the images - I uncheck the > positional link. What I use them for (apart from the obvious, which > doesn't work) is to set the CPG on the right track. I use cpfind for > both detectors in the 'stacked panorama' scenario. This way, I only > get CPs to images in another stack via the middle exposures, and the > CPs to fine-adjust the stacks inside the image, but no interstack CPs > for the other exposures. > > > However stitching ignores these stack numbers. With 'exposure > > fusion' enabled it just looks at which photos overlap at least 70% > > (by area) to determine which to fuse as stacks before blending. > > This, then, is the source of my problem > > > This does mean that small photos that overlap with large photos may > > get fused even if you would prefer them to be blended. > > Thanks for your analysis. I now managed to circumvent the problem by > stitching first the 8mm exposures and then the 18mm ones to finally > blend the two subpanoramas into one. This is a cumbersome process, > though, and it would be much easier if the stitching process could > honour stacks if they are present and only do it's undocumented > hardcoded 70% trick when run in the 'exposure fusion from stacks from > arbitrary arrangement' mode. 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. In fact, the 'direct' route should > be simpler - the stacks are already set up, so there's no need to do > any trickery to make them up from thin air. > > > Hugin currently doesn't give any indication of these calculations in > > the GUI, you have to stitch to find out what will happen. It would > > be nice to show it somehow in the Preview, or just list the stacks > > in the Stitcher tab, or maybe a python plugin could list them. > > I was working on stacks with an hsi/hpi plugin. The first plugin I > wrote was one to automatically assign stacks of three images to a all > images in a project - usually my brackets are of three images, and the > plugin (which works fine) helps me often :) > > The problem with it is twofold: firstly, the 'three images' shouldn't > be hardcoded. I can use wxPython on my system to let it ask for the > desired number, but passing parameters to hsi/hpi plugins has not been > implemented for other platforms, even though it's the single most > urgent feature lacking to help hsi/hpi to become a useful tool. > > Secondly, I tried to penetrate the logic which is used inside hugin to > assign/change/revoke stack numbers. In particular I failed to cleanly > implement behaviour like unstacking of all images and restacking with > a different images-per-stack number, not to mention assigning a > different scheme to a subset of images. As obvious as the stacking is > inside the pto file, as obscure is the handling inside the C++ code. I > couldn't fathom it, so I asked for help here: > > > http://groups.google.com/group/hugin-ptx/browse_thread/thread/2bb6f69866c56ad5# > > as you can see, noone answered my question. Since this was all the > help I got I kept my plugin to myself. Every user who posts a 'hugin > cannot stitch my holiday snaps' message tends to get at least an > answer pointing them to the documentation, so I was pissed off by this > non-echo, even after asking a second time. > > I think there should be a button in hugin saying 'autodetect stacks' > which triggers the 70% trick and reflects it by assigning the > autodetected stacks to the images. the 'exposure fusion from stacks' > should use the extant stacks, if present, and if not present it might > ask if it should try to autodetect or plain abort. And the 'exposure > fusion from arbitrary arrangement' should autodetect stacks if no > stacks are present and might complain if stacks have been previously > assigned and conflict with it's autoamtically generated ones. > > 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 > -- *Emaad* www.flickr.com/emaad -- 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
