Re: cubicQTVR projection
> Can I ask, why are you looking for these formulas?Hey Rik, thanks so far. That goes into the right direction. I'm only
trying to get a bit deaper in that graphic stuff, to understand what is
done there. And I wonder, if there is a shortcut, to do those 2 steps
in one (sph > cube and cube > viewer = sph > viewer). Than it should be
a sphere with the vCamera (central point) as center and the viewing
plane inbetween (inner surface of the sphere BEHIND the viewing plane),
right? 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 PanoToolsNG@yahoogroups.com, "Hannes Hensel" <h.hensel@...>
> How is the zoom realized then? Is it only doneHannes,
> by bringing the viewing plane more to the camera
> (zoom out) or more to the sphere (zoom in)?
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.
- --- In PanoToolsNG@yahoogroups.com, "Rik Littlefield"
> It is interesting to notice that if you start with camera images fromYes, that's true, but there is the problem of blendig, then. If the
> a perfect rectilinear lens, then in theory the entire viewing
> pipeline can be done without any spherical trig at all!
images were perfect, that should be no problem. But if they did not fit
100% or have some exposure differences, one would notice that in the
viewer. Maybe it would be a good approach, to correct and blend the
images, but to leave their ratio and size. Still it would need some
more calculations, like z-buffering, but that shouldn't be a problem.
The question here is: is there an advantage in having the (almost)
original images available in the viewer or its context? I can already
hear "Protect my images! Copyright!" - which is an important thing...
- --- In PanoToolsNG@yahoogroups.com, "Rik Littlefield" <rj.littlefield@...> wrote:
> It is interesting to notice that if you start with camera images fromThe fact is there is a guy who stitches panoramas this way.
> 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.
Well not quite but what he does is actually combining 6 images from a fisheye in a 3D
software (CINEMA 4D). They are converted to rectilinear and cropped to 90x90 degree + a
He also use a 15mm fisheye the same way but they have to be combined for each
His Name is Toshio Fuji
You would know him if you were on the Quicktime list.
But be prepared if you contact him. He is a very special guy.
He also designs his own panorig and this is what he did to demonstate that his rig was the
- I use standalone versions of SPi-V and DevalVR to view equirectangular
versions of 360x180 panos.
I don't know whether or not they build "on the fly" cubic faces...
BTW, the displayed rectilinear image is good and moves are very smooth.
This is very helpful for previews before end of stitcher use, but this
is out of topic!
- Hallo, Hannes
on Sat, 30 Dec 2006 09:00:12 -0000 Rik wrote:
> I forget the exact formulas. You can find the general forms in anySearch for "Euler Angles" if you want to know the math behind it...
> good computer graphics text, but working out the details is always
Resources, not only for panorama creation:
- My memory of Euler Angles had grown fuzzy with time (hey, I haven't
really worried about them since my mechanics classes in physics grad
school 20+ years ago), so I googled them to remind myself. I got a
kick out of the blue-boxed warning at the beginning of the article on
Wikpedia. You know, the same one where they say that the article may
need to be cleaned up or doesn't provide proper references. This one
said: "This article or section may be confusing or unclear for some
readers." I had to laugh 8-) I know I can imaging an unsuspecting
reader wondering what the heck THAT is!
On Jan 1, 2007, at 12:06 PM, Erik Krause wrote:
> Search for "Euler Angles" if you want to know the math behind it...
> Erik Krause
> Resources, not only for panorama creation: