Tuesday, May 27, 2008

Status Report (May 19 - May 25)

Things that have been done:
1. Design (Use case and Class Diagram)
2. Started porting exisiting implementation to use wxWidget and VIGRA
I've set up a basic wxWidget project. I'll start using VIGRA from the second week of coding phase.
3. Finalized scope (ie. deliverables for the project, what will be supported by the design and implementation)
Its mainly in the wiki. To summarize -
1. Create mask from brush strokes provided by the user
2. Fine tune mask
3. GUI features:
3.1 Undo/Redo
3.2 Load/Store
3.3 Zoom in/out
4. Extensible Design ie. provision for using different segmentation techniques, integrate with different front end
5. Standalone application that reads the pto file, lets the user create masks, remaps the mask and writes out the mask
6. Lastly work on automatically segmenting a sequence of images and masking out dark regions

Friday, May 16, 2008

New ideas and requirements

A lot of new ideas and requirements came out from the discussion in the mailing list. I'll summarize some of the points here for later reference.

Option for storing and loading masks:
Currently there are three options available - 1) storing the user input (this should make editing easier) 2) storing pixel-based mask 3) storing spline-based representation. There are two options for storing the mask. If its a spline representation then the splines can be stored in .pto file. In all other cases and also in general, it would be better to store the mask in a separate file and only the link will be provided in the .pto file.

At the beginning, I'll mainly focus on storing the user input and recomputing the mask from the input when its loaded.

Mask representation:
It would be nice to have the mechanism to convert pixel-based mask representation to spline-based representation and vice-versa. This is advantageous in two ways - a) a lot of tools already handle this type of representation b) spline-representation can be conveniently stored in .pto files. Autotrace tool was suggested in the discussion to compute the spline representation pixel-based mask.

This is definitely an important part. But it may not be possible implement this functionality during the summer. However the design will have provision for incorporating this feature

Fine tuning masks:
As for fine tuning masks, in general it is possible to get good results even if the mask is not completely accurate. But there are cases when good accuracy is essential.

Nona masks:
Applying masking in the nona stage may improve nona's performance. I'll be looking at this over the next few days.

Remapping masks:
It was pointed out that, when remapping is done it would be better for masks to be remapped as well. Since then users don't have to recreate the masks after remapping. To figure out how this can be done I'll be looking at PTMender.

Design:
It's important to have a loosly coupled system so that the underlying implementation is independent of the GUI.

This can probably be best represented using Command pattern. The command invoker (editor GUI) does not know how the operations are handled and the receiver (component handling masking) is not concerned about how the request was produced. To support undo/redo Memento pattern can be used. Hugin already makes use of these patterns so the implementation of these patterns in the mask editor will be kept consistent with that of Hugin. Additionally, for conversion between different formats strategy pattern can be used.

Saturday, May 3, 2008

Masking in GUI

In this summer as a participant of Google Summer of Code 2008, I'll working on a GUI based blend mask editor for hugin/panotools community under the guidance of Daniel M. German. This blog is mainly to keep track of my work and also to update interested people about the project. I'll also maintain a wiki for documenting the project. Please take a look at it and the references therein to get an idea of what the project is about and how its going to be done.