Historical:SoC 2009 idea

Introduction

If you are a student willing to participate in The Google Summer of Code 2009, do as suggested below:

• find out what ideas we have for SoC projects this year (read below);
• make up your mind, if you want to pick one of those tasks or if you have your own idea;
• join our community at hugin-ptx;
• introduce yourself and tell us about your plans and wishes.
• add your proposal to the student proposal page - see examples from last year

IMPORTANT: at the time of writing it is not known yet if we will be admitted to Google Summer of Code 2009. We can not guarantee you a place in the program, but we recommend you start preparing your application early as the application process is very competitive.

Development style

Most of the projects below are related to Hugin, and some also relate to Panotools or tlalli. Hugin is mostly written in C++, and uses the VIGRA image processing library to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs (nona, fulla). We also very much welcome contributions to Enblend/Enfuse.

The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).

Mentors

The following people have volunteered to be primary mentors:

• Andrew Mihal
• Bruno Postle
• Jim Watters
• Daniel M. German
• Tom K. Sharpless
• Tim Nugent
• John Cupitt

The following people have volunteered to be secundary mentors:

• Pablo d'Angelo

Application Template

SoC2009 Application Template

Possible Projects

We welcome you to propose your own ideas.

Some of the SoC2007 projects and SoC2008 projects proposals were not done in the past years and are potential projects for this year:

• SoC2007_projects#Interactive panoramic viewer (This was completed but there is further possible work to be done, particularly a joint project with VLC to integrate the viewer in their media player)
• SoC2007_projects#Processing of very large images (using the VIPS framework, or even GEGL if ready)
• SoC2007_projects#Architectural Overhaul of Panotools
• SoC_2008_ideas#munin_.E2.80.94_interactive_openGL_based_GUI
• SoC_2008_ideas#enblend-enfuse_zenith.2Fnadir_and_more
• SoC_2008_ideas#Ghost_removal_for_enfuse
• SoC_2008_ideas#Lens_Database (the library part is done, see lensfun, but there is still no system for updating the database)
• SoC_2008_ideas#tCA_Correction (this is done, the tca_correct tool now exists in the hugin-0.7.0 release)
• SoC_2008_ideas#Extend_hugin.27s_output_options_for_stitching
• SoC_2008_ideas#Utility_for_creating_a_Philosphere

Python Bindings

expose all functions / libraries as Python bindings

3D extension of panotools library

the current assumption of panotools is that all images are shot from the same point of view in a different direction. develop and implement the mathematics to adjust for a shift in the point form which the pictures where taken.

enblend/enfuse gimp plugin

Various GUIs for enblend and enfuse already exist (e.g. ImageFuser), however nothing that would as useful as a gimp plugin. e.g. gimp opens multilayer TIFF files created by hugin and other tools, an option to 'blend visible layers with enblend' would allow manual adjustment of masks during blending.

bracketing pano model

Currently the Hugin pano model has no provision for brackets / stacked images. This project would modify the pano model to make provision for image stacks to be considered as a single image or to be optimized locally as a stack before being optimized globally as a panorama.

hugin RAW support

hugin is never going to be a RAW converter with all the options of a tool such as ufraw, so I would be wary of adding half-baked RAW support to hugin that produced second-rate results.

Something that ought to work very well would be if hugin/enblend could support RAW output, specifically 'linear DNG'. In this workflow, hugin would import RAW via dcraw as 16bit linear data with no correction. It would then output linear DNG files which could be opened in any RAW converter for further tweaking.

This would be a good summer of code project: modify hugin to use dcraw as an input plugin, integrate TCA correction, modify enblend to write linear DNG (or create a standalone tiff2dng tool), modify hugin GUI to enable it, fix any ufraw bugs reading linear DNG.

hugin colour balancing

Internally hugin uses the EMoR photometric model. This means that adjusting the colour balance in hugin by altering the red/blue channel multipliers will give better results than doing the same in an image editor such as the Gimp/Photoshop - Provided the photometric parameters for the camera are calibrated properly. There is potentially unexplored interesting stuff that can be done with this capability: grey pickers, temperature sliders, curve adjustment etc...

A related problem is that hugin has an internal 'lens' representation that it used to link lens parameters for different photos together, this capability really should be split into three models: lens grouping photos with the same lens but potentially different CCDs, sensor grouping photos with the same CCD but potentially different lenses, position stacked images that can be rotated together (see #bracketing pano model above) - This is tinkering with hugin fundamentals and needs to be overseen by Pablo.

Straight-line detection for automated lens calibration

One of the techniques for lens calibration is to optimise straight lines. Tom Sharpless suggests: "Hugin needs an easy and reliable way to do straight line lens calibration. After many years using various calibration systems, photogrammetrists seem to have decided the straight line method is best. It is robust, accurate, and can often use naturally occurring straight lines rather than special calibration rigs. And it works well with fisheye lenses, which many other methods do not.

The key is software that can automatically follow strong "line-like" curves and estimate their positions to subpixel accuracy. Then, using a reasonable model of the lens, an optimizer like the one in Hugin can fit parameters that straighten the lines. Since the raw images of calibration lines are generally curved, a human may have to designate which lines are straight in reality. However, fully automatic straight line calibration is theoretically possible, based on jointly optimizing lens parameters and estimated line shapes.

A tool of this kind would be especially valuable for calibrating fisheye lenses, something the PanoTools family of s/w has always done poorly. Part of the problem is that the original PT library used the equal-angle model for fisheye lenses, instead of the equal-area model most modern fisheyes are actually designed to. Apparently libpano13 now has the equal-area model, too, but Hugin continues to use the equal-angle one. So an important part of this project could be to revise Hugin to handle fisheye lenses more correctly.