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
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
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".
>> 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
>> 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
>> 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
>> panotools mapping function to a VIPS operation, which shouldn't be
>> hard (although this is the "dirty" part of VIPS), given that the
>> main author
>> will help us :-)
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
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
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
>> 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> 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 hugin-ptx@...
Ippei> To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
Ippei> For more options, visit this group at http://groups.google.com/group/hugin-ptx
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei_ukai@... Skype: ippei_ukai
Daniel M. German "A machine --computer-- can only do
Lady Lovelance -> what we tell it to do"
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .