Menu
▾
▴
Re: [PanoTools-devel] general panini and its parametrization
|
From: dmg <dm...@uv...> - 2010-01-06 21:28:09
|
Thanks Tom, I'll take a look tonight.
Great work!
--daniel
On Wed, Jan 6, 2010 at 12:19 PM, Thomas Sharpless <tks...@gm...> wrote:
> 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
>
>
>
>
> On Wed, Jan 6, 2010 at 1:37 PM, Thomas Sharpless <tks...@gm...>
> wrote:
>>
>> 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
>>
>>
>>
>> On Mon, Jan 4, 2010 at 9:56 AM, Thomas Sharpless <tks...@gm...>
>> wrote:
>>>
>>> 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
>>>
>>>
>>> On Fri, Jan 1, 2010 at 8:41 PM, D M German <dm...@uv...> wrote:
>>>>
>>>> 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 <dm...@uv...>
>>>> 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 .
>>>
>>
>
>
--
--dmg
---
Daniel M. German
http://turingmachine.org
|