Re: [PanoTools-devel] Fwd: Reimplementing and extending libpano13

[Thomas S. <tks...@gm...>]

Hi Dan

On Tue, Aug 12, 2008 at 4:47 AM, Daniel M German <dm...@uv...> wrote:

>
>
> I am not sure how many people are still interested in hacking
> libpano. In more than one year since I stop contributing there have
> been only handful of changes.
>
> These last days I have started to work on libpano again. I think there
> are two main issues:
>
> 1. Future. There are several things that I want to do, and I have
> started a branch to accomplish it:
>
> -- Replacing the parser of panotools.  This is not trivial, but the
>   parser is already written. The main task is to convert the data
>   structures from the bison parser into the data structures of
>   libpano.
>
> -- Creating a suit of regression tests. This has been my goal for a
>   very long time. Without them our life becomes difficult. I have
>   been trying to find software to implement it but I haven't been
>   very lucky. cmake supports running regression tests, but we need
>   the testing infrastructure.


Agree heartily.

>
>
> -- Support for new projections. there are 3 projections that I (and
>   Seb) have. I have been wanting to refactor the code for projections
>   to make it easy to add new ones (the current code requires changes
>   in too many places).


That would be good.  I think it was one of Dersch's few  poor ideas to have
functions for all pairs of projections. Two functions per projection, that
map to/from a common reference frame would be much more manageable.
Moreover, all transformations on circularly symmetric projections could be
speeded up substantially by tabulating the radial function as a cubic spline
when the image is created.

>
>
> -- PTtiff2psd needs to be rewritten. It is too dump --its number of
>   writes is O(n^2) where n is the number of files to join.
>
> -- there are some minor changes that are required.
>
> 2. C++
>
>  yes, C++ would be nice, and perhaps it would be interesting to
>  implement the remapping using C++. I started reimplementing
>  projections (inside the libpanorama module of hugin). But one of the
>  great advantages of libpano is its speed and vigra makes it slow
>  (the performance of ptmender is better than nona, particularly for
>  large images that do not fit in memory).


I guess PTmender insists on TIFF files, which is a very good thing for
performance on big files since you can read and write them linewise.  And I
agree that vigra code runs slower.  But vigra images don't have to be
processed by vigra functions -- they are contiguous arrays and you can get
pointers to them.

Not that libpano couldn't be made faster.  I can think of two ways, both
much less difficult than the "fast transform" patch of a few years back
(which works well but could be improved, too).  One is the tablulated radial
functions I mentioned above; the other is tabulated interpolation functions
(the present code computes the interpolation coefficients for each point).

>
>
>
> 3. Adding parameters: They should be added to the parser, not to the
>   old code.  Look at libpanorama/parser and PTroller for the way to
>   use it (in my branch in libpano).


OK.  Does this parser also control script generation?

>
>
> 4. Legal/Copyright. Helmut's announcement of making his own version of
> libpano LGPL creates confusion (in my opinion). In my opinion this can
> only be resolved by using a different name.


Not a problem for me.

>
> Regards, Tom