Menu
▾
▴
Re: [PanoTools-devel] [hugin-ptx] Re: [hugin-ptx] Re: Google summer of code
|
From: Daniel M. G. <dm...@uv...> - 2007-03-15 19:32:40
|
Hi Ippei Ippei> 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'll try to answer both messages in one. 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). 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. So what Pablo is saying is right, panotools remapping is 3 systems: 1. Registration optimization 2. Remapping of sphere to output projection 3. Projections library and I would add: 4. Parsing of input Ippei> I'm confused. I thought mapping/optimisation is done to put the Ippei> images on the sphere surface (or whatever way in a 3D space), and Ippei> projection/stitcher engine produces the images by sort of taking Ippei> picture from the centre of that world with different projections (or Ippei> an interactive VR snap, or even a movie which could be really cool). Ippei> I don't understand why would the optimisation process ever need to Ippei> know about the projection. 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 I hope this clarifies your doubts. I think rehauling panotools is a summer project. And it will be fun, but it requires a lot of reengenering to get it "right". dmg >> Actually, for the mapping part, I would suggest instead of doing >> all the >> lowlevel stuff ourself and limit everything to tiff files (which is an >> enormous waste of disk space for real HDR panoramas, especially >> when all the >> intermediate files get stored on the hard disk), we should use a >> library >> that has been build with large images and flexible processing in >> mind, such as >> VIPS. VIPS has been designed from the ground up to work with images >> bigger >> than the available memory, has been tested on a 64 CPU machine with >> a good >> speedup, and can be easily scripted with python. Additionally it has a >> very nice, high level C++ interface. We can tap all this by porting >> the >> panotools mapping function to a VIPS operation, which shouldn't be >> terribly >> hard (although this is the "dirty" part of VIPS), given that the >> main author >> will help us :-) >> >> http://wiki.panotools.org/ >> SoC2007_projects#Processing_of_very_large_images 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. Ippei> I'm saying this because panotools can provide a set of general Ippei> framework, and for example PTMac could write its own projection Ippei> engine with Mac OS X's API, and still use the same optimiser etc. At Ippei> least I think that's how opensource libraries should be. Of course Ippei> the panotools/hugin would aim for the best cross-platform opensource Ippei> implementation around because that's our goal, but there are Ippei> different needs in the field and we can seek the way to keep us both Ippei> happily alive. Ippei> Anyway, my point is that one can work on this kind of >>> foundational Ippei> improvements during the summer too if we put as the SoC >>> project. That Ippei> way, we would probably get a better framework to write >>> panorama Ippei> imaging algorithms in after the summer. I'm not one of >>> those who Ippei> understand inside the black-box of the individual panotools Ippei> processes, but I feel the current framework makes the >>> panotools more Ippei> like a black-suck that is even hard for programmers to use >>> it from Ippei> outside, not to mention how it should be extended. >> >> I understand most of the inside, and you are definitely right about >> the >> interface. Seems like we have many candidates for projects :-) 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 Ippei> --~--~---------~--~----~------------~-------~--~----~ Ippei> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. Ippei> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ Ippei> To post to this group, send email to hug...@go... Ippei> To unsubscribe from this group, send email to hug...@go... Ippei> For more options, visit this group at http://groups.google.com/group/hugin-ptx Ippei> -~----------~----~----~----~------~----~------~--~--- Ippei> -- ->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>> MSN & AIM: ipp...@ma... Skype: ippei_ukai Homepage: http://homepage.mac.com/ippei_ukai/ -- Daniel M. German "A machine --computer-- can only do Lady Lovelance -> what we tell it to do" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |