The divergence of the "PanoTools script" format between the various
front-ends has almost reached the point of total incompatibility. They all
now use scripts that libpano cannot parse. If we are serious about keeping
the command line PanoTools interoperable with Hugin et. al, something
urgently needs to be done about that.
I think the most responsible solution would be to recognize this divergence
and formalize a way to bridge it.
That could mean first of all publishing a standard that defines the "PT
script" language, as it is understood by libpano at specified revision
numbers, and making it the duty of PT developers to keep that standard
current and correct. And re-licensing libpano to require that any front end
that links to it must be able to produce compatible standard scripts for at
least the basic operations -- remapping (PTmender) and optimizing
(PToptimizer). And publishing a test suite to verify that.
Which sounds like too much work to me.
An alternative is to provide APIs by which any front end can manipulate the
libpano control variables directly, without having to produce any scripts.
That is in fact pretty much the approach that the Hugin developers have
taken. If such APIs were properly standardized and documented, then we
could in fact remove the PT script parsers from libpano into a separate
module that would only need to be linked by programs that wished to be "PT
This approach could be taken further, breaking the present libpano into
several modules that could be "layered" as needed to support a given app.
The fact is that Dersch's conception of a monolithic panorama processing
engine controlled by one canonical parameter table is no longer sufficient.
Perhaps it is time to formally split libpano into more easily manageable
On Fri, Sep 18, 2009 at 1:42 PM, dmg <dmg@...> wrote:
> On Fri, Sep 18, 2009 at 8:22 AM, Seb Perez-D <sbprzd@...> wrote:
> > On Thu, Sep 10, 2009 at 08:50, D M German <dmg@...> wrote:
> >> I just committed the changes to libpano to support the tilt feature.
> > So what is the procedure at the moment?
> > * create pto file in Hugin
> > * edit by hand and add the Tx, Ty, etc. parameters in the pto file:
> > ** in the i-lines as Tx1 Ty1, etc.
> > ** in the v-line as Tx0 Ty0 (if the nadir image is image 0)
> > * run PToptimizer
> * Export script for use with PTmender
> > * run PTmender to reproject the images
> PTmender will choke on Hugin PTO files. I have worked on an alternate
> parser, but I'll be reluctant to replace it
> until we have more regression testing.
> To edit by hand the script is a pain. This is what I did while testing: I
> * Created control points using Hugin.
> * OPtimized with "edit by hand"
> * Once presented the script to edit, cut&pasted to a file
> * Run PToptimizer manually, then PTmender
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> PanoTools-devel mailing list