[ptx] On the organization of the hugin src

[JD Smith]

On Sun, 2004-03-21 at 02:37, Pablo d'Angelo wrote:
> On Sun, 21 Mar 2004, JD Smith wrote:
> 
> > 
> > I decided to take a look around the hugin CVS to get a sense of the
> > source and think about where I might like to contribute: what a mess (no
> > offense, nobody likes cleaning up)!
> 
> Yes, I have to admit that this is true...
> 
> > It seems as though the full development process, with all its branches
> > down many experimental or unproductive alleys, and an early basis on other
> > external tools (like PanoImage) is reflected in the current directory
> > structure, such that it's very difficult for someone on the outside to get
> > a "top level view" of the relationship between the many hugin components.
> > Though obviously a matter of personal taste, I suspect you might attract
> > more developers (like me!)
> 
> Oh, cool, you're thinking about joining development :)
> What do you want to work on?

I was thinking of poking around with autopano stuff, and perhaps
enblend: i.e. the guts of the code (I wouldn't have the patience to
learn all the wxWindows I'd need).  I've also kept the flat-fielding
problem in the back of my mind.

> Therefore I'd like to create a library that contains the basic panorama
> datastructures and algorithms.
> Currently this is stuff is included in the following subdirs:
> 
> common     (small utilities needed everywhere, platform workarounds)
> Panorama   (datastructures to hold the Panorama, and related operations
>             optimisation, stitching etc. A redesign of this is needed.)
> vigra_ext  (vigra (image processing) extensions)
> 
.
> 
> maybe a new directory structure would help:
> 
> base/
>   common
>   Panorama
>   vigra_ext
> 
> applications/
>   hugin
>   nona
>   nona_gui
> 
> scrapheap/
>   autopano_old
>   panosifter
>   automatch
>   autooptimizer
>   PanoImage
>   

Looks good.  My only worry is that many tools can work stand-alone, e.g.
enblend, autopano, etc., and thus might want to a) live in their own CVS
space somewhere, or b) have a directory in applications/.  I think both
of these should be feasible if the core functionality of enblend,
autopano, etc. were bundled into individual libraries which hugin could
call, as could the command line front-ends for these tools.  The issue
then becomes one of efficient data structure impedance matching among
all the libraries, but since VIGRA underlies most of the "external"
tools, that may not be an insurmountable problem.  I suppose certain
problems are solved multiple times by the different tools (spherical
projection, for instance): it would be nice in this case to trim off a
small convenience library for all library builders to use.

> Alexandre also wants to archive this, so probably we should work together on
> this.
> 
> > It would also help to make clear where the dependencies exist; so far I
> > see panoimage, jhead, vigra, nona, qt, wxwin, Panorama classes, etc.,
> > and of course libpano implicit in there (somewhere).  I know this is a
> > moving target.  I think many parts of the pano build (align, stitch,
> > coordinate transform, seam, etc.) process are or will soon have several
> > different flavors available (either actively, or as vestiges), so the
> > confusion is bound to grow.  
> 
> Yep, a reorganisation is needed, but it should be as one (or maybe more)
> panorama libraries, that provide the real functionality for panorama
> creation.
> 
> Also a README file that explains the stuff I have written here would
> probably help a lot.
> 
> > The progress on hugin and friends is very encouraging, and I think with
> > a bit of organization it can even accelerate!
> 
> Yes, definately true. The problem we had (and still have) is that everybody
> writes on his own codebase, so it's harder to unifiy everything. 

I think that this may continue.  People who invest a large amount of
time into a program of general utility, like enblend, probably would
like to keep that tool separate to some degree, rather than have it
subsumed under the hugin umbrella.  This is perfectly natural, and with
some care we can have our cake and eat it too: designing towards a set
of convenient, interoperable libraries, and then targeting those
libraries with special front-ends, be they GUI, or command line, would
seem to do the trick.  For instance, you didn't need to integrate VIGRA
into hugin directly.

> My hope was that all the code would be integrated into a common Panorama
> framework, but that didn't work out (as can be seen by the diverging
> developments, 3 programs to do sift based control point creation).

By keeping the coupling between libraries as lightweight and
well-documented as possible, this frees others to code as they like,
while keeping interoperability with the Panorama library suite in the
back of their minds.

Thanks,

JD