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.