[ptx] On the organization of the hugin src

[Pablo d'Angelo]

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?

> if you tidy up and present a more new-developer-friendly layout like:
> 
> hugin/        ; everything which is required to compile the hugin binary
> hugin_tools/  ; external tools, like enblend, autopano, etc.
> hugin_scraps/ ; old and outdated stuff, stuff hugin drew on originally

While this looks nice at the beginning, the problem is that there is a lot
of common stuff between hugin and hugin_tools, which should be reflected in
the module layout.

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)

Especially the design of the Panorama related classes could be improved.

The real tools depend on these packages:

hugin      (obviously..)
tools      (all the new and obselete tools...)
nona_wx    (the first tool with its own directory, but depends on
            some wx GUI components of the hugin module

Then there's the old PanoImage viewer, which should be thrown out, I think.
Fabian Wetzel has written an opengl accelerated Viewer, which should be used
instead.
Sometimes I have added algorithms directly into the tools, when they should
have been added to the libs. Added them to the libs later on etc.

> As tools are integrated directly into hugin, or their presence becomes
> required, they could be moved into the hugin/ module.  

Hmm, I don't think this is the right way to go. Hugin is the main
application, but the real panorama processing stuff is and should be
independant of hugin and the gui, and some frontend applications.

maybe a new directory structure would help:

base/
  common
  Panorama
  vigra_ext

applications/
  hugin
  nona
  nona_gui

scrapheap/
  autopano_old
  panosifter
  automatch
  autooptimizer
  PanoImage
  

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. 

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).

The problems I see with hugin (in that respect):

1. Messy code structure (both old stuff laying around , and some design
   issues, that have their roots in the fact that hugin is my first "real" GUI
   application, leading to messy datastructures for the Panorama class.)
    
2. Usage of strange C++ template image processing library.

3. Usage of wxWindows for the GUI (.. I'm not really happy with it too ..)

4. Me having not enough time to correct 1. in the next weeks.


My plan is to have a new release which works with the Alexandres autopano
stuff, and maybe with enblend integration.

After that, it would be a good time for some code cleanup, I think.

ciao
  Pablo