From: D M G. <dm...@uv...> - 2009-09-26 05:47:24
|
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 <dm...@uv...> * 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 . |
From: Jim W. <jwa...@ph...> - 2009-09-26 12:46:03
|
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 |
From: Thomas S. <tks...@gm...> - 2009-09-26 14:03:00
|
Hi Jim, I'd say the floor example is aligned as well as could be expected with just a tilt and shift. Or has the magnification (or Z distance) been optimized too? Anyhow, to do much better would probably require lens calibration, and some higher order corrections. Ultimately, the nadir matching problem needs 3D depth analysis and some "orthophoto"-type local adjustments. Perhaps we should think seriously about reviving morph-to-fit? Regards, Tom On Sat, Sep 26, 2009 at 8:45 AM, Jim Watters <jwa...@ph...>wrote: > 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<http://turingmachine.org/%7Edmg/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 > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
From: Jim W. <jwa...@ph...> - 2009-09-28 05:56:28
|
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 |
From: Jim W. <jwa...@ph...> - 2009-09-29 03:57:30
|
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 |
From: Jim W. <jwa...@ph...> - 2009-09-30 03:55:25
|
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 |
From: Pablo d'A. <pab...@we...> - 2009-09-30 15:37:34
|
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 |
From: D M G. <dm...@uv...> - 2009-09-26 20:18:51
|
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 . |
From: Thomas S. <tks...@gm...> - 2009-09-27 16:05:57
|
Hi Dan On Sat, Sep 26, 2009 at 4:18 PM, D M German <dm...@uv...> 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 . > |
From: Pablo d'A. <pab...@we...> - 2009-09-27 05:28:22
|
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 |
From: D M G. <dm...@uv...> - 2009-09-28 02:34:09
|
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 . |