Re: [PanoTools-devel] general panini and its parametrization

[D M German]

Thomas Sharpless twisted the bytes to say:

Thomas> Hi Daniel
Thomas> I put in 3 parameters and Hugin takes them OK.  But it returns them rounded to integer values.

this sounds like a restriction of hugin. The parameter sliders must be
programmed using integers, not floats.

A quick hack that will allow you to continue your work is to divide the
values in the sliders by 10 (specify 20 instead of 2) and then divide in
your code by the same factor.

yes, a hack, but at least you can keep working...

--dmg

Thomas> -- Tom

Thomas> On Thu, Dec 31, 2009 at 12:08 PM, D M German <d...@uvic.ca> wrote:

Hi Tom,

 Tom> Hi Daniel
 Tom> I'm trying to set up to test my revised general pannini code in libpano, and need some guidance about
how projection parameters get passed to/
 Tom> from hugin.

 Tom> First, I don't quite understand this code in queryfeatures.c

QueryFeatures was built as an interface to hugin. Hugin will use it to
know how many projections are supported, their field of view and any
parameters needed. Look at the albert conic projection for an example of
one with 2 parameters.

This way Hugin dynamically adjusts to the features of libpano without
having to be recompiled.

 Tom>     case PANO_FORMAT_PANINI_GENERAL:
 Tom>     features->maxVFOV = 179;
 Tom>     features->maxHFOV = 359;
 Tom>     features->numberOfParameters = 1;
 Tom>     features->parm[0].name = "d";
 Tom>     features->parm[1].name = "phi2";
 Tom>     for (i=0;i<2;i++) {
 Tom>            features->parm[i].minValue = +0.00001;
 Tom>            features->parm[i].maxValue = 10e10;
 Tom>     }
 Tom>         break;
 Tom> If there is just one parmeter, why do you intialize two of them?  What is phi2?

A "cloning" error. I just copied the code from the Albert. I should have
removed that line, and adjusted the for loop accordingly. I'll do that
right now.

As I mentioned before, queryfeatures is code that is not used inside
libpano (I think it should, for verification of parameters, but it is
not currently).

 Tom> How is the size of parm[] set?  What do I have to do to add two more parameters?

#define PANO_PROJECTION_MAX_PARMS 3

I said yesterday it was equal to 2. I was wrong, it is currently equal
to 3. I am not sure how hugin sets it.  So to add two parameters you
don' t need to do anything, just start using them in the projection. And
set them in the script, of course "P<val1> <val2> <val3>"

 Tom> Second, are any source changes needed on the hugin side, or can I 
 Tom> just relink a several months old build of hugin against this
 Tom> pano13.lib?

I'll check for the maximum number of parameters with the hugin
people. Maybe yes,  maybe not (the only problem is how the maximum
number of parameters is set).

 Tom> Happy New Year,  Tom

Happy new year!

--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

[T. Modes]

Hi,

> Thomas> Hi Daniel
> Thomas> I put in 3 parameters and Hugin takes them OK.  But it returns them rounded to integer values.
>

This should be fixed in rev 4846.

> this sounds like a restriction of hugin. The parameter sliders must be
> programmed using integers, not floats.

The sliders are using integers.
A problem is the range for general panini. The min and max values of
the sliders are set to the values hugin gets from queryfeature. So for
general panini the slider for the parameter "d" goes from 0 to 1e10
(min/max rounded to integer). So this slider works very crude, but the
text input field works good.

Thomas

[dmg]

thanks Thomas,

I was discussing with Tom that the sliders might have to be "scaled"
to be logarithmic. Once we have the
completed the implementation of the projection parameters we can
explore the best solutions.

--dmg

>
> --
> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx
>
>

--
--dmg

---
Daniel M. German
http://turingmachine.org

[Thomas Sharpless]

Hello PT developers

While trying to get hugin to display the new general panini, I noticed a kluge that we should address.

Hugin decides for itself whether the vFOV of a given projection is adjustable (fovCalcSupported() in PanoramaOptions.cpp) and worse, uses its own private list of projection type names to do it (enum ProjectionFormat {} in PanoramaOptions.h).  There is commented out code that suggests it once expected libpano to supply this information; evidently that did not work.

We need to make the legal ranges of both FOVs queryable projection features.  Probably should also supply a fn to compute the max feasible FOVs for specific projection parameters.

I have added PANINI_GENERAL to the copy of hugin I'm testing with; but I would much prefer to have
a correct libpano-based solution before releasing.

Regards, Tom

[T. Modes]

Hi Thomas,

> Hugin decides for itself whether the vFOV of a given projection is
> adjustable (fovCalcSupported() in PanoramaOptions.cpp) and worse, uses its
> own private list of projection type names to do it (enum ProjectionFormat {}
> in PanoramaOptions.h).  There is commented out code that suggests it once
> expected libpano to supply this information; evidently that did not work.
>

When libpano supplies this information, it can be integrated into
hugin. (e. g. a function if vFOV is adjustable for a given projection,
named enum for projections type)

> We need to make the legal ranges of both FOVs queryable projection
> features.  Probably should also supply a fn to compute the max feasible FOVs
> for specific projection parameters.
>

Currently I implemented the range check in hugin itself. After
changing the projection parameters Hugin checks if the HFOV is still
valid for the new projections parameters. If HFOV is bigger than max
HFOV for the new projection parameters it decreases HFOV to the new
max value. This check is done for general_panini, but also for biplane
and triplane. For all 3 projection the max HFOV depends on the
projection parameters.

Thomas

[Thomas Sharpless]

Hi Daniel et al.

I have finally got the inverse calculation for panini_general working correctly, now it gives images identical to recti when d = 0 (hcmpr parameter = -100) and identical to equi_panini when d = 1 (hcmpr = 0); and matches Panini so closely over the whole range of d that I can't see any difference (identity not claimed).

It seems my fears about the scaling of distanceparam were unfounded.  The true hFOV equals the nominal one over the whole range of hcmpr.  

So panini_general can be considered a working panorama projection now.  But not yet tested under hugin.

I have committed the source changes.

Regards, Tom

[Thomas Sharpless]

Hi

After a couple of workaround-type bugfixes, pannini_general is now usable under hugin.  But only with the slow preview window, the fast one displays garbage (though the resulting pano looks as it should).  This is true only if fov calculation remains disabled for panini_general, as it is in the current trunk version of hugin_base/PanoramOptions.c.  Enabling it causes vFOV to go to zero at each update, preventing use of either preview.

My workarounds won't hurt anything if the underlying problems get resolved.

Regards, Tom

[dmg]

Thanks Tom, I'll take a look tonight.

Great work!

--daniel

--

[T. Modes]

Hi Thomas

>  Enabling it causes
> vFOV to go to zero at each update, preventing use of either preview.
>

I found out, why it goes to zero.

In erect_panini_general it reads

if( x == 0 ) lambda = 0;
else{
</snip>
S = (d + ca)/(d + 1);
lambda = atan2( S * x, ca );
}
phi = atan(S * y);

when x==0, phi becomes always zero (independed of y) because S is not
set to a sensible value in this case (maybe using S=0). This breaks
the handling of vFOV in hugin, which uses the invers transformation at
x=0 for vFOV calculations. So could you provide a sensible value for S
when x==0?

Thomas

[T. Modes]

Hi,

> After a couple of workaround-type bugfixes, pannini_general is now usable
> under hugin.  But only with the slow preview window, the fast one displays
> garbage (though the resulting pano looks as it should).  

The fast preview window (trunk rev. 4862, libpano13 rev. 1212 +
changing line 1054 in math.c to "double S=1;", see my last mail) is ok
here with the general panini.

But I have a question: There are now 3 parameters for general panini.
But the second and third parameter show no change. Looking at the
source I can not see that these parameters are used in calculation. So
I'm missing something or is only one parameter needed?

Thomas

PS: The range checking of parameters in function check_panini_general
in math.c contains some copy and paste errors (when formatParam[1] and
formatParam[2] are outside the limit formatParam[0] is set.).