there have been some off-list mails about the next releases going around. My reply to those mails was to lay down my intentions - something I do here publicly with a request for comments.
I would like to see the hugin project move to frequent incremental releases. I would like to see the new features, specifically those that have been developed by our GSoC 2008 students, hit the mainstream user's desktop as fast as possible. To achieve this goal, I intend to move forward on releasing experimental features as Windows binary installers in the hope to attract not only testers, but also contributors; and on releasing an updated hugin SDK to empower contributors to build and modify hugin. EXPERIMENTAL FEATURE RELEASES I intend to release a windows binary installer of the gsoc2008_integration branch soon. If there are no objections I'll call it 0.8.0alpha1. in its current state it includes fast preview and batch processor which IMO are ready for some general public consumption/feedback. depending who is faster (Tim or I), Celeste (sky identification) will also be part of 0.8.0alpha1. Else it will be 0.8.0.alpha2. There is currently still an issue with Celeste in the hugin GUI in OSX (though standalone it works as expected). Thanks to Tim and Harry for trying to sort that one out. I expect that these will be all the features that go into 0.8.0 because I would like to see 0.8.0 released for Christmas 2008; and I would like the releases to be determined by the calendar and not by the features. Features which are not ready are simply pushed back to the next releases. Bug fixing is welcome any time, and 0.8.0 will surely have its fair share of bugs. Beyond that, we still have interesting code that is not ripe for mass consumption yet: * hugin_hdrmerge - the result of Jing's GSoC 2007 project, is still not robust enough for daily use. It would be nice if somebody could pick that up, and make the deghosting feature also available to enfuse. * for the masking in GUI GSoC 2008 project of Fahim we still need to think about the right place in the hugin GUI and in the stitching process. I personally would like to use it to generate masks before blending to manually manage image overlaps / moving subjects. * Onur's feature matching code and Zoran feature description code are also in need of integration, into a tool that should become, as Bruno call it, *the* single 'best of' control point generator integrated/linked into hugin, ie it needs to: - be patent free - do the conformal projection thing, or similar - do the align_image_stack thing for bracketed shots - do the sky-point pruning thing - have 'inconsistent-point' pruning, like apclean, ptoclean etc.. Tom has mentioned that he is working on something in a private email. I look forward to see the code evolve. HUGIN SDK Pablo last release of the Hugin SDK was December 2007 IIRC. many things have happened since - some upstream libraries have evolved/progressed and there are new dependencies with 0.8. To empower others to build their hugin 0.8, I will release an updated Hugin SDK, following in the footsteps of Pablo. I believe in running forward: it is more likely that a newer version of an upstream dependency fixes current problem than that it introduces new ones through incompatibilities or API-breaks in the features needed by hugin. Hence I propose a policy of trying to keep the SDK as up to date as possible. Specifically this means binding against wxWidgets 2.8.9 (released last months) instead of 2.8.7. Exiv2 has also progressed and 0.18 will provide TIFF exif writing capabilities. User of Linux systems get those improvements almost automatically with the evolution of the distributions, and keeping the SDK up to date is just a way of keeping Windows builders in sync. I do not have a lot of time for testing, hence the initial releases with new SDK are to be considered experimental. The sooner we hit the bugs, the sooner they will be fixed - and this applies to both hugin and third party code. I don't have the skill to do all of this. I am learning every hour I spend with building hugin, and I do it mainly for the learning experience. This is why, once I tackled a learning phase, I move on to the next, hoping that somebody else will step in and do what I did for the next release cycle. Know how transfer is what makes Open Source live on, and I will transfer all the know how that is requested from me. Laziness is the enemy of know how transfer and this is why I will intentionally leave some things incomplete (like the 0.7.0 installer). Spoon-feeding encourages laziness. I want the users to feel slightly hungry so that they will take the necessary step to fill their stomach rather than wait to be spoon-fed. The Hugin SDK, with the build instructions on the wiki, does just this. CODE DOCUMENTATION Last but not least, Hugin's code needs to be better documented. Last year this wonderful community helped me documenting the building process. And I had no clue of the building process back then. Now we need the same thing with the code. The GSoC 2008 student survey showed clearly that we have a deficit, that the architecture and the design decisions need to be documented in a way to simplify the learning curve for those willing to put their hands under the hood. I would like to see a top-down approach, describing the folders and files, the dependencies, the classes, the project and the tools, so that any future student can get quickly up to speed. Students who participated to the recent summer of code have the experience and know what they would have needed. If any of you can start typing away into the wiki, I'd be very grateful. FURTHER THRUSTS we don't know if Google will hold a Summer of Code next year. If it does, I'd appreciate if this year's students would step in, like Zoran did last year to become a mentor. Also, as a community, we may want to think whether there are other similar initiative that we could leverage. I am thinking of the season of usability - hugin's user interface and workflow / process have been (over)loaded with new functionalities and maybe a fresh look at them - building on Ippei's foundation in either wxWidgets or Qt - may unleash even more power from the existing code. thoughts? Yuv 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
