[ptx] nona vs. PTStitcher (was:PTOptimizer)

[JD Smith]

On Wed, 2005-04-06 at 18:00 +0100, Bruno Postle wrote:
> On Wed 06-Apr-2005 at 18:36 +0200, Benoit POSTE wrote:
> > 
> > > 2. Distributing PTStitcher just reduces the likelyhood of somebody
> > >    getting annoyed enough to add the missing features to nona.
> > 
> >    What's missing in Nona?
> 
> - Automatic colour/brightness correction.
> 
> - Fisheye format output, or is this a bug in hugin that it doesn't
>   show the option?
> 
> - Morph to fit.
> 
> - I'm not sure if it supports the 'fast transformation' option added
>   to pano12 by Fulvio Senore or 16bit colour depth images?

I think it doesn't.  I had volunteered to look into this, but never
really got fully comfortable with the Vigra underpinnings and layout of
the Hugin source.  Pablo indicated he was going to clean up and re-
organize (or at least document the organization of) the source after a
release, so I was waiting for that to look further.  

Nona is already pretty fast, because it skips all the "black area" in
the map transformation code, which libpano doesn't do.  It could be made
even faster by using an interpolation scheme ala Fulvio's.
Interestingly, Fulvio's interpolation scheme works row by row, i.e. it
is not a 2D interpolation of the remapped coordinates, which in
principle could perform much better for fisheye's and other projections
with fast-changing non-linear transformation deltas, and would require
even fewer evaluations of the complicated trigonometric transform stack
than a 1D interpolation would, at fixed tolerated error.  Fulvio's
method does use an interesting in situ estimate of the accumulating
error to decide how to sub-divide segments for interpolation,
dynamically increasing resolution where necessary.

Another very interesting point is that with nona, hugin actually uses
very little of libpano12, mostly just all the (complicated/optimized)
coordinate transform stuff, which Alexandre had already begun to rip out
and put into hugin separately (as SpaceTransform).  So with enblend
totally supplanting the color/brightness functionality inside of
libpano, and SpaceTransform (possibly, one day) replacing the coordinate
transforms, hugin could be completely de-coupled from libpano.  

That said, a better solution might be to break libpano into sub-pieces
that everyone could use and hack on.  Here's a snippet from a message I
wrote to Pablo about this, and his reply:


> > It seems in the ideal world there would be one external
> > stitcher/optimizer package for everyone.  Like nona, it would have full
> > source availability.  Like panotools, it would be convenient for lots of
> > people to hack on and improve.  It could be linked to as a library by
> > free software, or called as an executable from non-free software, or
> > used on the command-line by hard-core users.  Definitely more work to
> > fix the interface and get everyone to agree (especially if it's useful
> > for other things, like viewers), but could be well worth it.
> 
> Yes, I agree that would be a nice thing to have. Unfortunately, I really
> have to spend more time on my thesis work now, and university lectures start
> again next week so I probably won't have a lot of time to work/think over
> the hugin or nona stuff :(

One thing I'd like to see added are some other projections beside plain
cylindrical, like some equal-area cylinders that would allow decent
printing of full 360x180 panos.


> - Somebody should also do some performance profiling on really large
>   images or large numbers of images.

I guess my feeling that nona is faster comes from some early comparisons
before Fulvio's speedup.  It may not be the case anymore (though with
inside/outside rejection *and* interpolated transforms, it should really
smoke).  Anyone care to redo these?  

JD