Re: [PanoTools-devel] [hugin-ptx] Re: [hugin-ptx] Google summer of code

[Daniel M. G. <dm...@uv...>]

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 .