Introduction to Hugin's source code

This page will give a short overview about some aspects of Hugin's source code.

Panorama Model

Holds the Panorama state. It contains the following objects:

• the source images in a vector<HuginBase::SrcPanoImage>
• the control points in a HuginBase::CPVector
• the parameters to optimise in a HuginBase::OptimizeVector
• the output options in PanoramaOptions (mostly the parameters on the stitcher tab)

In GUI this class should not modified directly. Use instead a command object that inherit from PanoCommand (otherwise it will break undo/redo functionality). Consider it in GUI as read only.

List of SrcPanoImage

The HuginBase::SrcPanoImage holds all parameter of a single images. The access the individual image parameters use the get* and set* methods.

If you want to modify several parameters in one rush, use a HuginBase::VariableMapVector instead.

Coordination transformation

If you need to transform coordinates from image to panorama space or vice versa, use HuginBase::PTools::Transform.

If you want to transform from image to panospace, create the transformation stack with HuginBase::PTools::Transform::createInvTransform. If you want to transform coordinates from panorama space to the coordinates of a single image use HuginBase::PTools::Transform::createTransform. Both require a HuginBase::SrcPanoImage to describe the image and a HuginBase::PanoramaOptions to describe the panospace.

Now you can transfrom the coordinates with HuginBase::PTools::Transform::transformImgCoord. There are some cases, where it is not possible to transform the coordinates, e.g. in rectilinear transformation or when the project has non-zero translation parameters. So always check the return value of transformImgCoord, if the transformation could be executed.

Example

      HuginBase::PTools::Transform trans;
      trans.createInvTransform(srcImage,options);
      trans.transformImgCoord(x_out,y_out,x_in,y_in);

GUI

Hugin GUI

The GUI is written using the wxWindows toolkit. My idea was that the gui should not be a monolithic block, but split into smaller parts (for example the different tabs in the main frame are a idea how the GUI should be split in different panels that will recieve notifications when the model changed and will update themselves accordingly. These panels can also use the Commands inherited from PanoCommand to modify the model. The model should never be changed directly. By using PT::PanoCommand and a CommandHistory to execute them, it is very easy to implement undo/redo functionality. PT::Panorama will notify a PT::PanoramaObserver which can then notify the GUI and interested subwindows. MainFrame is a good candidate for PT::PanoramaObserver.

XRC is used for the GUI design. Each custom Panel should have its own XRC file, so that people can work with on different parts of the GUI without to much trouble. The MainFrame will then use the unknown class to load the different custom Panel. CPEditorPanel is an example how this can be done. Note that there is only a global namespace for all xrc files. Names in the xrc files should therefore start with a prefix that indicates the parent panel.

PTBatcherGUI

PTBatcherGUI stores a list of project files in a Batch class.

---