Contents

Architectural Overhaul of Panotools

Currently PanoTools is rather like a collection of monolithic tools that you would use from the UNIX command-line, and those tools are communicated with input 'scripts' even when linked as a library.

The goal of this project is to reorganise those processes of PanoTools into smaller chunks of codes with well defined interfaces so that easier employment, extension, and maintenance will be possible in the future.

Deliverables

PanoTools as a collection of functions that needs no parsing and writing of 'script' to access

Common tasks should have well defined function interfaces

Independent tasks should have accessible interfaces of their own so that they can be easily replaced independently

Possible encapsulation of data

Well defined data representation with which the functions will be communicated

Possibly a structure that can be easily converted to an XML representation

File I/O functionality

Parsing/generating of the 'script' format currently in use

Possibly new XML format to be added

Possible Object-oriented consideration for flexible extension

Minimum (ideally no) modification when adding new variation of a task

Polymorphismic solution would be beneficial

Possibly by providing C++ wrapper

The new architecture should allow flexible and easy access to the various steps of panorama creation process. Identifying the separate tasks in PanoTools and defining a good interface for each of them will be the most crucial task of this project.

Also important is the data representation to be used in the interface for those functions instead of the scripts. Those representation may be designed so that new XML format can then be defined upon it to replace the conventional script files.

In addition, the design decision as to how extensible the library should be has to be decided. Easy to extend/maintain modularity does not need to be as flexible as the polymorphism in the object-orientated programming. One possibility is for the PanoTools to become an implementation simply easier to modify; a new general C++ interfaces can then be written to allow compatible implementations of PanoTools' different steps.

Timeline

(to be planned)

Discussion

Choice of license could be asked when writing new portion of codes. The PanoTools' source that has already written will certainly stay under the GPL (well, unless the authors authorise otherwise, but practically they are all under the hood GPL now and forever). However the newly written portion of the code; like the interface definitions, the new file format handling, and the possible C++ wrappers; can stay out of GPL. That would allow more flexible choice for the authors who want to write a compatible library with more relaxed license like LGPL or BSD allowing commercial use of the new implementations.

I'd say all in LGPL. I want to make sure those interfaces will stay opened. --Ippei 03:37, 19 March 2007 (CET)

Students planning to apply

Ippei UKAI (Also applying for New GUI project; the GUI is in my top priority because I care more about the ordinary users, but I'd be happy if either of those would be taken by someone else so that both will be done this summer.)