[hugin-ptx] Re: Fusing before or after
Hello, There are cases when one photographs hand-held and the different exposures are not aligned well enough to be fused first. Best Regards, - Gerry On Fri, May 22, 2009 at 7:50 PM, DaveN wrote: > > I don't know if this has been asked before (hard question to ask in a > search) but why don't people fuse their images before making > panoramas? By that I mean the software for making panoramas (the > hugin clone ptgui and autopano pro) seem to remap all the images to > create differently exposed panoramas and then blend the panoramas. > Wouldn't it be more efficient to exposure fuse the images and then > make the panorama? > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi Dave, I fuse first. The reason is that, in my case, each set of eight images is taken with exactly the same settings (using manual mode). The other advantage is that selecting control points for the fused images is easy as all of the image is visible. Peter. From: DaveN Subject: [hugin-ptx] Fusing before or after Date: Fri, 22 May 2009 17:50:04 -0700 (PDT) > > I don't know if this has been asked before (hard question to ask in a > search) but why don't people fuse their images before making > panoramas? By that I mean the software for making panoramas (the > hugin clone ptgui and autopano pro) seem to remap all the images to > create differently exposed panoramas and then blend the panoramas. > Wouldn't it be more efficient to exposure fuse the images and then > make the panorama? > > > > __ > This email has been scanned by Netintelligence > http://www.netintelligence.com/email > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi Dave, I also fuse first (but maybe I'm a bit biased being the writer of the ImageFuser tool). The reason I do this is that Hugin has sometimes difficulties in finding CP's between the very dark and light images in such bracketed sets. It is sometimes also hard to do that by hand. In that case prefusing the helps a lot. As an addition to what Gerry said about hand-held images: You can use align_image_stack to perfectly align your bracketed photos before fusing them. The better fusing gui's come with align_image_stack and do support that. Harry 2009/5/23 Peter Gawthrop > > Hi Dave, > > I fuse first. The reason is that, in my case, each set of eight > images is taken with exactly the same settings (using manual > mode). The other advantage is that selecting control points for the > fused images is easy as all of the image is visible. > > Peter. > > > From: DaveN > Subject: [hugin-ptx] Fusing before or after > Date: Fri, 22 May 2009 17:50:04 -0700 (PDT) > > > > > I don't know if this has been asked before (hard question to ask in a > > search) but why don't people fuse their images before making > > panoramas? By that I mean the software for making panoramas (the > > hugin clone ptgui and autopano pro) seem to remap all the images to > > create differently exposed panoramas and then blend the panoramas. > > Wouldn't it be more efficient to exposure fuse the images and then > > make the panorama? > > > > > > > __ > > This email has been scanned by Netintelligence > > http://www.netintelligence.com/email > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi Gerry, I can see the logic of 'post processing' fusion for hand held images but that assumes each exposure set is aligned in itself and then the exposures are aligned which I don't think the programs do. Don't they align one image set and then apply the same settings to each exposure set? I nearly always shoot using a tripod and in that case a tool like Kekus' Xfuse works out great with its batch processing option. I haven't done any exposure fused panoramas yet though. Dave On May 22, 7:00 pm, Gerry Patterson wrote: > Hello, > > There are cases when one photographs hand-held and the different exposures > are not aligned well enough to be fused first. > > Best Regards, > > - Gerry > > On Fri, May 22, 2009 at 7:50 PM, DaveN wrote: > > > I don't know if this has been asked before (hard question to ask in a > > search) but why don't people fuse their images before making > > panoramas? By that I mean the software for making panoramas (the > > hugin clone ptgui and autopano pro) seem to remap all the images to > > create differently exposed panoramas and then blend the panoramas. > > Wouldn't it be more efficient to exposure fuse the images and then > > make the panorama? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Harry van der Wolf wrote: > I also fuse first +1 most of the time, but not all the time. > As an addition to what Gerry said about hand-held images: You can use > align_image_stack to perfectly align your bracketed photos before fusing > them. The better fusing gui's come with align_image_stack and do support > that. my wish is to eventually have a "composing GUI" to deal with the "sequence of images" - whatever that sequence is. constrains and actions are boxes of different sizes, that the user can drag and drop on the working surface; and that smart logic can auto-create. actions are things like: - determine CP - add masks - blend / fuse - optimize position in space - manual edit of individual parameters - remap - forks (to have mutliple processing, e.g. for different outputs from the same project) constraints are things like: - defining which images belong to a bracket and what type of bracket it is - which images share the same set of parameters - areas/mask of an image not to be considered for CP generation - areas/mask fo an image that *must* be preserved or *must* be hidden a GUI to move around and connect the boxes with a little bit of logic to make sense of the connections (e.g. don't blend a single image or don't enfuse images with same EV) sort of like a syntax checker before a controller engine starts the different tools in the appropriate order and with the appropriate parameters. Ideally the interface between the GUI and the controller engine would be an XML file, although if the GUI understands the Makefile format it could create a Makefile directly, but that would make the Makefile part of the project and I am not sure how it will affect the projects in terms of portability to a different box? rather go safe, describe it in an XML and have an XML to MakeFile thing... Yuv --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi all, I hope I didn't give anyone the wrong idea. I almost always shoot bracketed sets with a tripod. As such, fusion before blending makes sense for me, too. However, I have been burned before by not considering how others shoot, so I was just presenting a case when one would possibly want to blend first, and fuse later. What Yuval describes is something similar to a mindmap I had given him earlier. I think the XML file or someother top level persistent storage format will eventually be a useful addition to Huginl. While most of hugins options and settings can be stored in comments inside of a .pto file, it can be clumlsy. Makefiles and .pto files would be exported from hugin when required I hadn't really considered much of a revamp to the GUI, just enough additions to set the constraints as needed.. I am interested in James GSOC project this year as he plans on tackling the bracket exposure support in Hugin. Best Regards, - Gerry On Sat, May 23, 2009 at 2:29 PM, Yuval Levy wrote: > > Harry van der Wolf wrote: > > I also fuse first > > +1 most of the time, but not all the time. > > > > As an addition to what Gerry said about hand-held images: You can use > > align_image_stack to perfectly align your bracketed photos before fusing > > them. The better fusing gui's come with align_image_stack and do support > > that. > > my wish is to eventually have a "composing GUI" to deal with the > "sequence of images" - whatever that sequence is. > > constrains and actions are boxes of different sizes, that the user can > drag and drop on the working surface; and that smart logic can auto-create. > > actions are things like: > - determine CP > - add masks > - blend / fuse > - optimize position in space > - manual edit of individual parameters > - remap > - forks (to have mutliple processing, e.g. for different outputs from > the same project) > > constraints are things like: > - defining which images belong to a bracket and what type of bracket it is > - which images share the same set of parameters > - areas/mask of an image not to be considered for CP generation > - areas/mask fo an image that *must* be preserved or *must* be hidden > > > a GUI to move around and connect the boxes with a little bit of logic to > make sense of the connections (e.g. don't blend a single image or don't > enfuse images with same EV) sort of like a syntax checker before a > controller engine starts the different tools in the appropriate order > and with the appropriate parameters. > > Ideally the interface between the GUI and the controller engine would be > an XML file, although if the GUI understands the Makefile format it > could create a Makefile directly, but that would make the Makefile part > of the project and I am not sure how it will affect the projects in > terms of portability to a different box? rather go safe, describe it in > an XML and have an XML to MakeFile thing... > > Yuv > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
DaveN kirjoitti viestissään (lähetysaika lauantai, 23. toukokuuta 2009): > I don't know if this has been asked before (hard question to > ask in a search) but why don't people fuse their images before > making panoramas? I'm getting highlight banding artifacts when fusing (to 16-bit TIFF) before making the panorama. See e.g. the top left corner of http://static.panoramio.com/photos/original/10143416.jpg -- Markku Kolkka markku.kol...@iki.fi --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
2009/5/25 Markku Kolkka > > DaveN kirjoitti viestissään (lähetysaika lauantai, 23. toukokuuta > 2009): > > I don't know if this has been asked before (hard question to > > ask in a search) but why don't people fuse their images before > > making panoramas? > > I'm getting highlight banding artifacts when fusing (to 16-bit > TIFF) before making the panorama. See e.g. the top left corner > of http://static.panoramio.com/photos/original/10143416.jpg > > -- > Markku Kolkka > markku.kol...@iki.fi > > > You mention that you fuse to 16bit tiff. Fusing from what source images, also 16bit tiff or from 8bit tiff or jpg? If you are fusing from jpg or 8bit tiff you might run into the "banding artifact" issue which is described on enblend.sourceforge.net at http://enblend.sourceforge.net/banding.htm. Actually only the conclusion matters: *"In summary, it is a combination of numerical precision errors and limitations of an 8 bit/channel color format that is the cause of the banding artifacts. Rounding errors were responsible for the shape of the bands, but this was just hiding the underlying issue that 256 levels of green is not enough for quality digital imaging."* Harry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Take a look at the fused image before transforming to the panorama. The the image that is converted to the upper left corner have the artifact? If it doesn't then it isn't an enfuse problem but it may be an enblend problem. On May 25, 12:44 am, Harry van der Wolf wrote: > 2009/5/25 Markku Kolkka > > > > > > > DaveN kirjoitti viestissään (lähetysaika lauantai, 23. toukokuuta > > 2009): > > > I don't know if this has been asked before (hard question to > > > ask in a search) but why don't people fuse their images before > > > making panoramas? > > > I'm getting highlight banding artifacts when fusing (to 16-bit > > TIFF) before making the panorama. See e.g. the top left corner > > ofhttp://static.panoramio.com/photos/original/10143416.jpg > > > -- > > Markku Kolkka > > markku.kol...@iki.fi > > You mention that you fuse to 16bit tiff. Fusing from what source images, > also 16bit tiff or from 8bit tiff or jpg? > If you are fusing from jpg or 8bit tiff you might run into the "banding > artifact" issue which is described on enblend.sourceforge.net > athttp://enblend.sourceforge.net/banding.htm. > Actually only the conclusion matters: > *"In summary, it is a combination of numerical precision errors and > limitations of an 8 bit/channel color format that is the cause of the > banding artifacts. Rounding errors were responsible for the shape of the > bands, but this was just hiding the underlying issue that 256 levels of > green is not enough for quality digital imaging."* > > Harry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
DaveN wrote: > I don't know if this has been asked before (hard question to ask in a > search) but why don't people fuse their images before making > panoramas? By that I mean the software for making panoramas (the > hugin clone ptgui and autopano pro) seem to remap all the images to > create differently exposed panoramas and then blend the panoramas. > Wouldn't it be more efficient to exposure fuse the images and then > make the panorama? There are a number of pros and cons. IF the bracketed shots were taken using a (good) tripod, the images can be fused prior to stitching. However, this makes subsequent use of exposure optimisation in hugin "questionable", since the numerical basis of the optimisation is destroyed by the (clever and generally desirable) things enfuse does. The other possibility is that fusing is on a PER shot basis, and may create edge conditions between successive shots in the panorama that might cause difficulties for enblend. However, post-fusing requires the shots to be aligned. One way round this is to create a hugin project of the "middle" exposure in the bracket set, and then use this as a template for the more extreme exposures. This avoids the difficulties of placing control points on the extreme exposures at the ends of the bracketing. This only works for tripod-taken sets. Finally, pre fusing IS computationally efficient; if you repeatedly "tweak" your panorama project, having all the fusing done as a pre-stage is clearly efficient. Further, fusing a bracketed set of stitched panoramas is a massively RAM intensive activity, whereas fusing the shots separately might well fit in RAM. BugBear (pre fuser, on balance) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi Benjamin, I deal with enfuse and bracketed sets with a patch I wrote: http://ultrawide.wordpress.com/2008/11/16/hacking-hugin-part-1/ I load the first set of images, generate control points and align, then send the pano to batch. Then on the images panel, click 'bracket up' to switch to the next bracketed set, but keeping the control points/alignment from the first bracket set (this solves the problem when the set is too bright/dark to find CPs). Save and send to batch, then repeat for remaining bracketed sets. At the end, all the panos should have been warped in the same way. Then I enfuse them from the command line. Cheers, Tim Benjamin Schnieders wrote: > hi all, > actually i'm having a problem with exactly that question right now. > > > i have a series of image stacks i'd like to stitch and fuse, so stack1_0 > .. stack 1_6 until stack7_6. the thing is, the images are pretty dark, > so automatic control point generation does a very bad job using all the > images. align_image_stack however manages to align my stacks pretty well > (they are shot with a bad tripod, so a little alignment is needed) > > but everything align_image_stack can give me is a complete .hdr, (which > is, as far as i know, bad input to enfuse) a set of remapped images > (which i don't need as i want to remap them later, aligned in total) or > a pto file that holds information about the image offsets. > > seems that the latest is just what i need, but then, is there a method > of merging these pto files together in a way that the images will "stick > together"? > > to get proper results, atm i only see one solution: > > - take the brightest set of images, generate control points, align them > - starting from the brightest image, use align_image_stack to align each > whole stack to a .pto file > - manually add up the translations calculated by align_image_stack to > all further images and insert them into the big .pto from the beginning > - run enfuse and enblend. > > definitely not the best way. are there scripts oder other tricks that > will help? > > thanks, > Benjamin > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
On Tue 26-May-2009 at 22:54 +0200, Benjamin Schnieders wrote: > >but everything align_image_stack can give me is a complete .hdr, (which >is, as far as i know, bad input to enfuse) a set of remapped images >(which i don't need as i want to remap them later, aligned in total) or >a pto file that holds information about the image offsets. > >seems that the latest is just what i need, but then, is there a method >of merging these pto files together in a way that the images will "stick >together"? Yes, you could use ptomerge (from Panotools::Script) to join all the projects created by align_image_stack with a project created by autopano-sift-c or panomatic. >to get proper results, atm i only see one solution: > >- take the brightest set of images, generate control points, align them >- starting from the brightest image, use align_image_stack to align each >whole stack to a .pto file >- manually add up the translations calculated by align_image_stack to >all further images and insert them into the big .pto from the beginning This is exactly what the match-n-shift --stacks option does (also from Panotools::Script). i.e. something like this in the hugin preferences should do what you want: AutopanoExe=match-n-shift Args=-b -a -f %f -v %v -c -p %p -o %o %i -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
On 26 May, 11:23, paul womack wrote: [SNIP] > IF the bracketed shots were taken using a (good) tripod, > the images can be fused prior to stitching. > > However, this makes subsequent use of exposure optimisation > in hugin "questionable", since the numerical basis of the optimisation > is destroyed by the (clever and generally desirable) things enfuse does. > > The other possibility is that fusing is on a PER shot basis, and may > create edge conditions between successive shots in the panorama > that might cause difficulties for enblend. > > However, post-fusing requires the shots to be aligned. > One way round this is to create a hugin project of the > "middle" exposure in the bracket set, and then use this > as a template for the more extreme exposures. This avoids > the difficulties of placing control points on the extreme > exposures at the ends of the bracketing. This only works > for tripod-taken sets. I'm getting some weird results when using enfuse directly in Hugin: http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Pre-fused.jpg I've followed the tutorial given at http://hugin.sourceforge.net/tutorials/enfuse-360/en.shtml, except for manually aligning the three stacks. I aligned the middle exposures as normal, then each bracketed shot with the middle exposure shot. I tried without and with photometric optimisation but got weird results both times. In comparison, I stitched and blended each exposure layer, then enfused the three pannoramas and got this much better result, http://cnqo.phys.strath.ac.uk/~daniel/Photos/Examples/Post-fused.jpg. Source images were taken on tripod, -2EV, 0EV and +2EV exposure at each position (6+1+1). Cheers, Daniel. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi Harry et al. 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. With Hugin I tend to stitch first, then spend too much time fixing ghosts by hand. But that is mainly because I can't understand how to do it the other way, which based on this thread, I guess must be better. 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? 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? Regards, Tom On May 23, 5:18 am, Harry van der Wolf wrote: > Hi Dave, > > I also fuse first (but maybe I'm a bit biased being the writer of the > ImageFuser tool). > The reason I do this is that Hugin has sometimes difficulties in finding > CP's between the very dark and light images in such bracketed sets. It is > sometimes also hard to do that by hand. In that case prefusing the helps a > lot. > > As an addition to what Gerry said about hand-held images: You can use > align_image_stack to perfectly align your bracketed photos before fusing > them. The better fusing gui's come with align_image_stack and do support > that. > > Harry > > 2009/5/23 Peter Gawthrop > > > > > Hi Dave, > > > I fuse first. The reason is that, in my case, each set of eight > > images is taken with exactly the same settings (using manual > > mode). The other advantage is that selecting control points for the > > fused images is easy as all of the image is visible. > > > Peter. > > > From: DaveN > > Subject: [hugin-ptx] Fusing before or after > > Date: Fri, 22 May 2009 17:50:04 -0700 (PDT) > > > > I don't know if this has been asked before (hard question to ask in a > > > search) but why don't people fuse their images before making > > > panoramas? By that I mean the software for making panoramas (the > > > hugin clone ptgui and autopano pro) seem to remap all the images to > > > create differently exposed panoramas and then blend the panoramas. > > > Wouldn't it be more efficient to exposure fuse the images and then > > > make the panorama? > > > > __ > > > This email has been scanned by Netintelligence > > >http://www.netintelligence.com/email --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
2009/5/27 Tom Sharpless > > Are you fully satisfied with align_image_stack? I have noticed some > complaints as well as much praise in the lists. I'm quite satisfied with align_image_stack. As it is not perfect, I'm not fully satisfied ;-). Also align_image_stack sometimes has problems with very dark images. Align_image_stack creates "aligned" tiffs and it can create a HDR. One of the issues right now is that align_image_stack doesn't create a correct HDR when the input is tiff, both 8bit as well as 16bit (didn't try with 32bit). It makes a correct HDR image from jpeg and 8bit/16bit png. I still need to file a bug. (I've been quite busy last week). > 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? It's main limitation is it's speed (or better: lack of it). I have the idea that the code could be optimised for speed, but that might just be my impatient nature. Next to that is the mentioned bug off course, but that's not an improvement, only a (neccessary) bug fix. Maybe others experience other limitations. > 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? > Regards, Tom > No, it doesn't do that. It only works with Control Points. I have no experience at all with these kind of "fine-aligner using correlation" algorithms so it might be a helpful addition, but I can't judge. I would welcome such an addition if it is only to see whether it works. But then again: I'm not the one who can program that and who needs to put time and effort into it. Hoi, Harry > > On May 23, 5:18 am, Harry van der Wolf wrote: > > Hi Dave, > > > > I also fuse first (but maybe I'm a bit biased being the writer of the > > ImageFuser tool). > > The reason I do this is that Hugin has sometimes difficulties in finding > > CP's between the very dark and light images in such bracketed sets. It is > > sometimes also hard to do that by hand. In that case prefusing the helps > a > > lot. > > > > As an addition to what Gerry said about hand-held images: You can use > > align_image_stack to perfectly align your bracketed photos before fusing > > them. The better fusing gui's come with align_image_stack and do support > > that. > > > > Harry > > > > 2009/5/23 Peter Gawthrop > > > > > > > > > Hi Dave, > > > > > I fuse first. The reason is that, in my case, each set of eight > > > images is taken with exactly the same settings (using manual > > > mode). The other advantage is that selecting control points for the > > > fused images is easy as all of the image is visible. > > > > > Peter. > > > > > From: DaveN > > > Subject: [hugin-ptx] Fusing before or after > > > Date: Fri, 22 May 2009 17:50:04 -0700 (PDT) > > > > > > I don't know if this has been asked before (hard question to ask in a > > > > search) but why don't people fuse their images before making > > > > panoramas? By that I mean the software for making panoramas (the > > > > hugin clone ptgui and autopano pro) seem to remap all the images to > > > > create differently exposed panoramas and then blend the panoramas. > > > > Wouldn't it be more efficient to exposure fuse the images and then > > > > make the panorama? > > > > > > __ > > > > This email has been scanned by Netintelligence > > > >http://www.netintelligence.com/email > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Bruno Postle wrote: > > 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. I imagine that last word should be "enblend" :-) BugBear --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
On Thu 28-May-2009 at 09:40 +0100, paul womack wrote: >Bruno Postle wrote: >> >> 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. > >I imagine that last word should be "enblend" :-) Yes, or "confuse". -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Thanks, Bruno So align_image_stack does use local correlations, then generates CP's as a way of communicating the required alignment to other tools? Is this done in such a way as to allow some warping as well as simple shifting in the final alignment step? That is, are the CP's based only or mainly on local shifts? If that is the case then I think these CP's could profitably be fed to libpano's morph-to-fit facility (or an improved one, if someone would like to write that) in cases where parallax is a problem. -- Tom On May 27, 4:55 pm, Bruno Postle wrote: > 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
On Thu 28-May-2009 at 07:52 -0700, Tom Sharpless wrote: > >So align_image_stack does use local correlations, then generates CP's >as a way of communicating the required alignment to other tools? It generates control points because it uses the hugin optimiser to do the alignment (which is also why it accepts projection and field of view parameters). >Is this done in such a way as to allow some warping as well as simple >shifting in the final alignment step? The alignment uses the usual roll, pitch, yaw and fov distortion. >That is, are the CP's based only or mainly on local shifts? No idea, the image is divided up into a grid and a feature detector tries to place an even distribution of points over the image area. In practice, with the -p option it behaves like a control point generator that only works with stacked photos, but which produces very few 'bad' points and which works very well with large exposure differences. -- 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hi all, This description is correct. Note that align_image_stack was really written more like a proof of concept and is not really well optimized. Actually, the implementation of the normalized cross correlation in hugin is very basic and thus quite slow. Replacing it with a properly optimized version (I believe opencv has a nicely optimized correlator) would make both align_image_stack and the fine tune functionality much faster. ciao Pablo Bruno Postle wrote > On Thu 28-May-2009 at 07:52 -0700, Tom Sharpless wrote: >> So align_image_stack does use local correlations, then generates CP's >> as a way of communicating the required alignment to other tools? > > It generates control points because it uses the hugin optimiser to > do the alignment (which is also why it accepts projection and field > of view parameters). > >> Is this done in such a way as to allow some warping as well as simple >> shifting in the final alignment step? > > The alignment uses the usual roll, pitch, yaw and fov distortion. > >> That is, are the CP's based only or mainly on local shifts? > > No idea, the image is divided up into a grid and a feature detector > tries to place an even distribution of points over the image area. > > In practice, with the -p option it behaves like a control point > generator that only works with stacked photos, but which produces > very few 'bad' points and which works very well with large exposure > differences. > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hello all. On May 23, 2:50 am, DaveN wrote: > I don't know if this has been asked before (hard question to ask in a > search) but why don't people fuse their images before making > panoramas? By that I mean the software for making panoramas (the > hugin clone ptgui and autopano pro) seem to remap all the images to > create differently exposed panoramas and then blend the panoramas. > Wouldn't it be more efficient to exposure fuse the images and then > make the panorama? I'm very late to this thread, but I'm catching up. I was wondering if I've been doing it entirely wrong "all the time". All the time means that I havent made that many fused panoramas. With my main example of the entrance to the train station in Bern [1] i remember that I just dumped all the 87 images (29 photos for each exposure step) into hugin and stitched a fused image in one single output. It took a long time for Pan-O-Matic to find the control points but in the end I got a quite impressive result. So I'm asking: would I get another result if I'd have generated three panoramas, one for each exposure step and then enfuse them to one final panorama? Greetings from Switzerland Habi [1]: http://www.flickr.com/photos/habi/sets/72157614221776963/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[hugin-ptx] Re: Fusing before or after
Hello Habi, > So I'm asking: would I get another result if I'd have generated three > panoramas, one for each exposure step and then enfuse them to one > final panorama? I can't tell this but I have the impression that the scene isn't particularly suitable for exposure fusing. I would expect the dark areas in the train station to have a little more detail than without fusing but that's all. (Of course I haven't seen the original images or a panorama made solely of the middle exposure.) By the way I would recommend to use vertical control points to keep vertical edges of buildings upright. regards Joachim --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
