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

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. I believe that after many years of using various calibration systems, photogrammetrists finally decided the straight line method was best. And they often use naturally occurring straight lines rather than special calibration rigs. The key is software that can follow lines and estimate their positions to subpixel accuracy. The raw image of a calibration line will in general be curved, so a human has to designate which lines are straight in reality -- but not set dozens of control points on them."