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/ |