• 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

    December 2017
    M T W T F S S
    « Dec    
     123
    45678910
    11121314151617
    18192021222324
    25262728293031
  • Archives

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?

Hugin 2010.2.0 is out

Hugin 2010.2.0 has been released more than a week ago.  I was traveling when Bruno made the announcement officially sanctioning the second release candidate, moving new features such as mosaic mode and masking one step closer to the user.  But this is not the last step.

As usual it is a source-code only release.  Contributors will build binaries out of it that will eventually trickle down the official distribution channels in the coming weeks and months.  As usual the beggars are faster than the contributors.

While the project strives to make user’s life easy with binaries, the only way to release source code and binaries for all platforms at the same time would be to introduce an artificial delay in the release process, which in my opinion is a very bad idea trying to creep in from the world of proprietary software.

There is a natural sequence of events before a new feature hits the user’s desktop:  first there is source code, then it is compiled, then it is tested.  When the tests are conclusive the source code is packaged and distributed to builders who compile user-friendly installers for distribution.  It does not happen overnight.  The source code is naturally ready before any binary.

Marketing controls the release process in the world of proprietary software.  Everything is done in secret.  The effort of keeping everything under the radar screen until a big-bang launch is justified by the resulting publicity and boost in sales.  Everything is delayed until the launch campaign is ready, the product is ready, the distribution channels are ready.  The release announcement is made with the sole purpose of motivating consumers to buy.

It is the opposite dynamics in Open Source.  Delaying the source code release until all installers for all platforms are ready to ship only hinders progress.  It is better to let the developers move on with further improvements rather than freeze them while waiting for a synchronized release.  Since we don’t sell the software, there is little benefit to such synchronization.  Builders and distributors will take care of the details of producing binary installers for the end-user asynchronously in due time.

Open Source development is a continuum.  Strictly speaking, every time a developer pushes a changeset into the repository he is making a “release”.  He is releasing his newly add code to the general public.  There is even an RSS Feed of such releases.  It’s interesting to developers and others that are threading on the bleeding edge, but to the average user this is mostly boring overload.

The purpose of a release cycle is to motivate contributors to polish up their contribution – whether they are code, translations, manuals, tutorials, installers.  The release announcement is the point where the focus of the release cycle shift from code/bugfixes to preparations for distribution.  Stay tuned for binary distribution to start as soon as possible.

Linear Panoramas (Mosaic) Tutorial

Another development cycle is coming to an end.  Bruno released libpano13 2.9.17 and paved the way for Hugin 2010.2.0.   This version of Hugin will bring a lot of new features, amongst others a versatile masking tool and finer grained control of the control point (CP) detection process, courtesy of  Thomas Modes.  Good news for Windows user as well: galvanized by Emanuele Panz and his new NSIS based installer that solves the issues with distribution of patented software, also the Windows users community is on the forefront this time.

Time to do some cool stuff with Hugin:  mosaics.  The basic functionality for mosaics has been in the repository for about a year, and it has matured well.  This morning I set out to shoot and stitch a mosaic.

Stitched mosaics differ from traditional stitched panorama in two major ways:

  • In an ideal mosaic, all images depict a single, perfectly flat subject.
  • The images are taken from different points of view.

Mosaics present a few challenges of their own.  Think of them as protrusions and intrusions from/into the perfectly flat imaginary plane that you are trying to shoot.

Shooting

Not much is flat in the real world.  If parallax prevented seamless concordance in a traditional stitched panorama, depth and perspective prevent seamless concordance in a mosaic.  While parallax can be almost completely eliminated with accurate camera positioning on the no-parallax point, perspective is a given and will be with us throughout the process and into the finished product.  You need to be aware of it while shooting a mosaic more than you need to be aware of moving objects when shooting a stitched panorama.  The tools to deal with it are the same: overlap (plenty!); masking; and, inevitable in this case, retouching/editing.

For this kind of shooting, I first walk parallel to the subject watching how protrusions and intrusions  move relative to the imaginary ideal plane as I move along.  I look for vertical (not necessarily straight)  lines in the plane that could act as stitching seams, i.e. will be unencumbered by protrusions in two adjacent shots.  If I can’t find such a virtual seam line I will have a hard time masking and retouching the seam.  In a second pass I shoot images straight at the subject, one between every pair of the still virtual seam lines, with a lot of overlap.  In a third pass, I take pictures at different angles to “get around” protrusions such as trees that hide areas of interest of the subject.

All images were shot hand held.  Like for traditional panoramas, constant exposure and color are important.

Order

I found that order matters.  I get best results when starting from an anchor image in the middle of the mosaic and working my way to the edges.  To simplify the work flow, once the images are loaded I re-order them in the Images tab, making sure the anchor image is the top one.

Setting the Stage

Start a recent version of Hugin.  You will be switching forth and back between the main window and the fast preview window, so if you have two displays, open them side by side.  Unlike Terry Duell’s suggestions I found that it is not necessary to add images individually to the project, but a little bit of pre-planning is necessary.  There will be some inevitable forth and back as this is an iterative process.

Generate Control Points

Bad news first:  you most likely will have to enter CPs by hand.  That said, it’s easy.

It is paramount that all CPs are on the same plane and no currently existing CP detector known to me meets the condition.  Even small depth errors (e.g. relief on a wall) has big impact.  Avoid CPs between non-contiguous images.  Three or four well distributed (i.e. not on a straight line) CPs are enough.  If vertical lines are present, add one vertical CPs on each image that has them.  Conceptually, the three corners of a triangle in space are enough to define a plane and you are looking to define the common plane between two images.

Start with a Calibrated Lens

I found mosaics optimization to be much more sensible to the starting parameters than spherical optimization; and the outcome to be much more sensible to lens distortion than traditional panoramas.  Get lens distortion out of the way before starting.  If you have saved calibration data for your lens load it now.  Else, here’s a quick fix.

In the Fast Preview window:

  • Hide all images but one with plenty of lines that should be straight in the real world.
  • Select rectilinear projection.
  • Center the preview on the visible image and zoom in on it with the field of view (FoV) sliders.

Your goal is to make straight lines look straight, and the Fast Preview window will give you valuable visible feedback. In the Control Points tab, set a few line CPs:

  • Select the visible image into both the left and right panes and start adding CPs on lines.
  • For vertical lines, click on one end of a vertical line in the left pane and on the other end in the right pane.
  • For all other lines do the same, but check that the CP-type drop down says “another line” and the table says “line” and a number.  The name of horizontal CPs is misleading.  Horizontal lines are to identify the horizon itself, not lines parallel to it.

With six well distributed lines you can already get a good approximation.  In the Optimizer tab:

  • Select to optimize “the custom parameter below”
  • Select “only use control points from images visible in the preview window”
  • Deselect all parameters
  • Select only Pitch and Roll of the above image
  • Run a first optimization (and adjust the view in the Fast Preview window if necessary)
  • Deselect all parameters
  • Select Barrel
  • Run a second optimization
  • Select Pitch, Roll and Barrel and optimize them all
  • Now deselect Barrel, and leave the lens parameters alone

There is more to proper lens calibration, but this should be enough approximation for the project at hand.  Confirm visually that the lines are straight in the Fast Preview window before continuing.

Start from the Center

Start with only your anchor/calibration image visible  in the middle of the Fast Preview (in rectilinear projection) and all other images hidden.

In the Optimizer tab:

  • Select to optimize “the custom parameter below”
  • Select “only use control points from images visible in the preview window”
  • Optimize for Pitch and Roll of the anchor image.  Make sure it’s X/Y/Z parameters are 0 (in the Images tab).

Optimize Image after Image

Repeat the following for each image, always verifying the visual result in the Fast Preview after each optimization.

In the Fast Preview window:

  • Visually check that the current result is approximately OK
  • Adjust the FoV sliders if necessary
  • Make the next image visible

In the Images tab:

  • Select the image that just became visible in the Fast Preview window
  • Edit it’s X value.  Enter a negative value if it is to the left or a positive one if it is to the right.  Over time you will get a feel for the magnitude.  Start with +/-1.  Make sure it is roughly positioned where it belongs, slightly more to the outside than to the inside.

In the Optimizer tab

  • Select to optimize “the custom parameter below”
  • Select “only use control points from images visible in the preview window”
  • Optimize for Yaw, Pitch,  Roll, X, Y, Z of the newly visible image

Repeat for all images.  At the end do one more optimization run, optimizing Yaw, Pitch, Roll, X, Y, Z for all images but the anchor image, and only Pitch and Roll for the anchor image.

Improve Slowly

This is a step by step, image by image process.  And we’re not finished yet.  You may find that the project needs further tweaking.  It’s not an issue of mathematical precision but rather one of controlling the position and warping in critical areas where the different perspectives from the different pictures collide.

Terry suggested dragging the image in the Fast Preview window instead of the above step in the Images Tab.  And indeed the Fast Preview has a Move/Drag tab with mosaic mode.  Unfortunately dragging an image will automatically drag all other images connected by CPs, so unless you do this only once before adding CPs, dragging won’t work. I found the way through the numeric input in the Images tab to be preferable.  It enabled me to go back and rework the positioning of individual images without losing the work done on CPs.

Move/drag in the Fast Preview window is useful associated with cropping functionality.  I use manual cropping in this case, it’s fast and intuitive.  When the mosaic looks good in the Fast Preview window, head to the Stitcher tab and render it.  Make sure to output both the blended panorama and all remapped images by checking the appropriate check boxes.  Hit the Stitch Now button, enter a prefix and go get a deserved break while the computer churns away.

Masking

Hugin has a built in masking tool.  Masking in the input images is more useful for panoramas than for mosaic, because in a well shot panoramas it is reasonable to assume that the images align naturally and the masking is only needed to exclude / include details.  With mosaics, the assumption is wrong, and I prefer to do masking in output images, already warped and aligned, together with editing and some other unspecified fiddling to achieve a visually pleasant result.

Post Processing

Below is a scaled rendering of the blended mosaic.  No post-processing applied yet.  The original is about 21.000 pixels wide.  It’s not bad, but “perspective collisions” are visible at the seams and will require retouching.  It’s time to prepare the project for your favorite image editor.

Copy all the rendered images into a single TIFF file.  On the command line, enter:

$ tiffcp prefix* layeredmosaic.tif

Open the resulting file with Gimp.  The layers will be perfectly aligned.  Add mask layers to them and start editing, or export to a Photoshop file if you are more comfortable with that image editor.  My Photoshop CS 2 (quite old, but still does the job) is not able to open properly the multi-page TIFF file.

Improvements

This was a quick proof of concept / tutorial.  If I was to do something serious with this image, I would probably re-shoot it, taking advantage of the building regularity and adding more images, one in between every pair of columns.

Conclusion

Reaching this advanced stage in the image creation process was relatively easy with Hugin.  Now, depending on your level of perfectionism and intended purposes, there are still hours of editing ahead before the file can be declared good to print.  I don’t have enough wall space available for this 3.5m / 11 feet long mosaic.  If you have and are interested in this or similar commissioned work, I’d like to hear from you.

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.

Hugin Participates in Google Summer of Code 2010

Congratulations to Bruno, James, and Tim, for doing all the legwork and getting accepted for a fourth participation to this Google initiative that helps attract new talent to Open Source projects.

Hugin will be accepting candidates, and it is never too early to join. You can read some advice on how to apply in past posts to this blog tagged Google Summer of Code.

I won’t be part of the mentoring organization this year. Our family is currently in transition and I don’t have any spare time. I look forward to post a panorama of our new home, roughly 1000 Km further West, but our schedule is slippery as well.