From: Thomas S. <tks...@gm...> - 2009-07-28 14:40:29
|
Hello PanoTools developers, Designing a lens calibration program for Hugin has made it clearer to me both that the way libpano models lenses needs improving, and how such improvements could be implemented. PanoTools maps lenses just like any other projection, with a pair of functions that convert between the ideal lens projection and spherical polar coordinates, plus a polynomial that converts the ideal ("corrected") radius to the real ("uncorrected") radius. The ideal functions, and the radial polynomial, are used in other contexts as well, so there is nothing special about a lens at the level of the remapping function stack. The present PT scheme only allows two kinds of lens, rectilinear and "fisheye". The ideal function for the latter is "sphere_tp" (spherical polar coordinates as used to map the panosphere) which is the same as the equal-angle fisheye projection. At least two more ideal projections are needed to adequately model the range of existing fisheye lenes: equal-area and stereographic. The most direct way to improve PT's coverage would be to define two new source image types, equal-area fisheye and stereographic fisheye. The ideal functions are already in the library, so it would just be a matter of using them for those source image types. The main difficulty of implementing this has nothing to do with projection or correction, but the simple fact that PanoTools makes no formal distinction between lenses and ideal projections -- "you just have to know" when you are dealing with a lens. So doubling the number of lens types could compound confusion in many parts of the libpano code. A better alternative would be to create a single pair of "lens functions" that explicitly transform to and from all real lens projections and are distinguished from all the ideal projections. These could be used just like any other PT projections (as a rendering target, for example), but their use would always imply a physical lens model. Thus they would serve as a hook for introducing an explicit concept of "lens" into PanoTools. The lens functions would encapsulate the actual formulas and parameters used to model any given lens, and code would have to be added to libpano to set those up properly for each job. That code would deal only with lens issues, and could provide the API for a more complete lens modeling and calibration facility, something that Hugin (at least) badly needs. I am rather hopeful at this point (not having done the experiments yet) that inside the lens functions there could be a universal lens model, that fits all possible lens projections using two parameters. But they could just as well contain a collection of ad-hoc functions selected by lens type. Of course radius correction belongs inside the lens functions. That would allow more flexibility as to how it is done. And optimized. The lens functions would have to export sets of optimizable parameters. Those could differ according to not only lens type but also the context of the optimization; for lens calibration, some parameters would be visible that might be hidden during ordinary control point alignment. This could help reduce the frequency of optimization failures during stitching. Introducing opaque lens functions might also enable faster remapping, using a scheme I cooked up for autopano-sift-c. The idea is convert the whole radial projection and correction, and its inverse, to cubic spline tables beforehand, then remapping proceeds at (nearly) the speed of a cubic polynomial. I would like to know your thoughts on this. Regards, Tom Sharpless |
From: D M G. <dm...@uv...> - 2009-07-28 20:19:53
|
Tom> The lens functions would encapsulate the actual formulas and parameters used to model any given lens, and code would have to be added to Tom> libpano to set those up properly for each job. That code would deal only with lens issues, and could provide the API for a more complete lens Tom> modeling and calibration facility, something that Hugin (at least) badly needs. Tom> I am rather hopeful at this point (not having done the experiments yet) that inside the lens functions there could be a universal lens model, Tom> that fits all possible lens projections using two parameters. But they could just as well contain a collection of ad-hoc functions selected Tom> by lens type. Of course radius correction belongs inside the lens functions. That would allow more flexibility as to how it is done. Tom> And optimized. The lens functions would have to export sets of optimizable parameters. Those could differ according to not only lens type Tom> but also the context of the optimization; for lens calibration, some parameters would be visible that might be hidden during ordinary control Tom> point alignment. This could help reduce the frequency of optimization failures during stitching. Tom> Introducing opaque lens functions might also enable faster remapping, using a scheme I cooked up for autopano-sift-c. The idea is convert the Tom> whole radial projection and correction, and its inverse, to cubic spline tables beforehand, then remapping proceeds at (nearly) the speed of a Tom> cubic polynomial. Tom> I would like to know your thoughts on this. I fully agree. The lens models need an overhaul. How do we proceed? -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2009-07-31 21:41:05
|
On Tue 28-Jul-2009 at 10:40 -0400, Tom Sharpless wrote: > >The most direct way to improve PT's coverage would be to define two new >source image types, equal-area fisheye and stereographic fisheye. The ideal >functions are already in the library, so it would just be a matter of using >them for those source image types. I'm pretty sure that Jim Watters added these to libpano13 before the 2.9.14 release: * Some new input fisheye projections have been added: Mirror (f7), Orthographic (f8), Stereographic (f10) and Equisolid (f21). I think equisolid is your equal area fisheye. -- Bruno |
From: Thomas S. <tks...@gm...> - 2009-08-01 22:45:31
|
Hi Bruno On Fri, Jul 31, 2009 at 5:23 PM, Bruno Postle <br...@po...> wrote: > On Tue 28-Jul-2009 at 10:40 -0400, Tom Sharpless wrote: > > > >The most direct way to improve PT's coverage would be to define two new > >source image types, equal-area fisheye and stereographic fisheye. The > ideal > >functions are already in the library, so it would just be a matter of > using > >them for those source image types. > > I'm pretty sure that Jim Watters added these to libpano13 before the > 2.9.14 release: > > * Some new input fisheye projections have been added: Mirror (f7), > Orthographic (f8), Stereographic (f10) and Equisolid (f21). Can Hugin select those, or does it take a custom PT script? I guess I was looking at outdated source. Those projections were there, but not available as input image projections. Having downloaded the current SVN trunk I am in a position to be better informed. But still not to build, I am on a different machine from the one where I last built libpano, and it lacks libtiff and those infernal Java headers. I'm pretty well along with a universal "calibrated lens" projection and will add it to libpano when it works (testing in calibrate_lens first). Regards, Tom |
From: Bruno P. <br...@po...> - 2009-08-01 22:51:01
|
On Sat 01-Aug-2009 at 18:38 -0400, Tom Sharpless wrote: >> >> * Some new input fisheye projections have been added: Mirror (f7), >> Orthographic (f8), Stereographic (f10) and Equisolid (f21). >Can Hugin select those, or does it take a custom PT script? Not at the moment, nobody has written the code. -- Bruno |
From: Thomas S. <tks...@gm...> - 2009-08-03 00:54:36
|
Hi Bruno On Sun, Aug 2, 2009 at 3:28 PM, Bruno Postle <br...@po...> wrote: > On Sun 02-Aug-2009 at 13:09 -0400, Tom Sharpless wrote: > >> >> I would have to tweak the optimizer interface to stack functions in >> libpano >> a tiny bit to integrate the universal lens model. If Hugin's optimizer >> connects to remapping stacks built by SetMakeParams() (adjust.c) then this >> ought to work with Hugin's optimizer too. >> >> If you think of someone who is familiar with these things, let me know. >> > > Pablo is the only one who has done both the hugin and libpano13 part of > this. I'll ask his advice, then. > > > BTW I have been accustomed to build "Hugin's own" libpano13 with Cmake, >> but >> there are no Cmake scripts in the trunk at panotools.sourceforge. Is >> there >> a chance to bridge that gap? >> > > It's all auto-tools still. You are welcome to patch it. > > Is the panotools source the same used in Hugin, or not? >> > > There isn't a copy in the hugin source, if you have one probably you put it > there when you set up your tree. > It is beginning to come back to me that that is exactly what I did, when experimenting with straight line CP optimization (never got a good result). I set up the Cmake scripts to build only libpano without Java support, and get the image file format libraries from the Hugin SDK (i.e. wxWidgets). That let me build a static link library with and for MSVC. I guess it would not be terribly hard to extend the scripts to build the whole panotools suite, but I would not be surprised to encounter some compiler incompatibilities -- MSVC is a good deal pickier about language standards than Gcc is. If the rest of the panotools developers are willing to help out with testing & resolving any issues, I'm willing to try to add a full Cmake build system. This would almost certainly expect that you are set up to build Hugin, which the Makefiles do not, so might not be useful to all who want to build Panotools. But would be a helpful alternative for people who do build Hugin. I don't suppose it would hurt to put my "non-Java libpano13-only" Cmake scripts up right away (as soon as I test them against the current source, that is). Regards, Tom |
From: Thomas S. <tks...@gm...> - 2009-08-04 04:22:30
|
Hi Bruno et al I have committed a CMakeLists.txt for building libpano13 (only) in a Hugin build environment. Support for the Java tools is optional (that is much easier now due to someone's sensible repackaging -- only have to exclude the utility modules). It works for me with the Hugin Windows SDK and MSVC9. I have not tested the option to include Java support, and don't intend to. Will test on Ubuntu soon. Regards, Tom On Sun, Aug 2, 2009 at 8:54 PM, Thomas Sharpless <tks...@gm...>wrote: > Hi Bruno > > On Sun, Aug 2, 2009 at 3:28 PM, Bruno Postle <br...@po...> wrote: > >> On Sun 02-Aug-2009 at 13:09 -0400, Tom Sharpless wrote: >> >>> >>> I would have to tweak the optimizer interface to stack functions in >>> libpano >>> a tiny bit to integrate the universal lens model. If Hugin's optimizer >>> connects to remapping stacks built by SetMakeParams() (adjust.c) then >>> this >>> ought to work with Hugin's optimizer too. >>> >>> If you think of someone who is familiar with these things, let me know. >>> >> >> Pablo is the only one who has done both the hugin and libpano13 part of >> this. > > > I'll ask his advice, then. > >> >> >> BTW I have been accustomed to build "Hugin's own" libpano13 with Cmake, >>> but >>> there are no Cmake scripts in the trunk at panotools.sourceforge. Is >>> there >>> a chance to bridge that gap? >>> >> >> It's all auto-tools still. You are welcome to patch it. >> >> Is the panotools source the same used in Hugin, or not? >>> >> >> There isn't a copy in the hugin source, if you have one probably you put >> it there when you set up your tree. >> > > It is beginning to come back to me that that is exactly what I did, when > experimenting with straight line CP optimization (never got a good result). > I set up the Cmake scripts to build only libpano without Java support, and > get the image file format libraries from the Hugin SDK (i.e. wxWidgets). > That let me build a static link library with and for MSVC. I guess it would > not be terribly hard to extend the scripts to build the whole panotools > suite, but I would not be surprised to encounter some compiler > incompatibilities -- MSVC is a good deal pickier about language standards > than Gcc is. > > If the rest of the panotools developers are willing to help out with > testing & resolving any issues, I'm willing to try to add a full Cmake build > system. This would almost certainly expect that you are set up to build > Hugin, which the Makefiles do not, so might not be useful to all who want to > build Panotools. But would be a helpful alternative for people who do build > Hugin. > > I don't suppose it would hurt to put my "non-Java libpano13-only" Cmake > scripts up right away (as soon as I test them against the current source, > that is). > > Regards, Tom > > |
From: Kornel B. <Kor...@be...> - 2009-08-04 06:50:08
Attachments:
pano.patch
|
Am Tuesday 04 August 2009 schrieb Thomas Sharpless: > Hi Bruno et al > > I have committed a CMakeLists.txt for building libpano13 (only) in a Hugin > build environment. Support for the Java tools is optional (that is much > easier now due to someone's sensible repackaging -- only have to exclude the > utility modules). > > It works for me with the Hugin Windows SDK and MSVC9. I have not tested the > option to include Java support, and don't intend to. Will test on Ubuntu > soon. > > Regards, Tom I'd like a small change, to be able to use another build directory. So I can call cmake -DHUGIN_BASE_DIR=/usr/src/hugin /usr/src/panotools/trunk/libpano from my build-directory. /usr/src/hugin :Base of my hugin sources /usr/src/panotools/trunk/libpano: Patch to the CMakeLists.txt of pano13 Apart from that, it is not compilable on OpenSUSE due to missing libgimp/gimp.h, gtk/gtk.h ... /usr/local/bin/gcc -O3 -DNDEBUG -o CMakeFiles/libpano13.dir/PTDialogs.o -c /usr/src/panotools/trunk/libpano/PTDialogs.c In file included from /usr/src/panotools/trunk/libpano/PTDialogs.c:36: /usr/src/panotools/trunk/libpano/sys_X11.h:23:26: error: libgimp/gimp.h: No such file or directory /usr/src/panotools/trunk/libpano/sys_X11.h:24:21: error: gtk/gtk.h: No such file or directory ... (Compiling with bootstrap, configure and make was ok though) gcc -DHAVE_CONFIG_H -I. -I/usr/lib/jvm/java/include -I/usr/lib/jvm/java/include/linux -DHasJava -DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -D__Ansi__=1 -g -O2 -MT PTDialogs.lo -MD -MP -MF .deps/PTDialogs.Tpo -c PTDialogs.c -fPIC -DPIC -o .libs/PTDialogs.o Kornel -- Kornel Benko Kor...@be... |
From: Bruno P. <br...@po...> - 2009-08-04 12:51:02
|
On Tue 04-Aug-2009 at 08:31 +0200, Kornel Benko wrote: > >I'd like a small change, to be able to use another build directory. So I can call > > cmake -DHUGIN_BASE_DIR=/usr/src/hugin /usr/src/panotools/trunk/libpano > >from my build-directory. > /usr/src/hugin :Base of my hugin sources > /usr/src/panotools/trunk/libpano: Patch to the CMakeLists.txt of pano13 > >Apart from that, it is not compilable on OpenSUSE due to missing > libgimp/gimp.h, gtk/gtk.h There are files in libpano13 that shouldn't be compiled on Linux. Try removing PTDialogs.c from the CMakeLists.txt file. >/usr/local/bin/gcc -O3 -DNDEBUG -o CMakeFiles/libpano13.dir/PTDialogs.o -c /usr/src/panotools/trunk/libpano/PTDialogs.c >In file included from /usr/src/panotools/trunk/libpano/PTDialogs.c:36: >/usr/src/panotools/trunk/libpano/sys_X11.h:23:26: error: libgimp/gimp.h: No such > file or directory >/usr/src/panotools/trunk/libpano/sys_X11.h:24:21: error: gtk/gtk.h: No such file > or directory -- Bruno |
From: Kornel B. <Kor...@be...> - 2009-08-04 13:53:46
Attachments:
cmake.diff
|
Am Tuesday 04 August 2009 schrieb Bruno Postle: > There are files in libpano13 that shouldn't be compiled on Linux. > Try removing PTDialogs.c from the CMakeLists.txt file. > Like the attached? (The change in line 21 was neede, since HUGIN_SOURCE_DIR was not defined) Kornel -- Kornel Benko Kor...@be... |
From: Kornel B. <Kor...@be...> - 2009-08-04 13:59:44
Attachments:
cmake.diff
|
Am Tuesday 04 August 2009 schrieb Kornel Benko: > Am Tuesday 04 August 2009 schrieb Bruno Postle: > > There are files in libpano13 that shouldn't be compiled on Linux. > > Try removing PTDialogs.c from the CMakeLists.txt file. > > > > Like the attached? > (The change in line 21 was neede, since HUGIN_SOURCE_DIR was not defined) > > Kornel Sorry for this diff. This is better. Kornel -- Kornel Benko Kor...@be... |
From: Thomas S. <tks...@gm...> - 2009-08-04 14:07:15
|
Hi Bruno Your patch works on my Ubuntu system, too, and doesn't break the Windows build. So I have committed it. Regards, Tom On Tue, Aug 4, 2009 at 9:35 AM, Bruno Postle <br...@po...> wrote: > On Tue 04-Aug-2009 at 09:01 -0400, Tom Sharpless wrote: > >> On Tue, Aug 4, 2009 at 8:50 AM, Bruno Postle <br...@po...> wrote: >> >>> >>> There are files in libpano13 that shouldn't be compiled on Linux. >>> Try removing PTDialogs.c from the CMakeLists.txt file. >>> >> >> Are you saying that PTDialogs is hopelessly broken on Unix? Do we need it >> on Windows? If so, should we fix it for X11? >> > > The Windows versions of the tools have always had pop-up progress windows, > but the Linux version has always been command-line only (which is what we > want). > > I had it all wrong, this failure is caused by __Ansi__ and __Win__ not > being set in the CMakeLists.txt file. > > This patch fixes it for Linux: > > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 1020) > +++ CMakeLists.txt (working copy) > @@ -39,6 +39,7 @@ > # finding the wxWidgets distributions of those packages (Win32 only). > IF (WIN32) > SET(wxWidgets_ROOT_DIR ${SOURCE_BASE_DIR}/wxWidgets-2.8.10) > + ADD_DEFINITIONS(-D__Win__) > ENDIF(WIN32) > > FIND_PACKAGE(wxWidgets REQUIRED) > @@ -72,6 +73,7 @@ > ENDIF(${CMAKE_BUILD_TYPE} STREQUAL "Debug") > > IF (UNIX) > + ADD_DEFINITIONS(-D__Ansi__) > ELSE (UNIX) > IF (MSVC) > # Stop MSVC8 from bitching about the C library > @@ -175,4 +177,4 @@ > ZComb.c > ) > > |