Have just committed the first complete implementation of panini_general, including automatic clipping of hFOV to the max feasible limit, and working squeezes at top and bottom of image.

It works as expected in PTmender, and almost as expected in hugin 

The hugin slow preview window shows correct images, but does not always auto-update when the hcmpr slider moves, and seems never to update when the tops and bots sliders change.  The fast preview window tracks hcmpr and hFOV just fine, but somehow loses tops and bots altogether -- not only does it not update when they change, but it always displays an unsqueezed image.

I shall try building the latest hugin release on this version of pano13.lib and let you know if anything improves. 

Of course those are not libpano problems.  There are however still a couple of issues that span both hugin and libpano, namely that 1) there is no way to deal with FOV changes forced by parameter value changes, and 2) there are no default parameter values in libpano, nor any means in hugin to reset them to defaults.

Soon I shall write a page on this new projection for the Panotools Wiki.  It needs a bit of explaining, but I think I now understand it well enough to create an intelligible tutorial.

Cheers, Tom

On Fri, Jan 8, 2010 at 9:47 AM, Thomas Sharpless <tksharpless@gmail.com> wrote:
HI Dan

On Fri, Jan 8, 2010 at 4:20 AM, D M German <dmg@uvic.ca> wrote:

Hi Tom,

The code looks good. I have tested the same input hFOV with panini,
panini_general and equirectangular and they all give the same, which is

I had to reformat the entire code because I could
not easily read it (I find compact if-elses very had to read).


My only concern is the use of the static variable in

We cannot have static variables in these functions. It will make the
code non-reentrant.

I don't think it is needed; it is just for  a paranoid check that someone is not passing an old MakeParams struct with new projection parameters in it.  That does not seem likely enough to worry about.

The MP structure is the place where these values should be kept. The
variable "im->precomputedCount" is zero, it means that we these values
have not been set. Use array precomputedVariables (size
PANO_PROJECTION_PRECOMPUTED_VALUES --10 currently) to store anything
that needs to be saved from one invocation to another:

Image * check_panini_general(struct MakeParams* pmp)
   // DMG We cannot have a static variables.
   // Makes the code non-reentrant XXXX

   static double oldparm[4] = {0, 0, 0, 0};

We can also store some of the repeated calculations in
erect_panini_general in these fields (that is what they are for). See
albersEqualAreaConic_ParamCheck for an example, but this is not really
important, as this function is not called very frequently.

In fact I do store precomputed values: the working parameter values, translated
from the 'display' forms by check_paninin_general() when it finds no precomputed values.

Note that I have written check_paninin_general() to work with panini_general as
either source or destination, so it might be possible to make panini_general an
input format.  But the params would have to be set to match the source image.

The main outstanding problem is that the present way of setting distanceparam does not handle the possibility that the requested FOV exceeds the current max feasible FOV.  When it does, you get a bogus
image width, that may be negative (the reason I put the abs()'s in). I think the following scheme should work:

setMakeParams calls setup_panini_general( MakeParams * ), which does the
parameter translation, and also posts the appropriate distanceparam, based
on min( requested FOV, max feasible FOV ).  Then the angular scale will be right, and any destination pixels beyond the feasible limit will simply be black.

What do you think?  I shall try it soon, when I add the squeezes and remove the static var..

Regards, Tom


Daniel M. German
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
PanoTools-devel mailing list