• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    April 2014
    M T W T F S S
    « Dec    
     123456
    78910111213
    14151617181920
    21222324252627
    282930  
  • Archives

Hugin 2010.4.0 Officially Released

Today I declared the Hugin build released a few days ago final. It is dedicated to Milko K. Amorth, a pioneer of the full spherical panoramic photography that we have lost last year under tragic circumstances.  He will be missed.

This release of Hugins brings a load of new features.  The two most notable are the result of two Google Summer of Code (GSoC) 2010 projects:

The built in control point generator cpfind was the is the GSoC project of Antoine Deleforge, built on top of more than three years of contributions made by too many people to list here.  For the first time Hugin is “feature complete”.  This does not mean that there are no new features coming.  It only means that it is now possible to run the typical stitching workflow end-to-end without relying on third party non-Free packages.

The new underlying controller, Makefilelib, the GSoC project of Florian Achleitner.  Users of the GUI won’t notice, but it enables a more robust stitching process, distribution on multiple stitching nodes, finer grained control and extension of the process through other third party tools controlled by the same Makefile.

More information in the release notes.

Another first: the user-community around Hugin is growing and the user-contributed binaries are already available or will be available shortly after the source code release.  Many Thanks to everybody who has contributed to this great release cycle, particularly to Matthew Petroff for the Windows builds and to Harry van der Wolf for the OSX builds.

Hugin 2010.4.0beta2

Right on the heel of the first beta, here is the second beta in this release cycle.  It’s only one week since the first beta, but a lot of effort has gone into translations and bug fixes.  The changes since beta1 are summarized in the release announcement.

Once again the leading users have responded to the call and built binaries for their respective platforms.  Not that it is a competition, but this sounds almost like the results of a race with Harry van der Wolf coming in first with builds for Mac OSX, followed closely by Andreas Metzler’s Debian/experimental and Matthew Petroff with builds for Windows.  Extra bonus for Matthew who published his builds on our SourceForge page.  Uploading to SourceForge is easy and if your SSH-Key is correctly set in their system you don’t even need to enter a password.  Just start a command line and type something like

rsync --partial --progress -e ssh hugin-2010.4.0beta2.tar.bz2 yuv,hugin@frs.sourceforge.net:/home/frs/project/h/hu/hugin/hugin/hugin-2010.4_beta/

No such problems for users of platforms with proper package management system.

Bruno published Fedora builds at the usual location and I used Andreas’ Debian packages to publish Ubuntu builds for Lucid and Karmic in the Hugin PPA on Launchpad.  Moreover I tried a Soyuz feature and copied the Lucid source from the Hugin PPA to my personal PPA where it built successfully for Natty.  I  don’t have a Natty install yet so I can’t really test if it worked.

Next scheduled release is a release candidate for December 17.  Maybe an additional beta before that if further testing is required.  I don’t want to push too much on the builders.  The build mechanisms are oiled and ready.  If the performance of the last two beta releases is an indication for the future, this may be the first Hugin release to shrink the lag between source code release and binary release to less than 48 hours.

For now, happy bug fixing!

Hugin 2010.4.0beta1 released.

Hugin 2010 Logo

Yesterday I released the first tarball in the new Hugin release cycle.  The goal is to release 2010.4.0 before the end of the year.

It’s only a couple of months since the last release, but a lot has changed, in the code, in the process, and in the infrastructure.

I wrote about the infrastructure change three days ago.  The activity in the new bug tracker is massive.

In the code, the most important news is that with its own brand new control points detector, Hugin can be considered feature-complete.

To underscore this achievement, the project has given itself a new look, contributed by Cristian Marchi, that has given an evolutive face lift to the original design by Dr. Luca Vascon whose source files have been lost in time.

In terms of process, this time around we have more contributors than ever, on multiple disparate platforms.  The project will still stick to its policy of releasing source code as soon as it is good to go and leaving it up to the user communities on the different platforms to produce and distribute binaries because it does not make sense to delay the release of source code only because there are no binaries; and it does not make sense to delay the release of binaries for a platform with faster builders only because there are no binaries yet on other platforms.  However the natural and inevitable time lag between a released source package and a working binary package (which is what most users are looking forward to) is likely to be reduced for most platforms.

First to respond to my call was Matthew Petroff.  He made Windows binaries in four variations (32bit/64bit, installer and standalone zipped) available within a few hours and before anybody else.  Matthew has joined the team recently and he has done some excellent polishing work on the Windows side of thing.

Then the indefatigable Harry van der Wolf followed up.  Building for OSX is always a little bit different/special and require more effort than most other platforms.  He reported this morning that everything works and will produce the coveted bundle installer tomorrow.  What would Hugin Mac users do without Harry?

Andreas Metzler reported a “work for me” update to the Debian experimental source package.  Based on his work I will try to produce my first Ubuntu packages of Hugin for Ubuntu Lucid (my main system) and Jaunty (chrooted), and Gerry Patterson will tag-team for Maverick.

On the Fedora front things are quiet but not less up to date.  Between Bruno Postle and Terry Duell recent versions of Fedora should be covered soon.

Lukáš Jirkovský will try to use OpenSuSE Build Service, but he’s very busy and there is no guarantee.

No promises.  There is always an inevitable lag between the release of a source tarball and that of a usable binary – at minimum the time it takes for the builder to download the tarball, build it, run a minimal test, and publish it.  But we are doing our best to make this the Hugin release with the shortest delay from source to binary.

This weekend is a test run.  The really interesting run will be when we approach the final release.  Keep your champagne cold for now.

And when will somebody report success building Hugin on Android or iOS?

From Subversion to Mercurial. Part 3, Implementation Day and Beyond

If you followed the steps described in the first and second parts of this series, you should have a Mercurial (Hg) repository ready to replace your project’s Subversion (SVN) repository.  In this third and last part we’ll go over Implementation Day, with particular detail on how to implement this migration on the SourceForge infrastructure.

Test

Can’t test enough.  Your script produces an Hg repository that looks OK on superficial investigation with tools like hg log and hg view.  But does the code build?  Hugin’s build system had a couple of dependencies on SVN and they needed to be updated.  Thomas Modes and Kornel Benko stepped up to the task.  Can developers and builders use this repository?

Educate

On Implementation Day the project will transition from SVN to Hg.  While all relevant contributors are proficient in SVN, Hg was new territory for many.  While progressing on the conversion I kept the community informed and took every opportunity to encourage learning of the new tools, including public tutoring that continues after the transition.  You want to encourage people to share their experiences and learn from each other.  Conceptually the biggest difference between SVN and Hg is that with Hg the repository sits on your local client.  A check in to SVN is the equivalent of a check in and a push to Hg.  Offline operation is not possible with SVN but it is with Hg.  However both are revision control system (RCS) and very similar to use.

Implementation Day Overview

Warn everybody one last time.  Create a new repository on SourceForge for each migrating code line.  Lock down SVN by revoking write access to everybody but a few maintainers who will clean up after the transition.  Run once again the whole migration on a green field, from scratch, to be sure that everything to the very last SVN commit is included.  Test one last time this new local repository (compare it to previous results); create the new repository on SourceForge and push your local repository to it. Last but not least, configure the repository on SourceForge and announce the transition to the world.  Sounds easy.  The devil is in the detail.

Mercurial on SourceForge

SourceForge has been very generous with the projects it is hosting: we can have unlimited Hg repositories.  Unfortunately there are rough edges.

To activate Mercurial for your project:

  • Login via the web as a project administrator and go to the “Develop” page for your project.
  • Select the Project Admin menu, and click on “Feature Settings”.
  • Select “Available Features”.
  • Select the checkbox to the left of the “Mercurial” heading. Your repository will be instantly enabled.

This first repository will be fine but if you want to activate more than one repository you will have to manually set them to be group writable.  To activate additional repositories:

  • Log on to SourceForge’s shell service (assuming you have set up your SSH key) with `ssh -t USER,PROJECTUNIXNAME@shell.sourceforge.net create`
  • Navigate to your project’s Mercurial space with `cd /home/scm_hg/P/PR/PROJECTUNIXNAME`, e.g. for Hugin this would be `cd /home/scm_hg/h/hu/hugin`
  • Create a new directory with the name you want for the repository.  E.g. for Hugin’s website this was `mkdir hugin-web`
  • Execute `hg init DIRNAME` (where DIRNAME is the directory you just created, e.g. `hg init hugin-web`). This will initialize the new repository.
  • Inside the new repository, edit the configuration file .hg/hgrc (see configuration section below)
  • SourceForge rough edge: group write access must be given manually `chmod -R g+w /home/scm_hg/P/PR/PROJECTUNIXNAME/DIRNAME`

Configuration of the Mercurial Repository on SourceForge

SVN support on SourceForge is mature and projects are used to amenities such as email commit notifications.  Hg support is better than what the scant documentation suggests.  Most standard functionality, including email notification, works, even if it is officially unsupported.  One only has to find out how to configure it.  I played around with some trial and error already when optimizing the Enblend repository last year.  This is the hgrc file template that works for us:

[hooks]
changegroup.notify = python:hgext.notify.hook

[email]
from = NOTIFICATION_ADDRESS@lists.sourceforge.net

[smtp]
host = localhost

[web]
baseurl = http://PROJECT.hg.sourceforge.net/hgweb/PROJECT/DIRNAME

[notify]
sources = serve push pull bundle
test = False
config =
template = \ndetails:   {baseurl}{webroot}/rev/{node|short}\nchangeset: {rev}:{node|short}\nuser:      {author}\ndate:       {date|date}\ndescription:\n{desc}\n
maxdiff = -1

[usersubs]
NOTIFICATION_ADDRESS@lists.sourceforge.net = **[trusted]

users = *

You’ll have to replace your own project unix name PROJECT; your own Hg repository top directory DIRNAME; and your own NOTIFICATION_ADDRESS mailing list.  The configuration options are documented.

Committer Write Access

With a dRCS like Mercurial write access has a completely different meaning.  Everybody can `hg clone` an existing repository and once cloned has full write access and can publish their own repository.  The d in dRCS stands for distributed.  Technically there are no more hierarchies and no more central control.  All clones are equal.  Whoever owns a clone can decide to publish it on the web, e.g. with `hg serve`, and give write access to whomever they want.  Granting SourceForge write access only means that the committer can push to the repository hosted on SourceForge.  What makes a repository authoritative is user’s trust, and this is given implicitly by pulling from it.

SourceForge Rough Edges, Again

I wish there was a way to group-manage access rights on SourceForge.  I have not found it.  I needed to revoke SVN access to most developers, and grant them Hg access.  I had to click through each and every contributor registered with the project and single handedly managed their access rights.  To make things worse the pseudo-ajax web interface of SourceForge is everything but asynchronous: it reload the page after each change.  Ajax-cosmetics with underlying old technology from the last century.

One point projects on SourceForge will need to pay attention to are default access rights.  I did not find a place to change those, so every new project member gets by default SVN access right, unless you explicitly remove them.  It seems to me that the defaults on SourceForge are based on the principle of random uncoordinated historical growth.  Have they ever heard of the generally accepted principle of least privilege?  And the default file access for newly created extra Hg repositories is less than reasonable least privilege (see above).

<rant>And don’t tell me about SourceForge’s IdeaTorrent and ways to request and enhancement.  In my experience it does not work and some things on that site have been broken for years when the fix is simple, easy, and does not take much time.  Have you tried to use a SourceForge mailing list archive?</rant>

Push

Now that everything is set, you can simply `hg push` from your local repository to the SourceForge one.  Or if you’re really confident, you can rsync the .hg directory (but don’t forget to edit the .hg/hgrc configuration file on the SourceForge end).

CMake Build System

Our CMake build system depended on SVN and after the push it was broken.  Kornel Benko and Thomas Modes fixed it.  Bruno Postle added a break in the CMake build system in the SVN repository, to warn users of that repository that newer versions are in Hg.  Harry van der Wolf updated the OSX build system.

Conclusion

The disruption was short.  A few hours after going live, developers started committing again, using Hg.  Builders started building and distributing again, using Hg.  The Google Summer of Code students cloned away their own copies of the source code and started working on the next major developments for Hugin.  After taking on the most complex of the code lines in the SVN first,  I migrated the remaining ones over a few hours Sunday night.  Hugin and most of its related projects live now happily in Hg and can easily be converted to other formats, including Bazaar, git, and even SVN.  Initially I thought to mirror the default code branch from Hg to SVN, but our project does not really need that.  Subversion has been made completely redundant by a newer, better, superior tool. Mercurial and its likes would not exist without Subversion, and should be seen as a continuum in the lineage rather than a break from the past.  With Mercurial, Hugin is freer than ever, and you are free to take it further on a journey to the future.  For now Hugin still lives on SourceForge, where the next critical bit of infrastructure is the bug tracker.  But with Mercurial the dependency on SourceForge; and the dependency on any single central service or person; has been further reduced.  Long and Free live Hugin.

Hugin 2010.0 Released

Last week Bruno released Hugin 2010.0. It was almost immediately followed by binaries for MacOSX (Harry), Debian/Ubuntu (Andreas), Fedora (Terry). The step from release candidate to release had been longer than usual because of the lack of feedback from Windows builders/users whose interest seems to have shifted to the development version, which has already a few new cool features such as a masking tool.

Trunk still has a few rough edges, but overall is ready for the next cycle. Consensus is forming on moving the codebase to Mercurial and potential new Google Summer of Code projects are being discussed on the mailing list.

Releases, Releases.

Somehow the end of the Gregorian calendar year seems to be a popular time for software releases. There have been a number of interesting releases in the past two weeks in the area of Free photography in general and panorama making in particular. Too many to mention them all.

The one that caught my attention is PTStitcherNG 3.0b by Prof. Dr. Helmut Dersch. Helmut has been at the forefront of panorama making software for more than a decade now, and his new tool optimizes for speed and memory footprint. A 1.5 gigapixel panorama will stitch within less than 100MB RAM. To me this comes very convenient: since I upgraded my photo gear the resulting images are too big to stitch on my ailing notebook maxed out on RAM.

Unfortunately for the time being it is free and not Free. Binaries are freely available for Windows, OSX, and OpenSuse 11.1 (x86_64). Users of Linux distributions other than OpenSuse will need to run the Windows binary through Wine and take a 30% performance hit. The currently distributed binaries only work on SSE3 processors. Helmut says that a source code release is pending the scientific publication of his results. For the Pentium M / Ubuntu 9.04 notebook whose life I’m trying to extend beyond shelf-date  I’ll have to wait for SSE2 binaries or for the source code. I worked around it by rsyncing the source images to my Kubuntu 9.10 office workstation and running PTStitcherNG there, remotely.

Another notable release is Enblend-Enfuse 4.0 that has been overhauled by Christoph Spiel and has spurned a release of newer versions of related GUIs,   ImageFuser0.7.4 by Harry van der Wolf and EnfuseGUI 2.1 by Ingemar Bergmark.

Last but not least, Bruno released Hugin 2009.4.0. completing the work I left unfinished, and started the release cycle for 2010.0.0. James topped the Holiday present by merging into trunk the much awaited new layout branch, with his Google Summer of Code project and Pablo’s XYZ  parameters for image position.

Too Much Love Will Kill You

With the increased pace of development, added features, and improved stability, Hugin has become more visible and has got more attention and love from potential users, and of course they have needs and wishes.

One recurring user request is: “why don’t you make binaries available?” John Riley argues for a “concerted effort to create binaries”, saying that Hugin “deserves a much wider audience than those who are willing and/or able to build it from source” and that “making it more accessible would increase its visibility, which could get more people interested in contributing”.

No doubts that binary distributions would be nice. How do they fit in the plan? What is the status of the project? Of the binaries? What are the priorities?

The Plan

Most contributors to Hugin are volunteers. The rule number one is that there is no master plan. Well, I do have my plan, but I can not impose it on others; and others can’t impose their plan on me. Each contributor decides what is right for him, set his own priorities and contributes what he wants. If the contribution makes sense other contributors will adopt, follow, join, contribute.

I like to think of contributors as a free-flowing fluid on the project, like water on Earth. The fluid is naturally attracted to valleys where it forms rivers and lakes. Its passage shapes the landscape.

Controlling the fluids would need expensive barrages. Most often not a practical proposition. Project administrators only decide what is on Sourceforge and even this is not control: The software is Free. No barrier can prevent the fluids from flowing in an alternate direction and if that direction is more attractive, others will follow. It’s purely meritocratic.

Status

Hugin is undergoing major change. Growth has exposed the limits of the previous structures, and we had to adapt to the new dynamic.

When I first got involved with Hugin three years ago, I found the learning curve extremely steep. We needed to make it more attractive to contributors. In response to the difficulties encountered by the Google Summer of Code students the project reacted with SDK and documentation. Hugin has become more accessible for contributors. We see the result with new contributors coming on board almost every month (and without the incentive of a Google internship). Their contributions pose new challenges.

Last year we integrated four major contributed features: celeste; fast preview; batch processor; and new projections.The integration resulted in a development freeze for much of 2009, until the 0.8.0 release last July.

In the meantime, the queue of new contributed features waiting for integration had doubled:

  • GPU-stitching (to use modern hardware for faster stitching, integrated in 2009.2.0);
  • lens calibration (to develop a better mathematical model for the lens geometry, integrated in 2009.4.0 but not ready for practical use);
  • deghosting for enfuse (to reduce ghosts when merging stacks of images with enfuse, integrated in trunk and scheduled for release after 2009.4.0);
  • CPclean (to prune bad control points by statistical method, integrated in 2009.4.0);
  • Auto-crop (to reduce the blank areas around the image);
  • New layout mode (to improve the handling of exposure stacks);
  • XYZ-transform (to improve geometric positioning when the images are not taken from precisly the same no-parallax-point);
  • Masking in GUI (a Google Summer of Code 2008 project that we’re still studying how to integrate).

And there are plenty of small incremental improvements here and there that would not have happened if we were in a freeze.

Extrapolating the past, we’d be frozen until 2011. This would effectively kill the project. I introduced parallel development to solve the bottleneck, and I hope we can work through most of the back log before the end of the winter.

There is a cost to parallel development: desynchronization. And the less glamorous areas of the project suffer particularly. Building binaries for distribution is such an area.

Binaries

The Hugin project is committed to release source code that builds on a wide variety of platforms. The creation and distribution of binaries is left to the users’ communities. Of course we are users ourselves, and we do build binaries, mostly for testing purposes and only on our respective platforms. Our contribution to the distribution process is mostly documentation, because building for self-use and building for distribution are two completely different things, despite a common set of underlying steps.

We stop at the source code for many reasons. Primarily: limited access to all the platforms; limited resources; limited time. Building for distribution requires extra care (quality assurance) and extra steps that are critically important to make the difference between a good distribution and a dysfunctional one. Starting from a fresh source tree is strongly recommended to build a proper distribution. A developer’s source tree is seldom fresh. It contains the traces of the developers work, and this has the potential to contaminate the build process.

One of my activities over the past three months, as I took charge of our release process, was to liaise with downstream distributors to help them produce better distribution in the hope that new versions of Hugin will trickle faster down the distribution channel to the end users. The result:

  • The Hugin FreeBSD port is now easier to maintain and maintainer Vasil Dimov tracks recent releases closely.
  • The Hugin Gentoo Linux ebuild is kept up to date by Thomas Pani, Gentoo maintainer.
  • Coordination with Andreas Metzler and the maintainers team at Debian resulted in the clean up of some outstanding issues and better support of that plattform and its derivates, including Ubuntu. Unfortunately Hugin 2009.2.0 did not make the cut for Ubuntu 9.10, which has Hugin-0.8.0 available through it’s package manager.

Of course this is of little interest for people who do not use FreeBSD, Gentoo, Debian, Ubuntu. And the reality is that the majority of users are still on Windows. Systems without package managers (Windows and OSX) add additional effort / complexity to the build and distribution of binaries. Nevertheless, Harry van der Wolf, supported by some other Mac users, provides unofficial OSX binaries on a regular basis. And for Windows, I have recently guided a few users through parts of the build process. Unfortunately none of the resulting Windows binaries is stable enough to be declared official.

Priorities

Given all the back-log of features to integrate, and the consequent knowledge that the current release of Hugin is short lived and a newer, better one is just around the corner, why put the effort to produce a Windows installer that will be obsolete soon? Of course ideally the installer should track closely the development, but it seems to be too much effort at the moment. At some point, the gap between the installer and the code will be deep enough to attract more attention, and somebody may be motivated to provide a Windows installer.

Give a Man a Fish

Groundhog protecting his holeSo the Hugin project team released 0.8.0 three weeks ago. What are the expectations, and what does release actually mean?

Some users, particularly in the Windows world, expect the release of a shrink-wrapped product. They expect to click, download, install, use. And of course everything for free.

Easy? Not so quick. What was actually released is nothing more than a tarball, an archive of the source code in a state known to build and work on the major supported platforms. So it could be used to produce executable binaries.

How are those binaries produced? What do they depend upon? What is to be produced? Who does it? How are they distributed? What is missing?

How

The user community has prepared platform-specific instructions. They may not be perfect but do the job.

Dependencies

There are some dependencies that need to be fulfilled for the recipes to work. Besides the obvious ones of enough disk space; a supported operating system; and installation of the building tools, Hugin 0.8.0 depends on other software packages, both at build time and at run time.

On the Ubuntu package description the dependencies are clearly listed. They are roughly the same for all platforms. They include enblend, enfuse, libpano.

What

On most Linux based systems a package manager takes care of the dependencies. This means that the packager only has to build Hugin-0.8.0 itself. The package manager will download and install the appropriate dependencies.

On OSX and Windows there is no package manager. The Hugin-0.8.0 binaries alone are useless. The packager has to do extra work.

Who

Anybody with access to a computer can act as a packager, use the instructions and the tarball to produce executable binaries and do whatever they want with it. It’s free.

Distribution

Anybody can put up the binaries for download anywhere on the internet. In the download section of this blog there are links. On top of that there are two distribution channels with special meaning: the package manager and the official Hugin download page.

The package manager is responsibility of the Linux distributors. They carefully test and approve each package that goes into their distribution. And they don’t backport often. For example, Ubuntu still supports its 8.04LTS distribution until April 2011 for desktops and April 2013 for servers, as well as 8.10, 9.04 and the upcoming 9.10. As of today, the binary of Hugin distributed by the package manager for Ubuntu 8.04LTS is Hugin-0.7.0_beta4. Users of Ubuntu 8.10 are still served with Hugin-0.7.0_beta5. Users of the most recent Ubuntu 9.04 have access to Hugin-0.7.0 binaries. And for the upcoming 9.10, Ubuntu’s plan seems to be to still ship Hugin-0.7.0. We hope that this will change but it is not up to us to change this.

Dependencies Revisited

Specifically, there are three dependencies that currently cause pain. In order of importance:

  1. Enblend and enfuse are mandatory. Without them, Hugin-0.8.0 does not work. The current enblend and enfuse packages have serious problems, causing them to crash. They are a regression compared to previous CVS snapshots, in particular to those versions delivered with the old Windows SDK and with the Hugin-0.7.0 installer for Windows. There are fixes in the staging branch of enblend-enfuse. And Harry has been using that branch to build the OSX Hugin-0.8.0 bundle until his Mac died.
    Unfortunately the staging branch does not build in Windows yet. I researched the problem and fixed part of it (accepted as revision 347 by Christoph Spiel on August 3). Thomas Modes had a look at it before going to holiday and added some more pieces to the solution. But it does not build yet because of Microsoft’s Visual C++ quirks.
  2. Libpano is mandatory. Until recently libpano had a minor but annoying problem: it reverted the language of the user interface to English. Daniel M. German and Thomas Modes solved it in the repository.
  3. A control point generator is a critical. Until recently the autopano-SIFT-C package had serious problems, causing memory leaks and crashes; failing where the previous version bundled with the 0.7.0 OSX bundle and Windows installer succeeded.

On systems with package managers (i.e. Linux) the packager can simply publish Hugin-0.8.0 and rely on the package manager to solve the above listed issues. For systems without package manager the packager must add them to the bundle/installer or to the SDK used to build it.

Distribution Revisited

Distributing a binary that is known to have a regression over previous versions as official release is bad practice. It not only affects the project reputation, it ruins a working system for those users who overwrite the working version with the newer one.

The OSX Hugin users community fixed the problem and an official OSX binary is available from the Hugin site. There is no solution yet in sight for Windows, so currently Windows users are directed to the 0.7.0 installer. Maybe we should direct them to the tarball instead?

Conclusion

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime. This works with most of our users ond most supported platforms.

Unfortunately for some Windows users it does not seem to work. Give them free fish and they will come for more. Give them the freedom to feed themselves and they will ignore it.

Bad News For Mac OS X Users

Apple under the ShowerHarry van der Wolf has been a steady contributor to the Hugin project for more than two years. Due to circumstances beyond his control he can no longer feed the Mac user community with current snapshot builds of the latest and greatest Hugin and related tools. This comes at a critical time, with 0.8.0 so close to release. David Haberthür has offered some help, and we could use your help too! If you have access to a Mac, here is where to start. Let the community know how far you get and if you need help. Thank you.

Almost ready

Two weeks ago Bruno initiated the next round of clean up. He went through the massive task of reviewing each and every pending bug, cleaning out many outdated or duplicate reports. He brought the list down to 82 bug reports.

There are feelings in the wider community that the current hugin is ready for a release, so what do we need?

A small informal discussion unfolded off-list amongst developers, debuggers and builders. The consensus is that we need to stay focused on the bug tracker, group the bugs into manageable clusters and address them in a relatively fast series of incremental releases.

Bruno assigned to the 0.7.0 category those bugs that need to be fixed now for the release, leaving the rest for later. His approach, supported by everybody, is that we should prioritize for the upcoming release those bugs that lead to crashes, and then those that lead to many support requests.

Gerry started working through the bugs. His practical approach already yielded a few quick fixes, and he is introducing sanity checks to prevent some of the reported crashes. Pablo has been busy making the control point list more responsive and ensuring the code base builds with different versions of wxWidgets on the many supported platforms.

Harry refined his documentation of the OSX builds and Michael Galloway reproduced the build.

On the Windows side I have been slacking with the builds but Guido and Tom have been relentlessly releasing binaries to testers.

I have submitted a patch with two simple improvements to enfuse / enblend. The patch has not made it yet into SVN. I may include it in my next installer. The two improvements affect details of the pyramid blending – specifically the resolution of the last step of the pyramid and the number of levels used in the pyramid blending, both requested by Erik Krause.

Somewhat, the moving target has become too comfortable. From my perspective hugin works well enough. The installers I have been publishing here in the past three months met the quality requirements for a release, especially when compared with what I see released from other open source projects and even from commercial entities. But there is no question: we need to get an official release out soon.