Historical:SoC 2008 ideas

Introduction

If you are a student willing to participate in The Google Summer of Code 2008, 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.

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 development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).

Possible Projects

Some of the SoC2007 projects proposals were not done last year and are potential projects for this year.

munin — interactive openGL based GUI

Possible Mentors:

• Pablo?

Description:

Intuitive and interactive GUI, with priority in usability over available features and flexibility, based on what users should see — not on what software does internally.

Skills:

• C++
• Qt4
• OpenGL

Discussion:

how about relaxing the skills, and instead of fixing on Qt4 work on a combination of high level scripting language and widgets? Phythons + wxWidgets or Lua + wxWidgets come to my mind. Right now we have the option as both wxWidgets and Qt are in trunk, and if the student codes those widgets that require speed in OpenGL so that they integrate into such an API, any scripter can then leverage them for the fast and efficient design of GUI. Yuval 12:50, 4 March 2008 (CET)

enblend-enfuse zenith/nadir and more

Primary Mentor

Andrew Mihal

Description

• implementing blending of the zenith and nadir in Enblend and Enfuse

  The best way I can think of to do this is to use a cubic projection and provide all cube faces to the tool simultaneously. All of the boundaries will be horizontal or vertical lines, which will fit in well with the SKIPSM-based pyramid algorithms currently in use. Enblend and Enfuse can share the same pyramid code.

• Enblend would additionally need a nearest feature transform algorithm that works on the cube surface for mask generation. I am not aware of a published algorithm to solve this.
• Improve the seam optimization algorithm in Enblend.
• GUI hooks: an API to a higher anstraction level language such as Python+wxWidgets or Lua+wxWidgets, with a real time interface into the enfuse functionality so that when changing weights with a sliders a preview can be generated in near real time.
• multi-step fusing and alternative, user controlled, weighting (sigma).

Skills

Admission Test

A potential applicant for this project should first try to add boundary conditions to the localVarianceIf function in enfuse.h.

OpenGL accelerated hugin preview

There is a nice proof of concept for this idea created as a student project at Hallam University.

Ghost removal for enfuse

Thanks to SoC2007 project Anti Ghosting, hugin has ghost removal when merging bracketed series to HDR, but this isn't currently available for enfuse.

Masking in GUI

Currently masking to remove unwanted objects from panoramas has to be added to alpha channels which is laborious, this could be integrated into the hugin GUI via a simple vector/polygon editor. It would need to be simpler to use than the equivalent process with Inkscape

Batch processing

SoC2007 project Batch Processing was an unadopted project last year.

Now that hugin has a Makefile based stitching process, it is much clearer what a batch stitcher would look like. This would need to support 'plug-in' Makefile add-ons for additional views, QTVR generation, uploading, sharpening etc... as well as a queue/spool manager.

Lens Database

lens database of accumulated knowledge on distortion, CA, response curve. The lens database aim : using stitching to feed an huge camera / lens database for distortion correction, vignetting correction, ca, etc. Then, it will be possible to reuse this database to correct single picture too.

tCA Correction

An utility to determining the Transverse Chromatic Aberration (tCA) of an image so it can be corrected.

Description

CA is when the color channels in an image do not appear to line up well with each other. tCA is when colors are in focus but placed adjacent to each other. tCA can be corrected with Panorama Tool's Radial Shift. More info on Chromatic aberration

Correcting tCA using PanoTools' Radial Shift, requires knowing the radial correction coefficients a, b and c for your lens. PTOptimizer can be used to calculate the coefficients if known amounts of shift for each channel is known from the center to the corners of the image.

This utility will produce these coefficients to be used in the lens database.

Assume image is 180 deg diagonal filed of view. Regardless if it is rectangular or fisheye of any field of view. Map image to the nadir of a sphere, taking into account any offset from center of image.

The bottom of the remapped image is the center of the original. Moving up the remapped image is the same as moving away from the center of the original image.

Now we no longer have to deal with radial shift but vertical shift. The image can be divided into a number of strips going across the entire width of the image. Each strip represents a circle a different distance from the center. The strips are shifted up and down the same amount over the entire image width. Each strip can have the channel data adjusted up and down to find the best match to eliminate CAt at that position. One channel does not move while the other two are adjusted. The best result of the two channels are recored for every strip. Sub pixel accuracy can be achieved by increasing the height of the result when creating the remapped image.

This can be done manually in real-time giving visual feedback of the channels alignment. Or it can be done programmability doing a difference between the two channels and looking at the histogram. The blackest result has the best alignment. If accurate automated results are possible then there is no need for the manual method.

Current methods of correcting tCA are fairly complicated.