Development of Open Source tools

Panorama Related Open Source tools

• Hugin
• Enblend
• Enfuse
• Panotools

Contribution

Why contribute?

The above tools are free for you (and every other user), because volunteers have contributed their skills and time. They provide immense value to the whole community. They provide value to you, don't they? If they do, please consider contributing something back.

How to contribute?

Join the hugin-ptx mailing list to find out what is going on at the moment and how you can help.

If you don't have time, you are most likely a busy professional. You can donate money to Hugin, Enblend/Enfuse on their project pages through Sourceforge.

At the time of writing (03-February-2008) the building process of hugin is robust and we are looking for testers to go over bug reports and test them against the regular snapshot builds.

Don't be afraid of failures in the building process

• The likelihood that errors will occur when following the build processes linked below is high.
• Don't worry such failure will not compromise your computer.
• The failure of the building process is actually your success! Every time you report such a failure, with as much detail as possible to how it came about, you are contributing to the progress toward a stable release.

If you are fluent in other languages than English, you can help translate Hugin. There's a Hugin translation guide to help you get started or help when you run into translation problems.

Hugin 0.7.0 release schedule

Clearing the bugs in the sourceforge bug tracker is an iterative process. Feedback from tester is essential for this process. Please take the time to check if the older bugs apply to a current snapshot, if you like to see a release soon.

We'll be releasing frequent snapshots until a release candidate emerges. This is an iterative process:

1. Volunteers check the bugs listed in the sourceforge bug tracker under group v0.7.0 against the most recent snapshots (scroll down on that page).
   • Install the latest snapshot.
   • Try to reproduce the bug on your system.
   • If you find that the bug no longer occurs, chances are that it has been fixed. Close it (assuming you have the required access), or simply leave a note that it has been fixed (together with the SVN revision and the system used for testing).
   • If you reproduce the bug, leave a note to confirm that it is still actual. Note the SVN revision and the system used for testing.
   • Try again. If you can consistently reproduce the crash more than twice, raise its priority to 8. Post detailed instructions how to reproduce the crash.
   • If you can confirm a bug a bug that is older than 3-4 months, please raise its priority to 6. If it is a real show stopper.
   • Add any comments you have to the ticket in the bug tracker. Let the community know you have tested. The bug-tracker is like a mailing list or forum thread, don't be afraid to post.
   • If you don't want to open an account with Sourceforge, post your observations on the hugin-ptx mailing list. It is possible to post comments to the bug tracker anonymously, but it is e
2. The developers fix the bugs identified in the tracker.
3. The builders build new snapshots including the fixes.

We'll repeat this process to deal with:

• functional bugs: to make sure that the program does what it is meant to do
• GUI bugs: to make sure that the user has full access to the program's functionalities
• stability bugs: to make sure the program is robust and does not crash

After the GUI bugs have been fixed

• a string freeze will be issued to allow translators to prepare the translations. The string freeze will be announced on hugin-ptx and on this page.
• a first release candidate will be issued to allow for robustness testing.

Current Status

We have started to systematically look at the bugs in the bug tracker.

This list is incomplete based on testing svn2733 running on OSX. Thank you, Klaus!

showstoppers blocking 0.7.0 release

Please collect bugs (must be in tracker, include link) that must be fixed before 0.7.0 can be released.

• crash on undo/redo load project 1803962
• ...

ought to be done 0.7.0

• get the Option buttons working in the Stitcher tab
• reduce image size to image content size for Stitcher cropped output
• prevent modification of exposure information on merely clicking tabs

may be done for 0.7.0 if easily implemented

• interpolator selection
• flatfield file

• correct top grey rim in enblend , however --fine-mask option is workaround

release 0.7.x

• include antialiasing interpolators

release >0.7

• lots of GUI items i.e.
  • histograms for intensity and RGB
  • mass handling of Control Points, specify areas where (not) to put them

Download Test Build

If you want to contribute testing but you don't want to go through the hassle of building the code, you can find the latest installer download for Windows and OSX here.

Build your Own Test Builds

If you are ready to go through the building process, here are the instructions.

IMPORTANT:	These builds are for your computer. If you decide to share them with others, be aware that you are subject to the GPL, and that the general public may need guidance regarding what you distribute. Read the information in the packaging and distribution section below. If you are unsure, ask on the hugin-ptx mailing list for advice before posting a file for download.

Goal

an infrastructure for on-demand build and distribution of usable test-binaries for the most popular platforms. These builds are meant to enable users to test the newest features and report bugs. Ideally, on Pablo's demand all those who have a build chain will run it against the newest source code to produce the builds.

Process

1. Experienced users will build the most current hugin and helpers (libpano, enblend, autopano, etc.) for the target platform of their choice, with support from coders.
2. The build process will be documented for each of the supported platform.
3. Users willing to spend some time learning how to build will reproduce the documented process.
4. Power users will script and automate the building process.
5. Users with packaging skills will package the builds for distribution (installers).
6. The produced binaries/installers will be made available on the web.

Specific revisions

When building from the repository, some revisions have bugs. This process is meant to build the latest revision so that if the latest revision has bugs these can be identified and corrected. However sometimes these bugs can be more critical than other times. If you need a more or less working version of hugin, try applying the process to one of the following revisions.

hugin

Revision	Comments
2801	builds on Windows, used for Windows installer snapshot. Builds on ubuntu 7.10 AMD64
2797	builds on OSX, used for OSX snapshot package.
2766	Windows self-installing archives. [1] "TKSpwd1"
2733	build on OSX. runs on Macs that have no programming packages installed.

older hugin revision notes

libpano

Revision	Comments
785	builds on ubuntu 7.10 x86 32bit
770	does not build [2]
767	does not build [3]
759	builds on AMD64 ubuntu 7.10

older libpano revision notes

enblend

Revision	Comments
2008-02-07	builds on ubuntu 7.10 AMD64, OSX (used for snapshot package), Windows (used for first snapshot installer)
2008-02-03	builds on Windows and ubuntu 7.10 x86 32bit

older enblend revision notes

Supported Platforms

• If you don't find your preferred platform listed below and you are willing to contribute your time and skills to build hugin on it, feel free to add it to the table. We will accommodate any well supported platform in the regular release process.
• The Build-Chain Responsibles listed below have access to a build chain on the selected platform and have agreed to run the build chain within 2 days of a request from Pablo. They will forward the resulting binary package to the Release Manager who will in turn put them up for download by the general public.
• Redundancy is good. If you have access to one of the listed platforms, please try to run the documented process below and report success to hugin-ptx. If you think you could do this on a more regular basis, enter yourself in the Backup Build-Chain field.

Platform	Status	Process	Build-Chain Responsible	Credits	Backup Build-Chains
ubuntu 32bit	tbd	OK	tbd	Sébastien Perez-Duarte Yuval Levy Régis B.
ubuntu 64bit	tbd	OK	tbd
Fedora 32bit	tbd	tbd	tbd	Bruno Postle
Fedora 64bit	tbd	tbd	tbd
OSX IntelMac	tbd	draft	Peter A. Crowley	Ippei Ukai JD Smith Daniel M. German Peter A. Crowley David Haberthür John Riley Roger Howard
OSX PPC	tbd	draft	Peter A. Crowley
Windows 32bit	tbd	OK, SDK based draft, from scratch	Tom Sharpless	Tom Sharpless John Navas Jean-Marc Paratte Yili Zhao Yuval Levy
OpenSuse 32bit	tbd	tbd	tbd	Kornel Benko (10.3) Peter Suetterlin (10.2) Stephan Hegel (10.3 x86_64)
OpenSuse 64bit	tbd	tbd	tbd
FreeBSD 32bit	n/a	n/a	Vasil Dimov, FreeBSD port maintainer	confirmed to build on FreeBSD 6.2/i386 confirmed to build on FreeBSD 7.0/amd64
FreeBSD 64bit	n/a	n/a
all platforms	a big thank you to Pablo d'Angelo for supporting all of those building efforts.

Stati

Build Chain

• tbd: looking for responsible
• OK: mostly automated build process ready on request
• unavailable: temporarily unavailable (e.g. responsible on holiday)
• HW-broken: the hardware is temporarily unavailable
• SW-broken: temporarily dysfunctional, working on a fix
• broken: nobody is working on a fix
• unsupported: has been dropped for lack of support

Process

• tbd: status unknown
• auto: work as documented and has been automated to a reasonable extent
• OK: works as documented, could use automation / scripting
• draft: documented, needs validation / testing / cleaning
• incomplete: parts are missing (e.g. enblend, libpano)
• outdated: worked in the past but needs an update
• obsolete: nobody has the time to update

Packaging and Distribution

Instructions for packaging binaries for distribution will follow. Some important points:

Snapshots

• comply with the GPL
  • join a text of the GPL in the distribution
  • give access to the source code
  • credit the authors
• label clearly the snapshot as such, with a reference to the build date and/or the SVN revision number
• edit the text / readme files that come with the snapshot
  • indicate clearly that it is unstable, experimental software
  • indicate where to find the latest version
  • indicate that the advertised features might or might not work

Release

• comply with the GPL
  • join a text of the GPL in the distribution
  • give access to the source code
  • credit the authors

Feedback

When running through the building process documented above chances are that something goes wrong. While it is disappointing when the process ends in a flurry of cryptic error messages it is not harmful. This is the nature of software development and you are now part of it. There is still a lot of value in your experience and you can help improve the process and get closer to the hoped for software package. Please don't be ashamed that it did not work. This happens even to the most expert coders. Give the developers feedback on the hugin-ptx mailing list. Only with your feedback they can know that something goes wrong, and a well crafted feedback helps them find out quickly what went wrong and devise a solution. Be a part of the solution, not a part of the problem!

To give good feedback, note down carefully all of this information while you are going through the instructions.

1. details about your computer. CPU, operating system, other particularities
2. the revision number of the code checked out with SVN (which appears at the end of the checkout process) or with CVS. Or, if you don't find a revision number, the date and time when you checked out the code.
3. the last step / command you entered into the command line
4. a copy of the last few lines displayed, from where you think the error messages started. Don't worry if you copy a couple of lines too many, it is better to give more lines than less lines.

Even the standard feedback is good feedback. For those wishing to dig deeper, you can try

• to use "make VERBOSE=1" when building hugin.
• to do a debug build "cmake -DCMAKE_BUILD_TYPE=DEBUG" and use oprofile for profiling.