From: Ippei U. <ipp...@ma...> - 2007-03-13 22:10:31
|
On 2007-03-13, at 20:36, Daniel M. German wrote: > Hi Ippei, > > Ippei> My idea was to restructure the panotools into: > > Ippei> 1. Good data structure > Ippei> - File format (currently script, but we could define a new > better > Ippei> schemes with XML) > Ippei> - IO functionality that converts between the file format > and the data > Ippei> representations used in the programs. > Ippei> - Panorama data representations that can be used by many > applications > Ippei> (C++ class / C structure + functions) > > Panotools needs a total rehaul from the internal point of view, IMO. > > But the reality is that you don't need a complex data structure to > call panotools. I think we are getting the same place anyway. I was rather thinking in OOP stylistics, and probably the flat C way of implementing it is what you are suggesting here. > Panotools does two things, mainly: > > 1. OPtimization step (what I call registration). It receives as an > input a bunch of control points and does its best to "match" > them. In its current implementation it does not require access to > the images. It outputs a set of <yaw,roll,pitch> for each image, + > lens parameters for each different lens. > > 2. Mapping. Takes an image, yaw, roll and pitch, and lens parameters, > + optional morph-to control points. Output is an image. I see. I was looking at it rather as data + operations rather than pipe-lined operations. > I lean towards the idea of encapsulation. you don't want the caller to > know more than it needs. What we need are functions that take all the > information as input and return the corresponding result. Doing that > will oviate the need to use scripts, and it will make the rewriting > the panotools easier. > > So what is neeeded are data structures that replace the parameters > (there are too many). The data structure should be marshall-able as an > XML file (or even a PTstitcher script). > > In fact, once this data structure is defined and implemented, it will > be easy to split panotools into 2 different systems: optimization and > mapping. Having both in one library makes things more complex than > they need to be. That's exactly what I was suggesting:) And with a few design consideration, that XML can hold any combination of image information, lens information, mapping information etc. which makes perfect for hugin as well as single task that only requires one or two of those. > Ippei> Apologies if I've misunderstood the nature of problems, but > I thought > Ippei> the problem was that the data representation is sort of in > a higher > Ippei> level and a lower level representation that all > applications can > Ippei> happily use directly would be desirable. I just thought > something > Ippei> like XML can be defined modular so that one project can > have one > Ippei> representation of where the photos are mapped on the > sphere, three of > Ippei> camera/lens parameters, and two of how those should be > output etc. It > Ippei> even allows us to separate files for each of those. > > The problem, in my opinoin, is that there are no functions to call in > panotools to do either job only. True. And that's the problem I'm looking at, just wasn't thinking in terms of the library structure. Anyway, with your clarification, it now looks much simpler than I thought. Sounds like another possibility for the SoC project that I might be able to choose from:) Ippei -- ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |
From: Daniel M. G. <dm...@uv...> - 2007-03-13 22:56:44
|
Hi Ippei, Ippei> I think we are getting the same place anyway. I was rather thinking Ippei> in OOP stylistics, and probably the flat C way of implementing it is Ippei> what you are suggesting here. Wrapping panotools with C++ would be a great idea. In summary, what this job requires is to replace the parser of panootools. This is not easy, because they are too many things done during parsing, and the parser is very messy in its current state. dmg -- Daniel M. German "The WWW might get the glory, but e-mail is the quiet Beppi Crosanol -> workhorse of the digital age." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2007-03-15 17:31:02
|
Ippei UKAI wrote: > On 2007-03-13, at 23:17, Pablo d'Angelo wrote: > >>> In fact, once this data structure is defined and implemented, it will >>> be easy to split panotools into 2 different systems: optimization and >>> mapping. Having both in one library makes things more complex than >>> they need to be. >>> >> And both will depend on the projection library :-) >> > > I'm confused. I thought mapping/optimisation is done to put the > images on the sphere surface (or whatever way in a 3D space), and > projection/stitcher engine produces the images by sort of taking > picture from the centre of that world with different projections (or > an interactive VR snap, or even a movie which could be really cool). > I don't understand why would the optimisation process ever need to > know about the projection. > Going by memory. The error reported back from the optimizer is the distance the on the projection selected. The error used internally to find closest fit, is the distance on a sphere for normal control points but for lines (horizontal, vertical, and straight) control points it uses the projection selected. It may be worth investigating if all line control points should be optimized for rectilinear projection regardless of projection selected. The problem: no longer able to use line control points to optimize a pan taken from a the center of a circle to spherical projection. -- Jim Watters jwatters @ photocreations . ca http://photocreations.ca |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 22:45:49
|
Hi Jim, >> images on the sphere surface (or whatever way in a 3D space), and >> projection/stitcher engine produces the images by sort of taking >> picture from the centre of that world with different projections (or >> an interactive VR snap, or even a movie which could be really cool). >> I don't understand why would the optimisation process ever need to >> know about the projection. >> Jim> Going by memory. Jim> The error reported back from the optimizer is the distance the on the Jim> projection selected. I agree, we have to check several of the statements we make here :) Jim> The error used internally to find closest fit, is the distance on a Jim> sphere for normal control points but for lines (horizontal, vertical, Jim> and straight) control points it uses the projection selected. You are totally right, I forgot about straight lines in my previous posting. But straight lines only make sense for rectilinear (I don't think people use them for the other azimuthal --fisheye-- and it is certainly meaningless in any other type of projection). Jim> It may be worth investigating if all line control points should be Jim> optimized for rectilinear projection regardless of projection selected. Jim> The problem: no longer able to use line control points to optimize a pan Jim> taken from a the center of a circle to spherical projection. Jim> -- Jim> Jim Watters Jim> jwatters @ photocreations . ca Jim> http://photocreations.ca Jim> ------------------------------------------------------------------------- Jim> Take Surveys. Earn Cash. Influence the Future of IT Jim> Join SourceForge.net's Techsay panel and you'll get the chance to share your Jim> opinions on IT & business topics through brief surveys-and earn cash Jim> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Jim> _______________________________________________ Jim> PanoTools-devel mailing list Jim> Pan...@li... Jim> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "One thing I have learned in a long life: that all our science, measured against reality, is primivite and childlike --and yet it is the most precious thing Albert Einstein -> we have. " http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2007-03-15 22:56:02
|
Hi Daniel, > Hi Ippei > > 1. The registration maps an image to a sphere. It is in this sphere that > optimization happens. In other words, panotools trie to find where in > this sphere this image corresponds to. > > 2. The mapping takes this sphere and projects it. > > Both 1 and 2 require a projection library, but not to the same extend. > > 1 takes as input only rectilinear, equirectangular, fisheye equisolid > (correct me if I am wrong, but this sounds like azimuth equal area) > and cylindrical (I don't really know why cylindrical, but that is a > different story). Well, thats a very simple cylinder projection, as produced by swing lens cameras. > 2 takes the sphere and projects into whatever we want. Panotools > supports 10 (I think) projection (tlalli has 14). > > > 1 only requires very simple projections. > > > This is the conundrum. Should we support more input projections? I > would say no, but not to close the door and hardcode it. Why not? Who knows, maybe sometime you want to reproject that panorama in Mercator projection into something else, but you have lost the source images? Then this will be very useful. I don't like to artificially restrict functionality if there is no good reason to do so. Keep it flexible. > The reason that the optimization needs to know the input projection is > that it needs to know where an x,y point in the photo corresponds to > the sphere. > > Why thing that panotools does not do is to assume a flat field, > instead of a sphere to stitching. That limits the use of panotools, > and makes it difficult to stitch "murals" and similar objects when you > know the photos were "perfectly" parallel to each other This is something that should be changed as well during an overhaul. Internally, the panotools projections are all 2D <-> 2D. Within that model, the plane to plane projection could be also handled. It would just require some additional parameters, namely the 3D position of the camera with respect to the output plane. So this would require an additional set of x y z parameters (probably this is still there from the PTStereo and PTInterpolate programs :-) for each image, and a new output projection which is just a flat plane, without a HFOV. This would be very useful. For example, in the past I had several requests form people, mostly scientists, who wanted to stitch the images they have captured with cameras onboard a unstable unmanned aerial vehicle into a large, planar ground map. > I think rehauling panotools is a summer project. And it will be fun, > but it requires a lot of reengenering to get it "right". Maybe you can add it to the list of projects on http://wiki.panotools.org/SoC2007_projects ciao Pablo |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 23:03:03
|
Pablo d'Angelo twisted the bytes to say: >> I think rehauling panotools is a summer project. And it will be fun, >> but it requires a lot of reengenering to get it "right". Pablo> Maybe you can add it to the list of projects on Pablo> http://wiki.panotools.org/SoC2007_projects I'll do. Pablo> ciao Pablo Pablo> ------------------------------------------------------------------------- Pablo> Take Surveys. Earn Cash. Influence the Future of IT Pablo> Join SourceForge.net's Techsay panel and you'll get the chance to share your Pablo> opinions on IT & business topics through brief surveys-and earn cash Pablo> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Pablo> _______________________________________________ Pablo> PanoTools-devel mailing list Pablo> Pan...@li... Pablo> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "If debugging is the art of removing bugs, then programming must Anonymous -> be the art of inserting them." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2007-03-15 22:59:43
|
On Thu 15-Mar-2007 at 12:44 -0700, Daniel M. German wrote: > > But straight lines only make sense for rectilinear (I don't think > people use them for the other azimuthal --fisheye-- and it is > certainly meaningless in any other type of projection). The vertical control points are useful for levelling equirectangular and cylindrical panoramas. Horizontal control points are useful for leveling the horizon in equirectangular and cylindrical panoramas, good for seaside scenes. Straight-line control points are useful in any projection as they don't really have to be used strictly with straight lines. The classic case is with overhead wires, these curve in all projections but you can align them nonetheless with straight-line control points. -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2007-03-15 23:04:37
|
Bruno Postle twisted the bytes to say: Bruno> On Thu 15-Mar-2007 at 12:44 -0700, Daniel M. German wrote: >> >> But straight lines only make sense for rectilinear (I don't think >> people use them for the other azimuthal --fisheye-- and it is >> certainly meaningless in any other type of projection). Bruno> The vertical control points are useful for levelling equirectangular Bruno> and cylindrical panoramas. yes, by straight lines I mean straight that are not vertical or horizontal. Those two are very important. Bruno> Horizontal control points are useful for leveling the horizon in Bruno> equirectangular and cylindrical panoramas, good for seaside scenes. Bruno> Straight-line control points are useful in any projection as they Bruno> don't really have to be used strictly with straight lines. The Bruno> classic case is with overhead wires, these curve in all projections Bruno> but you can align them nonetheless with straight-line control Bruno> points. Ok, I am with you. This means that even if they are meaningless, they are still useful :) Call it art :) Bruno> -- Bruno> Bruno Bruno> --~--~---------~--~----~------------~-------~--~----~ Bruno> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. Bruno> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ Bruno> To post to this group, send email to hug...@go... Bruno> To unsubscribe from this group, send email to hug...@go... Bruno> For more options, visit this group at http://groups.google.com/group/hugin-ptx Bruno> -~----------~----~----~----~------~----~------~--~--- -- Daniel M. German "Cyberspace. A consensual hallucination experienced daily by billions William Gibson -> of legitimate operators in every nation" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2007-03-16 02:52:47
|
Ippei> I wonder any cross-platform CPU-only compatible GPU-aware tool is up Ippei> there. On Mac, Apple's Quartz Composer does something really Ippei> interesting; please look at the screenshot (I tried it out two years Ippei> ago when Tiger came out). It's based on GLSL, and runs with the best Ippei> available processor unit on the machine (GPU/AltiVec/SSE). Ippei> Anyway, I think the best is to make sure we will have a fixed API for Ippei> any small components of the library (that's what I learnt in CS1; Ippei> break up tasks and give each component as generic interface as Ippei> possible). That way, we can easily extend/replace/modify only the Ippei> required part later whatever implementation we choose now. Moreover, Ippei> I think we should prefer LGPL for newly written parts so that some Ippei> developers could write closed source versions of specific part of the Ippei> library for their purposes. The already written part can be modified Ippei> to follow the same new APIs still remaining under GPL. We already had a long discussion on this. The quick answer is no, we can't change the license of derivations of panotools. A new library could be LGPL, but I am not interested in creating LGPL software. There is also the fact that an LGPL license will restrict us to only use LGPL and BSD-type licensed software. The GNU Scientific Library is GPL, and it should be used. Ippei> I think I'm going to apply for this one as well as the hugin Ippei> renovation. If someone who is better at Qt4 or whatever GUI library Ippei> wanted the hugin work, I'd be more useful working on this one. Ippei> Ippei It sounds good. Panotools is quite good at what it does, but it is written in a very monolithic way. I don't think that anybody really knows it 100%. In a way PTblender, PTroller, PTcrop, PTuncrop, and PTtiff2psd have been attempts to create some modularity and encapsulation. The first step towards this goal is to improve the testing framework. We cannot really proceed to rehaul until we have some reference tests. dmg -- Daniel M. German "Any sufficiently advanced technology is indistinguishable Arthur C. Clarke -> from magic." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Ippei U. <ipp...@ma...> - 2007-03-16 03:12:00
|
On 2007-03-16, at 02:10, Daniel M. German wrote: > Ippei> Anyway, I think the best is to make sure we will have a =20 > fixed API for > Ippei> any small components of the library (that's what I learnt =20 > in CS1; > Ippei> break up tasks and give each component as generic interface as > Ippei> possible). That way, we can easily extend/replace/modify =20 > only the > Ippei> required part later whatever implementation we choose now. =20 > Moreover, > Ippei> I think we should prefer LGPL for newly written parts so =20 > that some > Ippei> developers could write closed source versions of specific =20 > part of the > Ippei> library for their purposes. The already written part can be =20= > modified > Ippei> to follow the same new APIs still remaining under GPL. > > We already had a long discussion on this. The quick answer is no, we > can't change the license of derivations of panotools. A new library > could be LGPL, but I am not interested in creating LGPL software. > > There is also the fact that an LGPL license will restrict us to only > use LGPL and BSD-type licensed software. The GNU Scientific Library is > GPL, and it should be used. I have roughly followed the discussion about the license. I'm only =20 saying that the newly written 'interface' and 'I/O file format =20 parsers' could stay out of GPL, so that it can have non GPL =20 implementation out of scope of our projects. It's not the derivatives. The current implementation stays GPL because there are no way back. I =20= know that. I have used a library which is in GPL only because it's =20 derived from a GPL'ed application; inherently I had no choice other =20 than releasing my software with GPL not BSD. I think nothing can stop renewing the current implementations to use =20 LGPL'ed interface and file parsers, and at least I feel it's =20 desirable to allow commercial implementations that reads the same =20 file formats. > Ippei> I think I'm going to apply for this one as well as the hugin > Ippei> renovation. If someone who is better at Qt4 or whatever GUI =20= > library > Ippei> wanted the hugin work, I'd be more useful working on this one. > > Ippei> Ippei > > It sounds good. Panotools is quite good at what it does, but it is > written in a very monolithic way. I don't think that anybody really > knows it 100%. > > In a way PTblender, PTroller, PTcrop, PTuncrop, and PTtiff2psd have > been attempts to create some modularity and encapsulation. > > The first step towards this goal is to improve the testing > framework. We cannot really proceed to rehaul until we have some > reference tests. -- ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3 (UKAI Ippei) = ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |
From: Ippei U. <ipp...@ma...> - 2007-03-16 02:54:26
|
On 2007-03-15, at 22:55, Pablo d'Angelo wrote: > > Hi Daniel, > >> Hi Ippei >> >> 1. The registration maps an image to a sphere. It is in this =20 >> sphere that >> optimization happens. In other words, panotools trie to find where in >> this sphere this image corresponds to. >> >> 2. The mapping takes this sphere and projects it. >> >> Both 1 and 2 require a projection library, but not to the same =20 >> extend. >> >> 1 takes as input only rectilinear, equirectangular, fisheye equisolid >> (correct me if I am wrong, but this sounds like azimuth equal area) >> and cylindrical (I don't really know why cylindrical, but that is a >> different story). > > Well, thats a very simple cylinder projection, as produced by swing > lens cameras. > >> 2 takes the sphere and projects into whatever we want. Panotools >> supports 10 (I think) projection (tlalli has 14). >> >> >> 1 only requires very simple projections. >> >> >> This is the conundrum. Should we support more input projections? I >> would say no, but not to close the door and hardcode it. > > Why not? Who knows, maybe sometime you want to reproject that =20 > panorama in > Mercator projection into something else, but you have lost the source > images? Then this will be very useful. I don't like to artificially =20= > restrict > functionality if there is no good reason to do so. Keep it flexible. So, we have projections to and from the sphere because we have to =20 reverse the projection of the original lens/camera from the real =20 world to the photo, not only the projection from the sphere to the =20 resulting panorama. That means we have two types of projections: 2D =20 to sphere and sphere to 2D, and their interface are similar but =20 opposite in domains and co-domains, and some of them may be the =20 complete inverse of another. That makes sense to me now. Is this something to do with the hugin's limitation to optimise =20 parameters while the output projection of the panorama is not one of =20 three basic ones? What I understood from above is that the =20 optimisation and output projection are independent of each other. >> The reason that the optimization needs to know the input =20 >> projection is >> that it needs to know where an x,y point in the photo corresponds to >> the sphere. >> >> Why thing that panotools does not do is to assume a flat field, >> instead of a sphere to stitching. That limits the use of panotools, >> and makes it difficult to stitch "murals" and similar objects when =20= >> you >> know the photos were "perfectly" parallel to each other > > This is something that should be changed as well during an overhaul. > Internally, the panotools projections are all 2D <-> 2D. Within =20 > that model, > the plane to plane projection could be also handled. It would just =20 > require > some additional parameters, namely the 3D position of the camera with > respect to the output plane. > > So this would require an additional set of x y z parameters =20 > (probably this > is still there from the PTStereo and PTInterpolate programs :-) for =20= > each > image, and a new output projection which is just a flat plane, =20 > without a > HFOV. > > This would be very useful. For example, in the past I had several =20 > requests > form people, mostly scientists, who wanted to stitch the images =20 > they have > captured with cameras onboard a unstable unmanned aerial vehicle =20 > into a large, > planar ground map. So because of this spherical nature of the world, it is surely not =20 trivial to stitch photos that cannot be assumed to be taken from one =20 point in the 3D world... but do you mean we'll have multiple spheres =20 and need to optimise their relative positions to an intermediate =20 output plane, from which we'll get another sphere for the usual =20 output projection??? That certainly sounds really really powerful... =20 but sounds like so big the difference is that this should happen =20 separately from the interface reorganisation. >> I think rehauling panotools is a summer project. And it will be fun, >> but it requires a lot of reengenering to get it "right". > > Maybe you can add it to the list of projects on > http://wiki.panotools.org/SoC2007_projects If that is to reorganise the panotools into: 1. Registration optimization 2. Remapping of sphere to output projection 3. Projections library 4. Parsing of input/output then that would be my second choice of the project. That would be =20 nice if you could add it with a brief description, but I'll be =20 writing my version of the detailed project description anyway. (Actually it interests me more then the GUI, but I feel the GUI =20 should have a higher priority in the todo list from the user point of =20= view. I would so loved to do both, but a summer would be too short...) Ippei -- ->> =E9=B5=9C=E9=A3=BC =E4=B8=80=E5=B9=B3 (UKAI Ippei) = ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ |
From: Daniel M. G. <dm...@uv...> - 2007-03-16 03:11:10
|
Hi Ippei, Ippei> On 2007-03-15, at 22:55, Pablo d'Angelo wrote: Ippei> So, we have projections to and from the sphere because we have to Ippei> reverse the projection of the original lens/camera from the real Ippei> world to the photo, not only the projection from the sphere to the Ippei> resulting panorama. That means we have two types of projections: 2D Ippei> to sphere and sphere to 2D, and their interface are similar but Ippei> opposite in domains and co-domains, and some of them may be the Ippei> complete inverse of another. That makes sense to me now. Exactly. But panotools is very smart on this: it does not really create a sphere. Instead it creates a "stack of operations": map from lens -> equirectangular (the "raw" sphere, because a normalized x, y in the equirectangular corresponds to a yaw, tilt in the sphere ) -> projection. In other words, it creates a pipeline of operations that needs to be computed. The process to create the image is: for every pixel in the output image: * Using the computation stack determine the pixels in the source image that it needs (it usually requires a neiborhood, in order to apply the correct appropriate interpolation --this is why sync1024 is significantly slower than bilinear). I like the computation stack model. It is powerful. But it is also very difficult to improve and maintain. I am not suggesting it to be rehauled. The rehauling would be in making sure it has a cleaner interface between projections and remapping. To give you an idea of how clutter things are. Addinga projection involves modifing 6 or 7 files. Ippei> Is this something to do with the hugin's limitation to optimise Ippei> parameters while the output projection of the panorama is not one of Ippei> three basic ones? What I understood from above is that the Ippei> optimisation and output projection are independent of each other. No, it is just that when we added new projections we did not bother to add them as input projections, only as oputput ones. -- Daniel M. German "Computer Science is no more about computers than astronomy Edsger Dijkstra -> is about telescopes" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2007-03-17 21:16:40
|
Ippei UKAI schrieb: > On 2007-03-16, at 03:11, Daniel M. German wrote: > >> Hi Ippei, >> >> I like the computation stack model. It is powerful. But it is also >> very difficult to improve and maintain. > > So it computes the composition of all the operations on the images > and apply it over the bitmap matrix. That's clever way to handle non- > discrete intermediate coordinates. And this is one of the big strengths of panotools. We need to keep that. The transform stack can be treated as a black box, and can represent a all different kinds of 2D<->2D transformations. Currently panotools builds the stack so that everything goes through a spherical model internally, but this is not a fundamental requirement! Interesting features are possible if we allow other transformations as well. Just think how complicated this conceptually very elegant procedure is: http://wiki.panotools.org/Fixing_nadir_parallax_errors I believe the maintainance difficulties are more due to technical reasons and not due to the flexibility of the transform stack approach. > Sounds like we need something like > OpenGL Shading Language that can be manipulated on runtime and > executed very fast according to the output resolution. I have no idea > how it could be done in C to be honest though. I'm too used to OOP. Using hardware acceleration is an attractive idea, however generality should not be sacrified. I think it might be useful to build dedictated transformations for the most common use cases. >> Ippei> What I understood from above is that the >> Ippei> optimisation and output projection are independent of each >> other. >> >> No, it is just that when we added new projections we did not bother to >> add them as input projections, only as oputput ones. > > Okay, I think I'm still lost here. Why do we need the input versions > of the output projections for optimisation if the optimisation is > independent from the output projection process? Actually an output projection has to be specified for the optimisation, however, currently only rectilinear, cylindrical and spherical are available, with spherical being the logical solution for 360x180 deg panos. But lets step back. I will try to summarize how the stuff related to projections works in panotools. 1. remapping is quite simple: (pano image coordinate P_j) -> [transform_stack_i(x_i)] -> (image i coordinates I_ij) transform_stack_i(x_i) is the transformation function parametrized with different parameters x_i (yaw, roll, pitch, hfov) for each input image i. You can use different projections for each input image, thus different transform stacks are required. The pixel found in the image is then placed in the panorama image. Actually, in the literature this is usually called inverse mapping, since the forward mapping, which transforms the input image coordinates I into the panorama coordinates P has some drawbacks when actual images should be remapped: http://blogs.mathworks.com/steve/?p=53 2. In order to calculate the function above, the parameters x_i need to be determined. This is done using the optimizer. Here stuff gets tricky. There are two ways to attack the problem, and the second one I describe is used in panotools, so feel free to skip to II) if you head aches while reading I): I) using the same transformation as for the remapping: Assume that we roughly know the coordinate P_j in the panorama image and have measured the associated image coordinates I_ij (corresponding points in the images). Then we can transform P_j into each image, resulting in image coordinates I*_ij. In order to make the images match, we require I_ij = I*_ij With this equation, we can then estimate the coordinate of P_j, and the transformation parameters x_i. The advantage of this method is that it allows "multi image" control points, and the main drawbacks are that the coordinates P_j also need to be determined, making the problem harder to solve. Additionally approximate initial values for P_j need to be available (but could be computed using other methods). The idea behind this method is also used in Bundle Adjustment, as used extensively in Photogrammetry for 3D reconstruction and map building. II) using the inverse transformation. Contrary to 3D reconstruction from images, where the transformation is actually a projection from 3D->2D, and thus cannot be uniquely invertable, we have the advantage that our transformation is invertible Thus we can use another approach based on the inverse transformation: Use the control point I_1j and I_2j to calculate P_1j and P_2j. To make the images match, we require P_1j = P_2j The parameters x_j can then be recovered by minimising the distance between P_1j - P_2j, which is the distance of control points in the final panorama. As implemented in panotools, this distance is always measured on the sphere, except for the special horizontal, vertical and line control points. The big advantege is that we do not need to estimate values for P_j, and thus have fewer parameters to estimate, and fewer control points are required. There are also other differences with respect to stability etc. This is why the inverse transformations are required for the optimisation. I hope this was not to confusing. ciao Pablo |
From: Daniel M. G. <dm...@uv...> - 2007-03-17 21:36:00
|
Pablo> I believe the maintainance difficulties are more due to technical reasons Pablo> and not due to the flexibility of the transform stack approach. I totally agree. the conceptual model is great. It is just difficult to understand how it works. Perhaps one of the tasks is to document it well. I think its main problem is that it is rather obscure how the stack is built and used. dmg -- Daniel M. German "Work. Finish. Publish. " Michael Faraday http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |