On Wed 27-May-2009 at 08:27 -0700, Tom Sharpless wrote: > >I generally stitch multiple exposure sequences with PTGui, as that >gives me what seems an intelligible choice: either share CPs across >exposures or align each image with independent CPs; while I can't make >head or tail of the options in Hugin. I think the Hugin UI needs some >serious work in this area, so everyone can have a nice tool like >ImageFuser.
>Are you fully satisfied with align_image_stack? I have noticed some >complaints as well as much praise in the lists. Not being a user of >it myself, but interested in image alignment problems as a developer, >I wonder if you or others could suggest what are its main >limitations? As far as I'm concerned this is largely a solved problem. hugin doesn't yet have the ability to hard-link the positions of photos in a stack, but align_image_stack does a good job of doing this linking with control points - With the added advantage of dealing with slight misalignments, up to and including my sloppy hand-held bracketing. The disadvantage is that align_image_stack takes some amount of time and that the control-points it generates slow down the optimiser. However, there is probably an order-of-magnitude speed increase available in the hugin workflow, but I'm sure it isn't here. Otherwise there are two important hugin options that we don't yet have that will be relatively simple to add with some extra Makefile rules: 1. enfusing stacks as the first step before remapping with nona. 2. enfusing exposure layers as the last step after blending with enfuse. For (1) to work sensibly, it should only happen when the photos are known to be exactly aligned, James is working on a GUI and backend to allow specifying and optimising this (or rather unspecifying, as stacks are easy to detect by looking at EXIF data, the distinction is whether or not they are exact stacks or not). >I imagine a fine-aligner using correlation (as opposed to control >points) might be a helpful addition to align_image_stack. Or does >it already do that? align_image_stack uses the same pixel correlation as the hugin fine-tune, which is why it is much faster than a control point matcher. Have you tried match-n-shift where all this is implemented? Though James has convinced me that most of this logic should be in hugin itself rather than in a separate control-point generator. -- Bruno --~--~---------~--~----~------------~-------~--~----~ 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
