--- In

PanoToolsNG@yahoogroups.com, "Hannes Hensel" <h.hensel@...>

wrote:

> How is the zoom realized then? Is it only done

> by bringing the viewing plane more to the camera

> (zoom out) or more to the sphere (zoom in)?

Hannes,

Yes, zooming is equivalent to changing the distance between

projection plane and center of projection.

All of these operations can be combined into one step, for some

definition of "step". They are usually kept separated to simplify

thinking/coding and to move the cost of computations to where they

can be afforded.

A little more discussion...

In my previous reply, I followed your lead and wrote in terms of

lat/lon --> cubic image coordinates --> viewscreen coordinates.

But in fact, the transformations are usually run in the opposite

direction. For each viewscreen pixel, one computes the corresponding

cubic image coordinates. From cubic image coordinates, one computes

the corresponding lat/lon. From lat/lon, one computes the

corresponding coordinates within a "perfected" camera image (after

correction for lens distortion). From those, one computes

coordinates within the camera image -- the one that was fed to

Panorama Tools as a source image.

Pixel value interpolation typically occurs at several places in the

pipeline, once for every actual image that is constructed. Suppose,

for example, that you run Panorama Tools to stitch multiple camera

images into a single equirectangular image, then run PanoCUBE to

generate a cubic file, then view with QuickTime or ptviewer. In this

case there will be at least three separate interpolations of pixel

value: one to go from camera images to equirectangular image, a

second to go from equirectangular image to cubic image, and a third

to go from cubic image to screen image.

In theory, all of this manipulation could be combined into a single

step, generating a screen image directly from camera images with only

a single interpolation of pixel values.

However, that would put the entire cost of the calculation into the

viewing loop. At present, that's not feasible because it would be

too slow. Instead, the expensive calculations are done once, to go

from camera images to cubic image file, so that only very simple

calculations are needed for interactive panning/zooming. The viewing

calculations can be done quickly even in software, and are simple

enough to be done in hardware for even better performance.

It is interesting to notice that if you start with camera images from

a perfect rectilinear lens, then in theory the entire viewing

pipeline can be done without any spherical trig at all! All this

lat/lon stuff is just a convenient way to think about the

calculation. Ultimately, what's being accomplished is only to

project each planar camera image onto the planar viewscreen. That

process requires only matrix multiply and perspective division, using

homogeneous coordinates. I'm not aware of any software that actually

takes this approach, however.

--Rik