Historical:SoC 2008 student proposals

Template

• name / university / current enrollment
• short bio / overview of your educational background
• did you ever code in C or C++, yes/no? please provide examples of code.
• do you photograph panoramas? please provide examples.
• do you make other use of hugin/panotools than for stitching panoramas? please describe and show examples.
• were you involved in hugin/panotools development in the past? what was your contribution?
• were you involved in other OpenSource development projects in the past? which, when and in what role?
• why have you chosen your development idea and what do you expect from your implementation?
• how much time you plan to invest in the project? (we expected full time 40h/week but better make this explicit)
• please provide a schedule of how this time will be spent on subtasks of the project. While this is only preliminary, be aware that at the beginning of the project you will be required to provide a detailed plan, and during the project you will issue weekly progress reports against that plan.

James Legg, OpenGL Accelerated Hugin Preview

• I am James Legg, a 2^nd year undergraduate in Computer Science and Mathematics at The University of York (UK).
• At university I have taken modules in human computer interaction, artificial intelligence, computer graphics and visualisation, theory of computation, algorithms and data structures, group & ring theory, linear algebra, vector calculus, and analysis among others. I have A-Levels in Physics, Maths, and Further Maths, and a Critical Thinking AS-Level.
• I have experience in C++ and OpenGL, for example I created a program that displays a procedural random terrain, including multiple layers of textures, using OpenGL, SDL (for platform independent event handling), and libnoise (for coherent noise generation). The source is available from http://lankyleggy.members.beeb.net (Download megamap.tar.gz)
• I do photograph panoramas and stitch them with Hugin, there are a few examples at: http://lankyleggy.members.beeb.net/panoramas/
• I also use Hugin for aligning bracketed photos to create HDR images, and I use enblend (and the Gimp) to create seamless textures from photographs. An HDR example and a tonemap are on the same page as linked above.
• I have only recently started contributing to Hugin, see http://groups.google.com/group/hugin-ptx/browse_thread/thread/f94c584095fcb9d0.
• I have not been involved in other open source development projects beyond use, evangelising and bug reporting.
• After completing this project, I expect to have a new optional preview display, acting largely like the existing one. This should instead use OpenGL, and a grid-like mesh to remap the images. It will only be approximate, but still functional. It will not require OpenGL shaders, as the hardware for this is not available to most users, although I would like to make it easy for someone to add this functionality at a later date. The main purpose is to speed up the preview process. Unfortunately, it will not have the accuracy and logarithmic HDR display of the current preview.
• I would like to do this project since I have an interest in computer graphics and human interface design.
• I will invest at least 40 hours a week after the first 3 weeks of the project. Unfortunately the 3rd week of Coding Phase 1 is an exam week, However I will attempt to make up the time before the official coding start date.
• I plan to split the project into the following stages:
  1. Beginnings: I will derive a new panorama preview from Hugin's existing one, set up an OpenGL context for it, and add extra preferences into Hugin to control selection of preview types, and the amount of texture memory and mesh resolution to use. I plan to have this done before the official "Coding starts" date.
  2. Texture creation: After this each image would be scaled appropriately and placed in texture memory.
  3. Photometric Alignment: OpenGL (without shaders) only directly supports linear colour transformations, however after this stage, white balance correction and (approximate) exposure correction will be used to display the images.
  4. Mesh creation: A grid-like mesh will be created for each displayed image. This will then be transformed under distortion correction, input lens projection and output projection, to get the coordinates used to make the display on the preview window. This will require using and extending the current remapping code. I will find a way to track duplicates (e.g. fisheye projections with a FOV > 360 degrees), and to split the mesh across discontinuities in the projection. The final output would then be a linear approximation between the mesh points (along continuous mappings), which is then handled by OpenGL. The results of the mesh transformations will be stored in memory so that changing parameters does not cause unnecessary costly calculations. I expect to have started this by the end of coding phase 1, but I expect this will be the most time consuming stage.
  5. Usability improvements: This will add extra features, e.g. a feature show the outline of an image in the preview, which will hopefully provide quicker identification of images.
  6. Performance enhancing and testing: I will try to improve the performance of my code, and fix any bugs I may have. I will call for testers on the mailing list during this stage, and I may add additional requested features if I have the time. I will also make sure that the documentation is completely up-to-date.

If this feature is not wanted, or mentors are not available, I have an alternative proposal: I would like to make a cube map projection, since cube maps are the most common way of handling static reflections in real-time computer graphics, they should work well with interactive panorama viewers such as FreePV, and it has been requested before.

I would keep the definition of the faces that make the projection generic enough (perhaps specified in a script) to allow shapes other than cubes to be defined (I see there is interest in foldable panoramas and other shapes, including ceating a Pilosphere). This will require work on making enblend and enfuse blend across distinct faces. I don't know any algorithms that can do this well, but I would be willing to research it and experiment.

Marko Kuder, Utility for Creating A Philosphere

Here is the application I intend to submit to Google, combined with the information I gave on the mailing list it should answer the questions in the template.

ABSTRACT

Hugin is a software tool for simple design of panoramic images. It's main function is to aid in combining multiple photographs, taken from a point in space in different directions, by finding common control points in neighbouring views and applying necessary transformations so that the images can be joined into a single, bigger picture. This can of course become an even tougher problem as photographs usually suffer from irregular lighting and Hugin is able to compensate for that also by color and light balancing.

The ultimate application of these functions is the creation of 360 degree panoramas. But such photographs have an innate problem - how to represent them in a natural and more attractive way than long and sometimes oddly curved pictures. The function that is yet missing from Hugin and would solve this problem is the ability to transform an image in such a way that it can be applied to a spherical body or, in practice, the automatic creation of models which can be printed and then folded into a polyhedron or sphere. The development and addition of this feature to Hugin would be my assignment on this project.

The original idea description can be found at: http://wiki.panotools.org/SoC_2008_ideas#Utility_for_creating_a_Philosphere

INTRODUCTION

Printing panoramas as foldable cut-out models has been somewhat popularized by Philippe Hurbain, a French electronics engineer and a panoramic photography enthusiast (his homepage is accessible at http://www.philohome.com). The rhombicuboctahedron, which he often uses for displaying his panoramic photographs, was nicknamed »Philosphere«, after Hurbain's first name. Even though printing panorama models has little technical potential, it is an idea that could bring panoramic photography closer to the general public, as it displays the photographs in a more interesting way. For this reason and because image transformations are a problem domain which can be handled with my education without much practical work experience (which I lack), I decided to apply for this specific idea. This way I could get some much needed programming experience, which is often expected when applying for a job, familiarize myself with working on a bigger project, which I would have to get to know without being involved in it's previous development, and work on something that is interesting to me. Other projects which are part of Google Summer of Code mostly require special skills or their project ideas are a very integrated part of the software they are based on. Since I plan to attend classes and pass my exams in June, I had to be realistic about my abilities and choose a project that I could handle in the time I would have. I was also a bit late in finding out about GSoC, so I have chosen only one project, this one, and spent the free time I had recently getting to know Hugin, the mentoring organization's project (which I haven't used before) and making sure I was fit for the job.

THE PROBLEM

While the basic idea of projecting an image on a sphere seems simple, it can get quite complicated if we want the projection to be as realistic as possible. The problem is that we have many types of cameras with different lenses and consequently multiple types of projections e.g. rectilinear, equirectangular, cylindrical and fisheye. Each of these should be handled differently and considering the fact that what we are working with are panoramas constructed out of multiple photographs, the simple problem can be expanded quite far. I do not intend to pretend that the original problem isn't trivial. If we had to map multiple non-stiched overlapping images to a single body, it would be difficult, but Hugin already contains the necessary code to join these images into one large panorama, so our task becomes easier. We can map an image to a sphere simply by converting it to so called »orange slices« (as shown on http://www.philohome.com/rhombicuboctahedron/rhombicuboctahedron.htm), which can be done by transforming each horizontal line of a slice into a shorter one, so it fits into the set form. There is a problem with this approach though. The final result depends greatly on the projection of the original image and the number of slices. The more slices we choose, the more equirectangular should the original photo be (as opposed to a fisheye projection), but such a model can be very hard to fold when printed. The alternative to orange slices which can be easier to assemble is the use of polyhedra like a rhombicubioctahedron or icosahedron, although model images of these could prove to be harder to construct, as multiple different transformations would have to be applied to separate parts of the original image. Some software which offers 3D panorama model construction already exists, like PTGui (http://www.ptgui.com) and IP-slicer script (http://www.bruno.postle.net/neatstuff/ip-slicer), but the former, which is a commercial application, is only able to construct a rhombicubioctahedron from a 360x180 degree panorama and the latter only converts an image into orange slices. Both lack additional user options, such as projection correction and incomplete panorama support, which I would like to include in my project. In my recent discussion with Hugin's group, Bruno Postle - one of it's members - kindly pointed out some solutions to similar problems which I could use as basis for my project. One is his image patterner (http://www.bruno.postle.net/neatstuff/image-patterner), which allows mapping images to arbitrary shapes (but by his words has some problems with performance and is written in perl, so it can't be used directly), and the second is the ability to specify arbitrary 3D meshes as foldable models by seam definition in the well known 3D modelling application Blender (http://www.blender.org/documentation/htmlI/x5336.html). Both present a possibility of parametrization of goal shapes and as such greater flexibility for further expansion of user options. While this would be great, I'm not sure at the moment if it could be developed in the time at hand, but it absolutely is an idea that I would consider, if not otherwise as further development after GSoC.

PROJECT TIME PLAN

Pre-summer phase:

At first I intend to get to know Hugin and it's source code as much as I need to visualize my planned code in it (including planning the GUI modifications). After that I should make some research and study the mathematical basis for my problem, so I could define the required code. At the start of the first coding phase, in June, I will have some exams to pass, so it could be expected that I will be less productive for a period of 2-3 weeks in that month, but I intend to get a head start on the project by beginning coding before the official start of GsoC coding phase one and I plan to already have something to show the mentoring organization at that time.

Coding phase one:

After my exams I will most probably be able to commit my full time to the project. Till the 14th of July, when mid-term evaluations begin, I intend to complete the inclusion of at least one of the planned transformations in Hugin with full functionality, so I could show some practical results.

Coding phase two:

After mid-term evaluations I would add as many additional functions and user options as possible, before doing the final bug fixes and polishing up the finished code and GUI to complete the project.

BIOGRAPHY

I was born and raised in Trbovlje, a small town in Slovenia and at the age of 22 I'm in the 4th year of the Computer Software university program at the Faculty of Computer and Information Science in Ljubljana, the capital of our country. My main interest is in computer graphics, although my dream would be to work in a small company designing software and electronic devices of various types, because I like inventing new things. From my education I have a lot of experience in Java programming and some in Python, C and C++, which would be my programming language of choice, for computer graphics in combination with OpenGL. Recently I have been working with our school's AI lab by doing research in the field of search algorithms and heuristics. I'm not much into photography, which may be strange considering the project I chose for my application, but I think my problem domain is separated enough from Hugin's main functionality that my lack of expertise in the area shouldn't be a problem. Google Summer of Code appears as an opportunity to prove to myself that I can work on real software projects and I hope I will be given the chance to show the same thing to Hugin's project team.

Michael Ploujnikov, Automatic Test Suite

Abstract

This project is to develop an automated test suite to perform functional (black box) and structural (white box) testing of the hugin internals as well as the user interface. The goal is to increase developers' confidence in the current code and future changes to the code as well as to improve the user experience of the application.

Deliverables

• a suitable framework will either be chosen from among existing frameworks or a new one will be developed based on analysis of the project needs and discussion with the core developers
• the test suite will be integrated with the built system
• procedures for creating unit tests, running tests and analyzing test results will be documented

Detailed Description

My name is Michael Ploujnikov and I am currently finishing up the last year of a Computer Science program at the York University of Canada.

I have written a lot of C programs for school assignments, just learning the language, personal projects and free/opensource software projects (FOSS)[1]. Most of my C++ programming experience is in working with FOSS projects.

I shoot hand-held panoramas some of which can be viewed in my public photo gallery[2]. Making even "regular" panoramas with hugin is so much fun that I have not had a chance to try anything fancy.

I have not been involved with hugin in the past. However, I have been involved in programming roles with other free/opensource software projects. My official resume[3] has some more details about my involvement.

I want to work on this project for a number of reasons. I strongly believe in test-driven development and wish to make it a possible (to some extent) for the current and future developers of a really fun application - hugin! I am currently taking a university course[4] on software testing and would like to apply the currently fresh concepts in my mind. I want to learn how hugin works and writing test for the code base is arguably one of the best ways to do so. I want to help the passionate hugin developers who volunteer their free time to work on this application by doing a rather tedious task of setting up an automatic test suite. Thus letting the developers spend more time on less "trivial" tasks. Finally, I want to get a feel for some unit testing frameworks (other than JUnit) that could be useful for me in the future career and FOSS projects.

I'm committed to work at least 40 hours per week for the duration of the GSoC on this project except for the first week in April when I will be busy with final exams, and another one week (to be determined) when I will be gone on vacation.

Plan

In Chronological order I will

• Finish school exams
• make sure I can run hugin compiled from source
• Research existing testing frameworks specifically for the C/C++ languages and wx/GTK GUI toolkits
• Research testing frameworks that work well with cmake
• Make a list of test suite features I would like to have
• Modify the test suite feature list by discussing it with core hugin developers to address their needs
• Decide (with core hugin developers) whether an existing framework (could be more than one) is suitable for hugin
• setup the existing framework(s) with stub tests or start creating a new framework (depending on how the previous decision goes)
• write some simple tests
• add concise usage documentation for the test framework on the wiki
• integrate the existing tests (I only found stuff in hugin/trunk/src/hugin1/tests)
• think about the testing techniques learned in school and use an appropriate one to come up with a "good" set of tests cases
• update the documentation because at this point the testing framework will probably have been modified
• write some tests for currently open bugs
• search the google group for proposed test cases and try to integrate them into the suite
• keep adding more tests until time runs out!