panotools-devel

In a nutshell,
First warning. I had to reindent some functions. use svn diff -x -w to
get diffs with whitespace ignored.
* tilt parameters have been renamed to TiX, TiY, TiZ, and TiS. TiX,
TiY, TiZ are now properly bound to -180,180 degrees. TiS can't be zero
nor negative.
* mosaic mode parameters are now TrX, TrY, and TrZ.
* I have added a set of parameters for future testing: Te0, Te1, Te2,
and Te3. These can be used for testing anything that requires
optimization (i.e. a new lens model). SetMakeParams and
SetInvMakeParams will need to include a new function to be used. Where
in the stack is dependent of the purpose.
Here is the same example I have been using. Layer 0 is the base photo,
layer 1 is the tilted version, and layer 2 is the translated one.
http://turingmachine.org/~dmg/temp/mergedFloorTiltTranslate.psd.bz2
Let me know what you think, and of course, if there are any bugs.
--dmg
----------------------------------------------------------------------
2009-09-25 <dmg@...>
* correct.c (SetCorrectDefaults): Initialized values of new parameters.
* adjust.h (GetGlobalPtr): added parms to its prototype
* PTcommon.c (panoPrintImage): Refactored this function from adjust.c
* panorama.h (correct_Prefs): Added new parameters
* adjust.c (SetAlignParams): Added new variables and renamed tilt ones.
(panoAdjustPrintMakeParams): Renamed function to make it standard.
Renamed variable g to optInfo
(SetAlignParams): Make sure the tilt parameters never go outside
incorrect values.
* parser.c (panoParseVariable, ParseScript): Refactored some
code. Sorry but I had to reindent the entire function.
* parser.c (WriteResults): Added new parameters to the output.
* parser.c (ParseScript): Renamed Tx, Ty,
and Tz to TiX, TiY, and TiZ. Added translation variables TrX, TxY,
and TrZ and test ones Te0, Te1, Te2, Te3.
* filter.h: Added translation parameters, (trans[XYZ]), renamed
optimization variables to a more meaningful name (suffix optVar),
added a new set of variables for testing new functions in the
stack.
-------
--
--
Daniel M. German
http://turingmachine.org/http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

D M German wrote:
> * tilt parameters have been renamed to TiX, TiY, TiZ, and TiS. TiX,
> TiY, TiZ are now properly bound to -180,180 degrees. TiS can't be zero
> nor negative.
>
> * mosaic mode parameters are now TrX, TrY, and TrZ.
>
> * I have added a set of parameters for future testing: Te0, Te1, Te2,
> and Te3. These can be used for testing anything that requires
> optimization (i.e. a new lens model). SetMakeParams and
> SetInvMakeParams will need to include a new function to be used. Where
> in the stack is dependent of the purpose.
>
> Here is the same example I have been using. Layer 0 is the base photo,
> layer 1 is the tilted version, and layer 2 is the translated one.
>
> http://turingmachine.org/~dmg/temp/mergedFloorTiltTranslate.psd.bz2
>
> Let me know what you think, and of course, if there are any bugs.
>
> --
> Daniel M. German
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
Looks like it is working.
The tilt model aligned the spherical images better in your example.
But your wall example looks bang on.
Thank you. I'll be running some test shortly.
--
Jim Watters
http://photocreations.ca

I am not getting good results with using the tilt model to force fit
some extra images into a full spherical pano.
I took three extra images that are extremely off the NPP.
One of the nadir and one each of two different walls.
I will try another day to optimizing to a rectilinear output projections
and see if it has a better effect.
--
Jim Watters
http://photocreations.ca

Jim Watters wrote:
> I am not getting good results with using the tilt model to force fit
> some extra images into a full spherical pano.
> I took three extra images that are extremely off the NPP.
> One of the nadir and one each of two different walls.
>
> I will try another day to optimizing to a rectilinear output projections
> and see if it has a better effect.
>
I could get the tilt model to align the images.
The translation mode could align one image if the plane is at z=1, by
optimizing the anchor image y&p.
Changing the output to rectilinear did not help the optimizer.
--
Jim Watters
http://photocreations.ca

Jim Watters wrote:
> Jim Watters wrote:
>
>> I am not getting good results with using the tilt model to force fit
>> some extra images into a full spherical pano.
>> I took three extra images that are extremely off the NPP.
>> One of the nadir and one each of two different walls.
>>
>> I will try another day to optimizing to a rectilinear output projections
>> and see if it has a better effect.
>>
>>
> I could get the tilt model to align the images.
>
That should have been, I could *not* get the tilt model to align the images.
> The translation mode could align one image if the plane is at z=1, by
> optimizing the anchor image y&p.
>
> Changing the output to rectilinear did not help the optimizer.
>
Using rectilinear and adding horizontal and vertical control points to
straighten the pano helped make the plane perpendicular and straight ahead.
As proof that the Translation mode only works at z=1 is after aligning
the images use the Numeric Transformation to adjust the yaw 10 deg. The
image being aligned with Translation will not line up. This is because
the camera positions needs to be updated too.
Try optimizing the Translation image. In my case the error increased
from max 8 to max 200.
This makes the Translation mode totally useless in most panorama
stitching. But very good at stitching mosaics.
--
Jim Watters
http://photocreations.ca

Jim Watters wrote:
>> The translation mode could align one image if the plane is at z=1, by
>> optimizing the anchor image y&p.
>>
>> Changing the output to rectilinear did not help the optimizer.
>>
> Using rectilinear and adding horizontal and vertical control points to
> straighten the pano helped make the plane perpendicular and straight ahead.
>
> As proof that the Translation mode only works at z=1 is after aligning
> the images use the Numeric Transformation to adjust the yaw 10 deg. The
> image being aligned with Translation will not line up. This is because
> the camera positions needs to be updated too.
Actually, I think they will be misaligned even if the camera positions
are also rotated.
> This makes the Translation mode totally useless in most panorama
> stitching. But very good at stitching mosaics.
Indeed, the panorama usecases is something that is not covered by the
current translation model. It might be possible to specify two more
parameters so that each image can have it own plane, but I fear that
this will make optimization even more delicate. I will have to think
about it a bit more. Maybe something like the tilt parameters but
implemented differently could work for that purpose.
ciao
Pablo

Thomas> Hi Jim,
Thomas> I'd say the floor example is aligned as well as could be
Thomas> expected with just a tilt and shift. Or has the magnification
Thomas> (or Z distance) been optimized too?
Shear also. tried shear with the Tr model, but didn't work.
I am being confused by the optimizer. I can't get the Tr parameters to
stay within reasonable values and still get good results.
Thomas> Anyhow, to do much better would probably require lens
Thomas> calibration, and some higher order corrections.
Thinking about corrections, how many parameters do you need for your
corrections?
Thomas> Ultimately, the nadir matching problem needs 3D depth analysis
Thomas> and some "orthophoto"-type local adjustments. Perhaps we
Thomas> should think seriously about reviving morph-to-fit?
I worked on that long time ago. I think I can get it working again.
--
Daniel M. German
http://turingmachine.org/http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

Hi Dan
On Sat, Sep 26, 2009 at 4:18 PM, D M German <dmg@...> wrote:
>
>
>
>
> Thomas> Hi Jim,
>
> Thomas> I'd say the floor example is aligned as well as could be
> Thomas> expected with just a tilt and shift. Or has the magnification
> Thomas> (or Z distance) been optimized too?
>
> Shear also. tried shear with the Tr model, but didn't work.
>
> I am being confused by the optimizer. I can't get the Tr parameters to
> stay within reasonable values and still get good results.
>
> Thomas> Anyhow, to do much better would probably require lens
> Thomas> calibration, and some higher order corrections.
>
> Thinking about corrections, how many parameters do you need for your
> corrections?
>
If you mean correcting the lens projection, not more than 8. That counts
the projection type as a parameter, along with focal length, 3 or 4
"distortion" parameters, and the center shifts.. On this accounting libpano
presently uses 7 parameters: projection type, fov, a, b, c, d, e. For
lensFunc, there need to be new projection types that explicitly mean
"rectilinear lens", and one or more kinds of "fisheye lens". The use of
these codes would imply the use of 3 or 4 lensFunc-style distortion
parameters, one or two for a mathematical model of the lens and 2 or 3 for a
correction polynomial. The meaning of fov and center shifts would remain
unchanged.
It might be possible to get the number of distortion parameters down to 3,
which would be preferable from the statistical point of view, if they were
to be optimized at stitching time. However the basic idea of lens
calibration is to predetermine some lens parameters rather than optimizing
them at each stitch, one big benefit of which is to reduce the number of
parameters that need to be estimated from the control points. I don't think
it is realistic to stop optimizing fov or center shifts, and maybe one
adjustable shape parameter should be provided for stitching, but that could
be different from any of the calibration parameters. My thinking is that
some adjustable stretching -- like morph-to-fit -- is likely to be better at
fitting images together than fiddling with the lens parameters.
Regards, Tom
>
> Thomas> Ultimately, the nadir matching problem needs 3D depth analysis
> Thomas> and some "orthophoto"-type local adjustments. Perhaps we
> Thomas> should think seriously about reviving morph-to-fit?
>
> I worked on that long time ago. I think I can get it working again.
>
> --
> Daniel M. German
> http://turingmachine.org/
> http://silvernegative.com/
> dmg (at) uvic (dot) ca
> replace (at) with @ and (dot) with .
>

Hi Daniel,
D M German wrote:
>
> In a nutshell,
>
> * tilt parameters have been renamed to TiX, TiY, TiZ, and TiS. TiX,
> TiY, TiZ are now properly bound to -180,180 degrees. TiS can't be zero
> nor negative.
>
> * mosaic mode parameters are now TrX, TrY, and TrZ.
Thanks for these changes. I'll post my modified hugin soon.
> Here is the same example I have been using. Layer 0 is the base photo,
> layer 1 is the tilted version, and layer 2 is the translated one.
>
> http://turingmachine.org/~dmg/temp/mergedFloorTiltTranslate.psd.bz2
>
> Let me know what you think, and of course, if there are any bugs.
The problem with using Tr on this example is that it currently assumes
that the plane is located at Z=1, and not tilted. You could try
optimizing y,p of the anchor image, too, and it should work better.
Actually, this could be used for straightening a sphererical panorama
without straight line control points, I think ;-)
ciao
Pablo

Pablo> The problem with using Tr on this example is that it currently assumes
Pablo> that the plane is located at Z=1, and not tilted. You could try
Pablo> optimizing y,p of the anchor image, too, and it should work better.
Hi Pablo, if I am understanding correctly, this means that the best way
to use Tr parameters for a mosaic is to shoot as orthogonal to the plane
as possible.
--
Daniel M. German
http://turingmachine.org/http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .