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 compatible".
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 pieces.
On Fri, Sep 18, 2009 at 8:22 AM, Seb Perez-D <firstname.lastname@example.org> wrote:* Export script for use with PTmender
> On Thu, Sep 10, 2009 at 08:50, D M German <email@example.com> 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
PTmender will choke on Hugin PTO files. I have worked on an alternate
> * run PTmender to reproject the images
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