Re: [PanoTools-devel] patch to add support for more projections

[Pablo d'A. <pab...@we...>]

Bruno Postle wrote
> On Thu 20-Apr-2006 at 09:39 -0400, jwa...@ph... wrote:
> 
>> > > there is no way for the transformation functions to report > >
>> wether a pixel in the panorama image is valid or not
> 
> 
> Surely something like this happens already?  How do the
> empty/transparent areas of output around remapped images get generated
> otherwise?

Because this happens based on wether the input image alpha channel or crop
setting excludes the pixel in the *source* image. However, currently there
is no way that an output pixel can be set to invalid.

It works like this:
transformImage()
{
  for all pixels in pano image:
     transform pano coordinates to src image coordinates
     interpolate from source image, if inside src image.
}

the coordinate transforms the pano image coordinates into spherical
coordinates, applies yaw, roll and pitch, applies distortion correction etc.

The problem is that the transform from the output panorama projection to
spherical coordiantes is always valid. ie. there are no invalid spherical
coordinates, even a latitude of 10^30 degrees is valid.

So there needs to be a way that the sinusoidal -> spherical transform
reports invalid input coordinate. For example, this is possible with
circular fisheye and sinusoidal panos.

> [snip changing the API]
> 
>> The best thing probably would be to change the name of the DLL/library
>> from pano12 (pano13 comes to mind).
> 
> This shouldn't be necessary.  These other tools can either change to
> suit the new API or ship with an older version of the library.
> 
> ...or the extended API can live in newly named functions and the old
> functions can just be wrappers around them.

Actually, in this case I vote for changing the API. The only affected
functions are the really low level coordinate transform functions, which are
not likely to be used by binary, non open source programs (which are
theoretically not allowed to link against the GPL'ed panotools anyway...).

Most tools will probably use the MakeTransform() and execute_stack()
functions, and not the low level functions (erect_pano etc.) directly.

Actually I don't know, but I speculate that PTStereo might use these low
level functions directly, and might break, so a wrapper might still be useful.

My proposal is then to extend the API (as suggested by Bruno), introducing
a new

int execute_stack_try ( double x_dest,double  y_dest, double* x_src, double*
y_src, void* params );	

and related transform functions like:
int erect_rect_try ( double x_dest,double  y_dest, double* x_src, double*
y_src, void* params );	

There would be wrappers around the old functions that will just call the
_try variants and discart the return code.

ciao
  Pablo