---------- Forwarded message ----------
From: Thomas Sharpless <firstname.lastname@example.org>
Date: Mon, Aug 11, 2008 at 1:53 PM
Subject: Reimplementing and extending libpano13
To: Helmut Dersch <email@example.com
>, Bret McKee <firstname.lastname@example.org
>, Bruno Postle <email@example.com
>, Pablo d'Angelo <firstname.lastname@example.org
>, "Daniel M. German" <email@example.com
>, Douglas Wilkins <firstname.lastname@example.org
>, Jim Watters <email@example.com
>, Max Lyons <firstname.lastname@example.org
>, Marek Januszewski <email@example.com
>, Thomas Niemann <firstname.lastname@example.org
>, Tim Jacobs <email@example.com
>, ylzhao <firstname.lastname@example.org
>, Rik Littlefield <email@example.com
>, Kevin Kratzke <firstname.lastname@example.org
>, Fulvio Senore <email@example.com
>, Thomas Rauscher <firstname.lastname@example.org
>, Robert Platt <email@example.com
Some of you may recognize me as an occasional recent contributor to the hugin project. I/m a retired s/w engineer with a background in medical imaging, and by now a pretty keen panoramic photographer. I've used PanoTools for 5 years or so, and have freely stolen code from it for my own programs that solve special problems connected with rotating digital linescan cameras (which I build as a hobby).
Recently I've been looking into what I see as some shortcomings of libpano13, that are reflected as shortcomings of hugin, and have come to believe that a new object-based implementation might be a good thing. This is of course a ridiculously ambitious notion for one old programmer, so I'm trying to contact everyone who has a significant interest in the PanoTools library, to solicit your opinions about (and if possible, help with) such a project. If you know someone like that who is not on the address list of this e-mail, I would appreciate your letting me know how to reach them.
The basic idea is to reimplement libpano13 with C++ objects for the main data structures, and a new C++ API for future applications. I would hope to be able to keep the C structs and API, declared in panorama.h and filter.h, usable for current applications, somehow "shadowing" them with the C++ objects, but I can't say I actually know how to do that. So let's say the baseline objective is just a C++ API for everything now in libpano13, minus some functions that nobody uses, plus some improvements and extensions. This would support new apps only; however since hugin, at least, largely calls libpano though wrapper functions, it should be possible to adapt it to the new library.
I don't want C++ because I hate C -- indeed, Dersch's code is a thing of beauty -- but because it will make a better foundation for continued development of libpano. Most of you will I hope agree that by now a growing number of parameters and options has begun to seriously stress the original structure, not to mention the script file format. One manifestation is the presence of independent bits of code that compute the same thing -- or should -- or that initialize the same data structure -- always a sign of impending unmaintainablility. C++ really does solve such problems better than C, and the even more basic one of properly allocating and freeing memory blocks.
I don't mean to say libpano is buggy, just that it is getting a bit "long in the tooth". I'd guess that only perhaps 10% of the code would have to be rewritten to get a nice "new" C++ version.
To further improve libpano, it will be necessary to add even more parameters, and more complex relations among them. The C++ STL containers, and if necessary some more advanced algorithms from Boost, would make it much easier and safer to do this. And of course there are many open-source C++ packages that could add lots of value to libpano; for example the Vigra image file import-export library, which seems to be very comprehensive and well supported.
So what do you think?
Best regards, Tom