From: Pablo d'A. <pab...@we...> - 2006-04-19 20:24:36
Attachments:
projections.patch
|
Hi, Here is a patch that adds support for mercator, transverse mercator, sinusoidal and stereographic projection to panotools. I'd like to use these features in hugin 0.6. The new projections can be specified on the p line, just like the traditional ones: f4 - stereographic f5 - mercator f6 - transverse mercator f7 - sinusoidal (mainly for use with devalvr) Both forward and backwards transformations are implemented, so it should be possible to uses the antialiasing filters, though I haven't tried that yet. Currently the sinusoidal output is not completely correct, since the unused areas near the corners are not set to zero, but filled with garbage. This happens, because the currently, there is no way for the transformation functions to report wether a pixel in the panorama image is valid or not. Changing that would require a changes to the API, which might break programs that call the transform functions directly. (PTGui and PTMac might do this/might have done this). The ugly workaround would be to add a global variable that indicates wether the transform is successfull or not. However, this will break the multithreaded remapping supported by hugin and nona, and is therefore not a clean solution. ciao Pablo |
From: Bruno P. <br...@po...> - 2006-04-19 22:51:09
|
On Wed 19-Apr-2006 at 22:22 +0200, Pablo d'Angelo wrote: > > Here is a patch that adds support for mercator, transverse mercator, > sinusoidal and stereographic projection to panotools. Pretty cool, they work for me using PTmender. There are a couple of things I noticed after a quick look around: 'Transverse mercator' produces a very narrow field of view even if I set the HFOV to 179 degrees, the mapping also flips left to right above and below the zenith and nadir. 'stereographic' is meaningless at 360 degrees HFOV and above (a bit like rectilinear at 180 degrees), so this should generate an error. -- Bruno |
From: Daniel M. G. <dmg...@uv...> - 2006-04-20 06:36:51
|
Pablo> Changing that would require a changes to the API, which might break programs Pablo> that call the transform functions directly. (PTGui and PTMac might do Pablo> this/might have done this). One way to ease the pain is to do a version number upgrade. I think we need to start thinking about it. After all the new features warrant it. My $0.02 dmg -- Daniel M. German "Science can be esoteric The Economist -> technology has to be pragmatic" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: <jwa...@ph...> - 2006-04-20 13:40:13
|
> Pablo> Changing that would require a changes to the API, which might > Pablo> break programs that call the transform functions directly. > Pablo> (PTGui and PTMac might do this/might have done this). > > > One way to ease the pain is to do a version number upgrade. I think we > need to start thinking about it. After all the new features warrant it. > > My $0.02 > > dmg I would like the next release of PanoTools to include all tools bundled together. Make it a major release. There definitely are programs that call transform functions directly ( plug-ins, Pano2QTVR, ). The best thing probably would be to change the name of the DLL/library from pano12 (pano13 comes to mind). We should also maintain the current version. So splitting the source tree is probably in order. If we are going to split the source tree and create a new version we should incorporate as many things as possible. There have been several items that I can not recall right now, that were put on hold because of backwards compatibility. I should really dig through my messages and submit feature request for all of these so they can be tracked. Jim Watters |
From: Bruno P. <br...@po...> - 2006-04-20 14:24:54
|
On Thu 20-Apr-2006 at 09:39 -0400, jwa...@ph... wrote: > > > there is no way for the transformation functions to report > > > wether a pixel in the panorama image is valid or not Surely something like this happens already? How do the empty/transparent areas of output around remapped images get generated otherwise? [snip changing the API] > The best thing probably would be to change the name of the DLL/library > from pano12 (pano13 comes to mind). This shouldn't be necessary. These other tools can either change to suit the new API or ship with an older version of the library. ...or the extended API can live in newly named functions and the old functions can just be wrappers around them. -- Bruno |
From: Pablo d'A. <pab...@we...> - 2006-04-20 16:30:24
|
Bruno Postle wrote > On Thu 20-Apr-2006 at 09:39 -0400, jwa...@ph... wrote: > >> > > there is no way for the transformation functions to report > > >> wether a pixel in the panorama image is valid or not > > > Surely something like this happens already? How do the > empty/transparent areas of output around remapped images get generated > otherwise? Because this happens based on wether the input image alpha channel or crop setting excludes the pixel in the *source* image. However, currently there is no way that an output pixel can be set to invalid. It works like this: transformImage() { for all pixels in pano image: transform pano coordinates to src image coordinates interpolate from source image, if inside src image. } the coordinate transforms the pano image coordinates into spherical coordinates, applies yaw, roll and pitch, applies distortion correction etc. The problem is that the transform from the output panorama projection to spherical coordiantes is always valid. ie. there are no invalid spherical coordinates, even a latitude of 10^30 degrees is valid. So there needs to be a way that the sinusoidal -> spherical transform reports invalid input coordinate. For example, this is possible with circular fisheye and sinusoidal panos. > [snip changing the API] > >> The best thing probably would be to change the name of the DLL/library >> from pano12 (pano13 comes to mind). > > This shouldn't be necessary. These other tools can either change to > suit the new API or ship with an older version of the library. > > ...or the extended API can live in newly named functions and the old > functions can just be wrappers around them. Actually, in this case I vote for changing the API. The only affected functions are the really low level coordinate transform functions, which are not likely to be used by binary, non open source programs (which are theoretically not allowed to link against the GPL'ed panotools anyway...). Most tools will probably use the MakeTransform() and execute_stack() functions, and not the low level functions (erect_pano etc.) directly. Actually I don't know, but I speculate that PTStereo might use these low level functions directly, and might break, so a wrapper might still be useful. My proposal is then to extend the API (as suggested by Bruno), introducing a new int execute_stack_try ( double x_dest,double y_dest, double* x_src, double* y_src, void* params ); and related transform functions like: int erect_rect_try ( double x_dest,double y_dest, double* x_src, double* y_src, void* params ); There would be wrappers around the old functions that will just call the _try variants and discart the return code. ciao Pablo |
From: Daniel M. G. <dmg...@uv...> - 2006-04-21 01:21:37
|
Hi Pablo, Is the #include <malloc.h> needed under linux? It creates a compilation error (it is in <system/malloc.h> in OS X) hence I replaced it with <stdlib.h>. I am just wondering if you changed it back by mistake or you overrode my change. daniel ---------------------------------------------------------------------- revision 1.3 date: 2006/04/20 23:01:41; author: dangelo; state: Exp; lines: +1 -1 added stereographic, mercator, transverse mercator and sinusoidal projection. Transverse mercator does not work properly yet. Modified all coordinate transfor m functions to return if the transformation was possible. (Not used during stitchi ng yet) ---------------------------- revision 1.2 date: 2006/04/09 23:07:38; author: dmg; state: Exp; lines: +1 -1 2006-04-09 dmg <dmg...@uv...> * rgbe.c: Replaced #include <malloc.h> with <stdlib.h> to avoid MacOS compilation error ---------------------------------------------------------------------- -- Daniel M. German "No one can be a great thinker who does not recognize, that as a thinker it is his first duty to follow his intellect to whatever John Stuart Mill -> conclusions it may lead." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2006-04-21 07:03:04
|
Hi Daniel, > Hi Pablo, > > Is the #include <malloc.h> needed under linux? It creates a > compilation error (it is in <system/malloc.h> in OS X) hence I > replaced it with <stdlib.h>. > > I am just wondering if you changed it back by mistake or you overrode > my change. Sorry, this must have happened when moving my changes to the new developer cvs working copy. fixed in cvs. ciao Pablo |
From: Daniel M. G. <dmg...@uv...> - 2006-04-20 18:36:34
|
jwatters twisted the bytes to say: Pablo> Changing that would require a changes to the API, which might Pablo> break programs that call the transform functions directly. Pablo> (PTGui and PTMac might do this/might have done this). >> >> >> One way to ease the pain is to do a version number upgrade. I think we >> need to start thinking about it. After all the new features warrant it. >> >> My $0.02 >> >> dmg Jim> I would like the next release of PanoTools to include all tools bundled Jim> together. Make it a major release. Jim> There definitely are programs that call transform functions directly ( Jim> plug-ins, Pano2QTVR, ). Jim> The best thing probably would be to change the name of the DLL/library Jim> from pano12 (pano13 comes to mind). Jim> We should also maintain the current version. So splitting the source tree Jim> is probably in order. Yes, I suggest creating a branch for pano12, and using the main trunk for the current development. WHy don't we use a linux approach to numbering: pano13 for development, and pano14 for stable? Jim> If we are going to split the source tree and create a new version we Jim> should incorporate as many things as possible. There have been several Jim> items that I can not recall right now, that were put on hold because of Jim> backwards compatibility. I should really dig through my messages and Jim> submit feature request for all of these so they can be tracked. We can make list of features that we will include in the next release an work towards that. Jim> Jim Watters Jim> ------------------------------------------------------- Jim> Using Tomcat but need to do more? Need to support web services, security? Jim> Get stuff done quickly with pre-integrated technology to make your job easier Jim> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo Jim> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 Jim> _______________________________________________ Jim> PanoTools-devel mailing list Jim> Pan...@li... Jim> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- 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...> - 2006-04-20 19:59:55
|
On Thu 20-Apr-2006 at 11:36 -0700, Daniel M. German wrote: > > Yes, I suggest creating a branch for pano12, and using the main trunk > for the current development. > WHy don't we use a linux approach to numbering: pano13 for > development, and pano14 for stable? I'd hate to change the name of the library when it is basically the same thing as before. There is the version, currently 2.8.0, that should be used for these things. If you really think there is enough new stuff to warrant a stable/unstable split, then have a linux-style 2.8.x stable series and a 2.9.x unstable series. Though Linux abandoned this system some time ago, only developers used the unstable branch which never got any user testing. I suggest that once the new projection formats are in CVS, we should test a little, release 2.8.1 and see what bugs turn-up. -- Bruno |
From: Daniel M. G. <dmg...@uv...> - 2006-04-20 20:05:13
|
Bruno> On Thu 20-Apr-2006 at 11:36 -0700, Daniel M. German wrote: >> >> Yes, I suggest creating a branch for pano12, and using the main trunk >> for the current development. >> WHy don't we use a linux approach to numbering: pano13 for >> development, and pano14 for stable? Bruno> I'd hate to change the name of the library when it is basically the Bruno> same thing as before. Bruno> There is the version, currently 2.8.0, that should be used for these Bruno> things. If you really think there is enough new stuff to warrant a Bruno> stable/unstable split, then have a linux-style 2.8.x stable series Bruno> and a 2.9.x unstable series. Bruno> Though Linux abandoned this system some time ago, only developers Bruno> used the unstable branch which never got any user testing. Bruno> I suggest that once the new projection formats are in CVS, we should Bruno> test a little, release 2.8.1 and see what bugs turn-up. It sounds good. I'll also renumber the versions of PT(mender|bender) to match this number. There is no point on each having their own. From my part I'll make sure that support on these programs for JPG and 8 bit TIFF is complete. dmg Bruno> -- Bruno> Bruno Bruno> ------------------------------------------------------- Bruno> Using Tomcat but need to do more? Need to support web services, security? Bruno> Get stuff done quickly with pre-integrated technology to make your job easier Bruno> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo Bruno> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "For indeed who is there alive that will not be swayed by his bias and partiality to Jonathan Swift -> the place of his birth?" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2006-04-21 00:38:17
|
Bruno Postle wrote: > I'd hate to change the name of the library when it is basically the > same thing as before. If if can all work by some wrapper functions then all is good. I was worried that other programs would not be able to work correctly. -- Jim Watters Yahoo ID: j1vvy ymsgr:sendIM?j1vvy jwa...@ph... http://photocreations.ca |
From: Pablo d'A. <pab...@we...> - 2006-04-21 07:21:35
|
Jim Watters schrieb: > Bruno Postle wrote: > >> I'd hate to change the name of the library when it is basically the >> same thing as before. > > If if can all work by some wrapper functions then all is good. I was > worried that other programs would not be able to work correctly. The only change visible to the programs using libpano12 is that the prototype for the coordinate transform functions was changed to return int instead of void. typedef void (*trfn)( double x_dest,double y_dest, double* x_src, double* y_src, void* params ); has become: typedef int (*trfn)( double x_dest,double y_dest, double* x_src, double* y_src, void* params ); This might break programs that build their own transform stack, or use them directly. The common usage through execute_stack() still works. The transform functions themself were not exported to the pano12.dll, even if the are in the header file. So there is no chance that programs could access those (under windows at least). ciao Pablo |
From: Pablo d'A. <pab...@we...> - 2006-04-26 21:43:24
|
Pablo d'Angelo schrieb: > Hi, > > Here is a patch that adds support for mercator, transverse mercator, > sinusoidal and stereographic projection to panotools. I'd like to use these > features in hugin 0.6. > > Currently the sinusoidal output is not completely correct, since the unused > areas near the corners are not set to zero, but filled with garbage. This > happens, because the currently, there is no way for the transformation > functions to report wether a pixel in the panorama image is valid or not. I have added the required functionality to the coordinate transform and the image transform functions. Now, PTmender can create nice sinusoidal output. ciao Pablo |