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 <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
