In article <3cca6837@news.povray.org> , "Vic" <let### [at] fwhu> wrote:

> My problem is the tilt of the horizontal lines appears on my "bad" pictures,
> not the depth of my objects. The effect is very similar (but not identical)
> to a slight rotation around the Z axis. This renders the left and right
> images wrong.

But they are not wrong!  As soon as your eyes focus on something this is
precisely the effect you have.  What you are trying to generate is an image
infinitely far away, so your eyes have to look nearly parallel.

> viewport limits

As you keep talking about viewport limits I suppose your problems
understanding the correct behavior come from the use of z-buffer based
algorithms.  It is indeed true that for those when rendering stereo views the
viewport is commonly moved, but this is only an approximation necessary to
avoid having to transform the whole scene in order to keep the rendering fast.
The image you call "bad" is actually the correct image for a stereo view of a
human eye and the "good" one a simple approximation similar to those commonly
produced by a z-buffer based stereo renderer.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

If you change the camera location but don't
change the look_at it will rotate the camera
and introduce "keystone" distortion. In the
real world our eyes do rotate (converge) when
we look at something close, and our perceptual
system (brain) compensates for the distortion.
Unfortunately, when we view stereo images our
viewing methods can't recreate this convergence
and as a result we see distortion. To avoid this
stereo pairs should be created with parallel
cameras.

The rare exception to keeping the cameras
parallel this is in electron microscopy where
the object itself is rotated. The resulting image
doen't have noticeable keystone distortion
because of the shallow depth of field.

Harolddd



Warp said:

>   Unrelated to the question in itself, but AFAIK the most accurate way
> of getting a stereo image pair is precisely changing the location of the
> camera while keeping the look_at where the camera is "looking at".
>   This simulates what happens with your eyes and thus is the most correct
> simulation of a stereo image.

Post a reply to this message

Thorsten said:
> But they are not wrong!  As soon as your eyes focus on something this is
> precisely the effect you have.  What you are trying to generate is an
image
> infinitely far away, so your eyes have to look nearly parallel.

That is true, our EYES see the images this way, but our brain does not.
I don't think he is trying to generate an image at infinity, but expects it
to look as if it were at infinity, because he (we) can't recreate the
viewing experience of looking at a scene close to our face. Also, it
is convergence that is the issue, not focus. The eyes cross (converge)
on close objects.

Our eyes begin to converge from parallel at about 2m (six feet), we
don't notice it until things are close, like 0.3m. Our perception
adjusts for geometric distortion and other issues when we focus
close and converge our eyes, for example we ignore the distant
background which is out of focus and can't be stereoscopically
fused (it is a "double image"). Minor keystone distortion is likewise
ignored. When we view a pair of images rendered from this geometry later
on the computer screen it is disturbing because we don't have the
ability to ignore or compensate for the distortions because we are
viewing it in a different context and with parallel eyes focused at a
different depth. That is why one should always generate stereo
pairs with parallel cameras. The issue becomes how to set the
"stereo window" which is the virtual frame created by the edge of
the image. I set the stereo window by trimming the left and right
edges of the stereo pairs.

> As you keep talking about viewport limits I suppose your problems
> understanding the correct behavior come from the use of z-buffer based
> algorithms.  It is indeed true that for those when rendering stereo views
the
> viewport is commonly moved, but this is only an approximation necessary to
> avoid having to transform the whole scene in order to keep the rendering
fast.
> The image you call "bad" is actually the correct image for a stereo view
of a
> human eye and the "good" one a simple approximation similar to those
commonly
> produced by a z-buffer based stereo renderer.

I know nothing of z-buffer based algorithms, but I would argue that the
image
Vic labeled as "good" was rendered correctly for stereo viewing, and the
"bad" image was rendered accurately for what the eye sees, but not for what
the brain perceives or for stereo viewing.

Harolddd

Post a reply to this message

In message <3cc9ce28@news.povray.org>, Vic <let### [at] fwhu> writes
>Hi Pov fans!
>
>I've made a shutter glass interface hardware and created some stereo
>pictures with PovRay. I'm faced with a serious shortage of Pov, namely the
>unability to "shift" the camera viewport. The right and up vectors are
>always at 0.5, so I've to shift the resulting images after rendering to
>match the left and right eye views at the screen plane. (see "The
>perspective camera" in Pov help at "Placing the Camera" topic)
>
>Is there any way to shift the image plane during the rendering process?
>
I was going to suggest changing the direction vector, but unfortunately 
this does not work at all logically.
The docs say "Note: that the up, right, and direction vectors should 
always remain perpendicular to each other or the image will be 
distorted.", but knocking up a short test scene I find the povray (3.5) 
*forces* the vectors to be perpendicular. Whilst non-perpendicular 
vectors do distort the scene, it does not do it in the way I would 
expect (and which allow the camera viewport to be shifted).

Slime suggests using the matrix transformation, which will allow you to 
shift the image plane.

matrix <1,0,sf,
         0,1,0,
         0,0,1,
         0,0,0>

where sf is the shear required (use +/- for R/L images respectively

    x
   ____      sf=x/z
   \   |
    \  |  z
     \ |
      \|

But this doesn't quite work as expected, causing a slight stretch in the 
image along the x-axis. The fix is to use

matrix <sqrt(1+sf^2),0,sf,
                    0,1,0,
                    0,0,1,
                    0,0,0>
>
>camera {
>  #local pp=clock*2-1;
>  #local dd=0.06;
>  #local xx=-dd*0.5*pp;
>  #local yy=0.4;
>  #local zz=0.6;
>  location  <xx, yy, -zz>
>  right     x*image_width/image_height
>  look_at   <xx, 0.0,  0.0>
>}
>

This ought to work:

camera {
   #local pp=cl0ck*2-1;
   #local dd=0.06;
   #local xx=-dd*0.5*pp;
   #local yy=0.4;
   #local zz=0.6;
   #local sf=xx/zz;
   location  <xx, yy, -zz>
   right     x*image_width/image_height
   look_at   <0, 0.0,  0.0>

   matrix <sqrt(1+sf^2),0,-sf,
                    0,1,0,
                    0,0,1,
                    0,0,0>
}

The other thing that doesn't work as expected is the look_at. I would 
have expected to look_at <xx,0,0> (parallel to the z-axis) and the 
matrix to deform the camera to look at the origin.


Can I have a new camera please, this one's broken (shakes it and hears 
glass rattling about inside).
-- 
Alex

Post a reply to this message

Hi Alex!

> I was going to suggest changing the direction vector, but unfortunately
> this does not work at all logically.

Unfortunately, not.

> Slime suggests using the matrix transformation, which will allow you to
> shift the image plane.

> matrix <1,0,sf,
>          0,1,0,
>          0,0,1,
>          0,0,0>

Yes, it's in the documentation on the "matrix keyword" page and mentioned as
shearing.

> But this doesn't quite work as expected, causing a slight stretch in the
> image along the x-axis. The fix is to use
>
> matrix <sqrt(1+sf^2),0,sf,
>                     0,1,0,
>                     0,0,1,
>                     0,0,0>

I had to turn off vista buffer, because Pov refused to render the image
(camera vectors are not perpendicular).

Stereo images now look good and not shifted away!
Thanks, this works corretly as I expected.

> The other thing that doesn't work as expected is the look_at. I would
> have expected to look_at <xx,0,0> (parallel to the z-axis) and the
> matrix to deform the camera to look at the origin.
> Can I have a new camera please, this one's broken (shakes it and hears
> glass rattling about inside).

There would be a camera modifier in PovRay supporting stereo images, like:

camera {
    ...
    eye_distance 0.06
    ...
}

This should generate two images for each frame: a left eye view and a right
eye view, such as:

Stereo.pov =>
Stereo01L.bmp
Stereo01R.bmp
Stereo02L.bmp
Stereo02R.bmp
...

This could simplify stereo animation, because on the one hand it's not
needed to calculate a new clock variable according to frame_number, on the
other hand left and right images can be separated and processed easily.

A command line/configuration paramter can also be useful to support stereo
view of existing scenes.

Thanks to the Pov newsgroup, my problem has been solved.

Special thanks to: Alex, Slime and Harolddd

- Vic -

Post a reply to this message

Thanks Harold!

You've described my problem successfully!
Alex and slime were able to solve my problem.
After reading your description?
;-)))

- Vic -

---------------------------------------------------------------

"Harold Baize" <bai### [at] itsaucsfedu> wrote in message
news:3ccb18a8@news.povray.org...
>
> Thorsten said:
> > But they are not wrong!  As soon as your eyes focus on something this is
> > precisely the effect you have.  What you are trying to generate is an
> image
> > infinitely far away, so your eyes have to look nearly parallel.
>
> That is true, our EYES see the images this way, but our brain does not.
> I don't think he is trying to generate an image at infinity, but expects
it
> to look as if it were at infinity, because he (we) can't recreate the
> viewing experience of looking at a scene close to our face. Also, it
> is convergence that is the issue, not focus. The eyes cross (converge)
> on close objects.
>
> Our eyes begin to converge from parallel at about 2m (six feet), we
> don't notice it until things are close, like 0.3m. Our perception
> adjusts for geometric distortion and other issues when we focus
> close and converge our eyes, for example we ignore the distant
> background which is out of focus and can't be stereoscopically
> fused (it is a "double image"). Minor keystone distortion is likewise
> ignored. When we view a pair of images rendered from this geometry later
> on the computer screen it is disturbing because we don't have the
> ability to ignore or compensate for the distortions because we are
> viewing it in a different context and with parallel eyes focused at a
> different depth. That is why one should always generate stereo
> pairs with parallel cameras. The issue becomes how to set the
> "stereo window" which is the virtual frame created by the edge of
> the image. I set the stereo window by trimming the left and right
> edges of the stereo pairs.
>
> > As you keep talking about viewport limits I suppose your problems
> > understanding the correct behavior come from the use of z-buffer based
> > algorithms.  It is indeed true that for those when rendering stereo
views
> the
> > viewport is commonly moved, but this is only an approximation necessary
to
> > avoid having to transform the whole scene in order to keep the rendering
> fast.
> > The image you call "bad" is actually the correct image for a stereo view
> of a
> > human eye and the "good" one a simple approximation similar to those
> commonly
> > produced by a z-buffer based stereo renderer.
>
> I know nothing of z-buffer based algorithms, but I would argue that the
> image
> Vic labeled as "good" was rendered correctly for stereo viewing, and the
> "bad" image was rendered accurately for what the eye sees, but not for
what
> the brain perceives or for stereo viewing.
>
> Harolddd
>
>

Post a reply to this message

In message <3ccbc0a8@news.povray.org>, Vic <let### [at] fwhu> writes
>Hi Alex!
>
<snip>
>
>There would be a camera modifier in PovRay supporting stereo images, like:
>
>camera {
>    ...
>    eye_distance 0.06
>    ...
>}
>
I was rather expecting something along the lines of the following to 
work:

#declare offset=1   // +1 for left eye, -1 for right, (0 for cyclops!)
camera {
   right <4,0,0>
   up <0,3,0>
   direction <offset,0,4>
   location <-5*offset,0,-20>
   look_at <0,0,0>
   }

but all that happens is the 'right' vector gets rotated to be 
perpendicular to the direction vector, causing the keystone distortion 
mentioned elsewhere in this thread.

>This should generate two images for each frame: a left eye view and a right
>eye view, such as:
>
>Stereo.pov =>
>Stereo01L.bmp
>Stereo01R.bmp
>Stereo02L.bmp
>Stereo02R.bmp
>...
>
>This could simplify stereo animation, because on the one hand it's not
>needed to calculate a new clock variable according to frame_number, on the
>other hand left and right images can be separated and processed easily.
>
>A command line/configuration paramter can also be useful to support stereo
>view of existing scenes.
>
I'd just create a .pov file to render the left eye as stereoL.pov, then 
just modify it for the right eye and save as stereoR.pov. But I'm just 
lazy....

-- 
Alex

Post a reply to this message

Alex wrote:
> I was rather expecting something along the lines of the following to work:
> 
> #declare offset=1   // +1 for left eye, -1 for right, (0 for cyclops!)
> camera {
>   right <4,0,0>
>   up <0,3,0>
>   direction <offset,0,4>
>   location <-5*offset,0,-20>
>   look_at <0,0,0>
>   }
> 
> but all that happens is the 'right' vector gets rotated to be 
> perpendicular to the direction vector, causing the keystone distortion 
> mentioned elsewhere in this thread.
> 

Oh my God!
This *DID* work allways. I created dozens of stereo pairs with
POV-Ray versions prior to 3.5 by using this approach.

If the 3.5 perspective camera rotates the vectors, I would
consider this clearly a bug. What, if someone wants to make
a shift (like shift optics at real world cameras) ??

<rant>
I think, it is wrong to break a working feature that is
commonly needed by advanced users in order to make things
more easy for the newbies.
</rant>


Ok ok--
I shouldn't complain.

If  POV 3.5 's camera would be broken in this way,
all Stereo enthusiasts were forced to use my StereoPOV patch :-;

Post a reply to this message

Harold Baize wrote:
> Thorsten said:
>>But they are not wrong!  As soon as your eyes focus on something this is
>>precisely the effect you have.  What you are trying to generate is an
>>image infinitely far away, so your eyes have to look nearly parallel.
> 
> That is true, our EYES see the images this way, but our brain does not.
> I don't think he is trying to generate an image at infinity, but expects it
> to look as if it were at infinity, because he (we) can't recreate the
> viewing experience of looking at a scene close to our face. Also, it
> is convergence that is the issue, not focus. The eyes cross (converge)
> on close objects.

Some time ago I saw a specialized stereo viewer that simulated
this cross converging for objects rather very near to the eyes.
It was used to show macro stereo images of some machinery or
technical constructions.
But such a thing only works with a stereo viewer with lenses.

For presenting stereo images on a computer monitor or on a
slide projection screen, we have to consider, that both half images
are presented on the same (screen) plane. Because of this, the
image planes used to create the halfimages need to be aligned as
well, otherwise you will get the keystone distortions Harold Baize
mentioned when bringing the two halfimages on a single plane for
presentation.

Btw., our eyes have a curved image plane (retina) and can be turned.
And the brain compensates as well.

When making stereoscopic images, we don't simulate the human eye/brain
system itself. But we rather create a view, that can be percepted by
the human eye/brain system in a way similar to the natural two-eyed
3D viewing.

Post a reply to this message

wrote:

> This *DID* work always.

No, the example you are quoting never worked.  When look_at was applied
POV-Ray always made the up and right vectors perpendicular.  If you didn't
want perpendicular up and right vectors, you could not use look_at.  The same
is still true in POV-Ray 3.5.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message