• 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

    August 2009
    M T W T F S S
    « Jul   Sep »
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • Archives

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.

7 Responses

  1. Give a man a blog and he will be pathetic

  2. Thank you for the explanation, Yuval. Many of us Hugin-on-Windows users have been wondering what the case was. Some of us do have some grasp of the difficulties that can be presented on platforms where there are no package management systems, but actual details on what some of the obstacles were to win32/win64 versions being available were not easily found – aside from the more obvious ones like the legality of building and distributing patent-encumbered portions like autopano-sift-c from the US – even if we monitored parts of the developer forums. This information is quite useful.
    Thank you again.

  3. I can remember when some of he things Hugin does today were theoretical fields of study. The current stable binary for Windows is Hugin-0.7.0. It works wonderfully, where’s the issue? Thanks for the explanation, but the solution is really pretty clear. You want the stable binary then download it and use it and quit obsessing about the version number.

  4. @fenstermacher: you’re right, Sam. 0.7.0 is perfectly useful. We added some nice things to 0.8.0, though, such as the fast preview. It seems that some users can’t wait for the official windows binary, and a vocal minority of them who can’t help themselves despite the plenty of help available, including links to bleeding edge snapshot 0.8 binaries on the downloads page of this blog, have made enough of a fuss about us “developers who don’t care” to trigger me.

    BTW, the website linked from your name is a wonderful collection of interesting travel articles about this area of the world I’ve not visited yet. Worth visiting – both Texas and your blog!

    @Derek: Happy you found the information useful.

    @prokoudine: Sorry to see you had a bad day. Isn’t that a blog, linked from your name? it can happen to everybody ;-)

  5. Thx for the explainations, Yuval. I just found your page while digging for the “Hugin-0.8-Windows” answer. Now I know it.

    Concerning the fish – I cannot share your opinion. Of course, if I can program, I can create (almost) any tool I want. But why are there not only tutorials on programming and examples (single fishes) but complete programs in the net? Yes of course, the time it would take…

    For me as developer it is no big thing to load sources and compile them – neither Windows nor Linux. In spite of this, it ain’t pleasant for me. Hugin is an end-user product, not a developer package. So why do I need to deal with compiling sources? No one understands why he needs to learn compiling while he wants to build a panorama.
    Why do I need to know how to grow an apple if I want to eat one?

    In my opinion it would have been better to anounce only the Linux release. Making Windows users assuming that a Windows release is available is not much better than providing a buggy Windows release. Users of Hugin are photo guys, not software configuration management staff.

    Look at the Lame-MP3 team. They release source only, right because of the platform issues I guess. So when I want Lame, I see that I will not find binaries on their page. That’s consequent, and they explain it clearly.

    Please don’t understand me wrong. I like Hugin and have a lot of respect for the developers who spend their spare time for the project. My comment is meant to be helpful not to anger anyone!

    Have a nice day

  6. Sorry, but in the thread you linked I read something like:

    “… hugin-0.8.0.tar.gz is what the
    Hugin developers team released. It is source code that has been
    superficially tested to build on the supported platforms …”

    A release which has been “superficially tested to build” is something that hurts bad!
    I’m not better than the average windows user, but I’ve managed to compile both GIMP and PostgreSQL from source following their instructions just because they went a bit further than “superficially testing”, even if their main development platform is not windows.

  7. @Danilo: Two misunderstanding.

    1. You seem to imply that “to fish” is “to program”. My point is that you determine for yourself what your “fish” is. “Digging” is synonymous for fishing in your case. You ask a question and you find the answer by yourself. If the question is “where do I find Hugin windows binaries?”, Google is your friend. If the question is “why there is no official 0.8.0 windows installer for download on Sourceforge?” the answer is in comparing the official 0.7.0 windows installer with one of the many unofficial snapshot installers available (some of which are even more bleeding edge than 0.8.0).

    2. You say it would have been better to announce only the Linux release. This is wrong. We released source code that builds on Linux, Windows, OSX by following the appropriate instructions that are delivered with the source code itself. We did not release binaries. Not even for Linux. You seem to imply that “release” = “shrink wrapped software”. For a rock band, release can be a song or an album. For a movie studio it can be the opening of a film in theatres or the availability of the DVD in stores. For us it is the availability of the source code that builds on all platforms.

    @pabloj: You’ll manage to compile Hugin from source following our instructions because they are at par with GIMP and PostgreSQL; and on the mailing list we do help people who help themselves. It all depends what your definition is of “superficially testing”. IMO there are very few volunteer efforts that can claim to have anything other than “superficial testing”. For commercial software much less complex than Hugin the budget for proper testing runs quickly in the six digits and takes an amount of resources that we don’t have. I doubt GIMP has them – and GIMP has a much wider audience than Hugin. I don’t know about PostgreSQL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s