I been interested in PanoTools half year ago,I very admire the original code
style by Derch,it seems so effective.
When i try to use it in my c++ programe,i met the same problem.I coundn't
agree any more to make a c++ version for convenience reusing.
Actually the key is the algorithm part,for example,LM&BR optimize,the
Transfermation functions.And gladly i found hugin have already
done a lot of things about this,although i don't think it is a really OOP
encapsulation,meanwhile,I coundn't strive for so much time to study boost
and vigra and vigra-ext.I think maybe STL will be enough.As for the data
struct of panotools Image,it is nothing.
I always wonder how PTGui make PT magic,i guess they must do a lot of extra
things.e.g. SIFT(but PTGui's control point looks not like sift but harries
corner),Blender...Imaging if all of these algorithms can be used as COM...
In fact,there are still many details to be improve.One month ago,I were so
confused by the optimizer,what the exact parameters he need on earth?and how
should i provide the proper source image size?and why PTMender need another
All the above questions make a hint that libpano need a well OOP
I am sorry that maybe i didnt make myself clear,cause i never make a good
comprehision of these kind of things .
2008/8/12 Thomas Sharpless <tksharpless@...>
> ---------- Forwarded message ----------
> From: Thomas Sharpless <tksharpless@...>
> Date: Mon, Aug 11, 2008 at 1:53 PM
> Subject: Reimplementing and extending libpano13
> To: Helmut Dersch <der@...>, Bret McKee <
> bret_mckee@...>, Bruno Postle <
> brunopostle@...>, Pablo d'Angelo <
> dangelo@...>, "Daniel M. German" <
> dmg@...>, Douglas Wilkins <
> dwilkins42@...>, Jim Watters <
> jim0watters@...>, Max Lyons <
> maxlyons@...>, Marek Januszewski <
> specu@...>, Thomas Niemann <
> tniemann@...>, Tim Jacobs <
> twjacobs@...>, ylzhao <ylzhao@...>,
> Rik Littlefield <rj.littlefield@...>, Kevin Kratzke <
> info@...>, Fulvio Senore <fsenore@...>, Thomas Rauscher <
> rauscher@...>, Robert Platt <rob@...>
> Hello All,
> 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
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> Build the coolest Linux based applications with Moblin SDK & win great
> Grand prize is a trip for two to an Open Source event anywhere in the world
> PanoTools-devel mailing list