Difference between revisions of "Historical:SoC 2010 ideas"

From PanoTools.org Wiki
Jump to navigation Jump to search
(Some possible projects, needs cleanup, linking)
Line 45: Line 45:
  
 
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.
 
To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.
 +
 +
=== Patent free control point generator ===
 +
 +
We now have a patent free control point generator with libpanomatic, but this needs some integration:
 +
 +
* Ability to read and write .pto projects
 +
* To classify features in a conformal space based on info in the .pto file
 +
* To not classify features in masked areas
 +
* Test suite
 +
* integration of celeste at feature identification stage
 +
* matching pairs of photos using heuristics (see gigastart)
 +
 +
Possible project to use GPU for feature classification as suggested on ptx
 +
 +
=== UI testing ===
 +
 +
Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.
 +
 +
So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design
 +
 +
=== Colour ===
 +
 +
Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:
 +
 +
* Display of images in tabs and preview is not colour managed, integrate lcms and access system  monitor colour profiles
 +
* Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos
 +
* tca correction in nona with support in GUI and .pto format, possible simple GUI to run tca_correct
 +
 +
=== Makefile system ===
 +
 +
Hugin uses gnu make to drive stitching, this involves writing makefiles and executing make as a sub-process. We have two issues with this;
 +
 +
* The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend
 +
* 'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters
 +
 +
Write a C/C++ equivalent of Panotools::Makefile, write lots of tests, identify problem characters on each platform, port Hugin to use this makefile library, add filters to filename selection parts of Hugin GUI to prevent use of problem characters.
  
 
[[Category:Community:Project]]
 
[[Category:Community:Project]]

Revision as of 12:24, 27 February 2010

If you are a student willing to participate in The Google Summer of Code 2010:

  • find out what ideas we have for SoC projects this year (read below);
  • decide 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; and
  • 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 2010. 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 project's version control system. Communication with the mentors should usually happen through the appropriate mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).

Application Template

SoC2010 Application Template

Possible Projects

You are welcome to propose your own ideas.

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

Zooming for fast preview

It would be good if the user can zoom into Hugin's fast preview window. The the amount of approximation in the fast preview would have to reduce to display meaningful details. The areas off screen can be ignored, to keep up performance as more details need to be processed. It would be appropriate to dynamically load more image detail for the most visible images too.

Threading for Hugin

Hugin currently becomes unresponsive while it loads images. It would be better to keep the interface responsive during image loading and scaling images in another thread. Also, something like this patch, which loads images when Hugin is otherwise idle, would be better in a background thread.

The user interface could display temporary placeholders while images are being loaded, and remain interactive.

To maximise the rate at which images are loaded, ideally we would have a thread that only reads files and waits for the filesystem, and another thread to uncompress image files and produce the small version of the image which waits only for CPU time. However doing both of these in a single thread, separate from the user interface thread, would provide a responsive interface.

Patent free control point generator

We now have a patent free control point generator with libpanomatic, but this needs some integration:

  • Ability to read and write .pto projects
  • To classify features in a conformal space based on info in the .pto file
  • To not classify features in masked areas
  • Test suite
  • integration of celeste at feature identification stage
  • matching pairs of photos using heuristics (see gigastart)

Possible project to use GPU for feature classification as suggested on ptx

UI testing

Everyone agrees that Hugin needs usability improvements, however the major usability issues are closely related to programming issues such as the quality and availability of control point generators. We do not want a programmer to dive-in and and try and fix 'usability' without a plan of action.

So Hugin could use a usability audit, i.e. write user profiles/personas, define tasks, collect real data from test subjects. This is a non-programming project for a student of interaction design

Colour

Hugin deals correctly with colour profiles in photos and passes them on to output, this doesn't need fixing, however there are some related tasks that could be tackled:

  • Display of images in tabs and preview is not colour managed, integrate lcms and access system monitor colour profiles
  • Hugin has a good backend for adjusting white-balance. Add a GUI grey picker and/or tools to adjust colour temperatures manually on a subset of photos
  • tca correction in nona with support in GUI and .pto format, possible simple GUI to run tca_correct

Makefile system

Hugin uses gnu make to drive stitching, this involves writing makefiles and executing make as a sub-process. We have two issues with this;

  • The code that handles makefiles is mixed up with stitching logic, the result is that this part of the codebase is quite hairy and difficult to extend
  • 'make' places restrictions on characters in file paths but the Hugin GUI doesn't do anything to prevent users from using these characters

Write a C/C++ equivalent of Panotools::Makefile, write lots of tests, identify problem characters on each platform, port Hugin to use this makefile library, add filters to filename selection parts of Hugin GUI to prevent use of problem characters.