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
good.

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

OK

My only concern is the use of the static variable in
check_panini_general:

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
http://turingmachine.org/
http://silvernegative.com/
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
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
PanoTools-devel mailing list
PanoTools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/panotools-devel