hallo Lars, Lars Schimmer wrote: > For windows only snapshots and unofficial build >0.7.0 are noted, but > the windows bin link follows to http://hugin.huikeshoven.org/ which > tells me "only vista, highly experimental" for >0.8.0. > > Is there no stable (general) windows binary release >0.7.0 available at all?
Nicolas gave you the short answer: No. With a little bit of fiddling you can make the experimental builds work for you, but they are not of the same stability / quality as the 0.7.0 and the critical criteria to be uploaded to SF and distributed as official is real stability, not just "declared stability" (as in: the project has released them). Long answer: There are four issues that make a Windows binary installer complex. Build-time dependencies; Run-time dependencies; the Installer itself; and last but not least the SDK, that brings them all together. A Windows binary release must also ship other run-time dependencies because of the lack of proper package management system on that platform. On platforms with a package manager, the four issues are taken automatically care of.. Around the time of the 0.7.0 we had a lucky combination of really stable dependencies; up to date Installer scripts; and users from the Windows community willing to go through the pains of a systematic and clean build (that was myself and Guido. In the end his binaries were uploaded to SF). Since then things have been wacky. They may improve by the end of the year. Current status: BUILD-TIME DEPENDENCIES 1. Libpano is the critical build-time dependency. Bleeding edge features require the latest libpano. The current 2.9.15_beta3 is acceptable (although there have been further fixes committed, so better wait for the next tarball). In between the repository was broken and either does not build or may result in faulty Hugin binaries. 2. Other build time dependencies don't improve as fast; tracking their improvements is not critical. The current SDK (by Guido) should be good enough to build Hugin. Using slightly older dependencies only affects marginally the end-user experience and is acceptable. RUN-TIME DEPENDENCIES There are two critical run-time dependencies: Enblend, and (optional) a control point generator. 1. Enblend is the critical run-time dependency. At the time of releasing Hugin 0.7.0 we were lucky that the Enblend repository was in a stable state. After that, Enblend 3.2 has been released and there are reports that it is a regression compared to the pre 3.2 snapshots. To compile an Hugin installer Enblend must be present inside the SDK. Unfortunately the most recent SDK does not have what it take to build Enblend. Joachim is expanding the SDK to build Enblend from the repository. Enblend is now in the final stages of polishing / cleaning up bugs ahead of the 4.0 release. There is no guaranteed release date, the stated objective is to release before year end. No guarantee. 2. There are a bunch of options for the control point generator. The problem is that all of those that work are covered by some patent (SIFT or SURF) in some jurisdictions, making their distribution a hot potato. Although a control point generator is an optional dependency, most end-user consider it mandatory. The script to compile the 0.7.0 installer had two variations, one with and one without CP generators. I've expressed the view that in the future it would be good to do the same as for OSX and release separate Windows binary installers for Hugin and for the CP generators. 3. Autopano-SIFT-C is the last incarnation of the CP generator traditionally associated with Hugin. The current status is that the previous "stable" release (2.5.0) had serious memory leaks and crashed on large projects. The current development snapshot of 2.5.2 is broken, and there is no guaranteed date for the fix (Tom said he has no time before the end of the year). As an interim solution we've branched out 2.5.1 (currently release candidate 2, could be declared final any time). 4. Autopano-SIFT-C is covered by the SIFT patent in some countries. The patent holder, UBC, allows use for "educational purposes". I do not recall if also for "non-commercial purposes". The patent is the reason why popular mainstream Linux distributions such as Debian and Fedora don't carry Autopano-SIFT-C. 5. A better control points generator is Pano-O-matic. It is covered by the SURF patent. You can find it on the web, but it is very unlikely that it will make it into the official Hugin binary distribution. You can make it work for you if you know what you are doing. 6. We still don't have a patent-free, open sourced control points generator. Some parts have been produced during Google Summer of Code 2007 and 2008, but work still needs to be done and there is nobody working on that at the moment, AFAIK. WINDOWS INSTALLER Since I added the 0.7.0 installer scripts to Hugin's codebase I changed platform and the scripts were practically orphaned. All installers circulating after 0.7.0 are modified versions and until not long ago the modifications where not even back in the codebase. Allard has committed his modified version recently. It has not been tested/verified by anybody else. All of these issues can be solved. Some of them are related to the Hugin/Enblend/Libpano/Autopano-SIFT-C codebase. We're solving these. The new parallel development cycle of Hugin works well, trunk is in better state than ever and we can branch out regularly quite stable release codelines. Libpano seems to be going a similar way, with 2.9.15 branched out as a separate codeline. This bodes well for future stability. Bruno stabilized an Autopano-SIFT-C interim release and Chris is taking care of Enblend. Some of them are platform specific and are left to volunteers on that platform. Harry has been the driving force behind OSX. We have not had a driving force behind Windows since 0.7.0. Some Windows users are contributing valuable code (Thomas), build (Allard, Ad, Joachim), SDK (Guido, Ryan), and testing (too many to name, and sorry if I forgot somebody contributing code, build, SDK work). But nobody is really taking it all the way to a proper and clean binary release. It's a lot of work, not to be underestimated. It takes more time than just syncing the repositories and building; and for those like me who have access to multiple platforms, it is time taken from other priorities. I hope this is shed some light on the situation... > - ------------------------------------------------------------- > TU Graz, Institut für ComputerGraphik & WissensVisualisierung ... at such an institute you should have students / assistants / professors with the skill to build Windows code? 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 -~----------~----~----~----~------~----~------~--~---
