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?

Important: The shift operation is not equivalent with camera translation. I
cannot use ortographic camera, because stereo rendering is theoretically
based on the perspective one.

>>> My scene:

#version 3.5;

#include "colors.inc"
#include "math.inc"

global_settings {
  assumed_gamma 1.0
  max_trace_level 5
}

// ----------------------------------------

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>
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.0,0.2>]
    }
  }
}

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

// ----------------------------------------

union {
  intersection {
    plane {               // checkered floor
      y, 0
      texture
      {
        pigment {
          checker
          color rgb 1
          color blue 1
          scale 0.2
        }
        finish{
          diffuse 0.8
          ambient 0.1
        }
      }
    }
    cylinder {
      <0,-0.03,0>, <0,0.01,0>, 0.2
      pigment {color red 0.5}
    }
  }

  box {
    <-0.05,0.0001,-0.05>, <0.05,0.1,0.05>
    texture {
      pigment {
        color rgbft <0.1,0.9,0.1,0.5,0.2>
      }
      finish{
        diffuse 0.4
        phong 0.3
        ambient 0.2
        specular 0.1
      }
    }
    rotate 25*y
  }

  translate 0.0*z
}

>>> Render with these settings (quickres.ini):

[1024x768, AA 0.3 Stereo]
Width=1024
Height=768
Antialias=On
Initial_Frame=1
Final_Frame=2
Initial_Clock=0
Final_Clock=1
Cyclic_Animation=off

The center point of the checker pattern (the <0,0,0> point) must match on
the first and second frames (the left and right eye views). The camera can
be rotated such a way by modifying look_at to look_at <0.0, 0.0,  0.0>, but
this introduces a perspective distortion of the X axis. The images must be
shifted on the X axis by half eye-distance, but there's no way to do this in
Pov.

Sorry about my poor English.

Thanks for your help, Vic

Post a reply to this message

If I understand what you're saying correctly, this can be done with a matrix
transformation.

- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]

Post a reply to this message

Vic <let### [at] fwhu> wrote:
> I've made a shutter glass interface hardware and created some stereo
> pictures with PovRay.

  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.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I've uploaded some scenes and rendered images of this problem to:

http://www.cx.hu/pov/stereo1/index.html

Thanks for your help - Vic

Post a reply to this message

I don't think you are trying to apply stereo images properly.  In your
images, what you are calling bad (Maintaining the look_at while moving the
camera) is actually proper.  The fact that it strains the eyes is reality.
Hold a plate to the bridge of your nose and try to focus on the front and
back edges at the same time... impossible.  This is effectively what should
happen to the disc in your picture. Since it is relatively flat compared to
the viewing angle, it should be difficult to focus in on the whole disc in a
stereogram just as in reality. Or maybe i misunderstand what you want to
achieve.

-tgq

Post a reply to this message

Hi!

> I don't think you are trying to apply stereo images properly.  In your
> images, what you are calling bad (Maintaining the look_at while moving the
> camera) is actually proper.  The fact that it strains the eyes is reality.
> Hold a plate to the bridge of your nose and try to focus on the front and
> back edges at the same time... impossible.  This is effectively what
should
> happen to the disc in your picture.

The effect you mentioned is reality, but my problem is not that. I
understand, that someone cannot focus to different distances at the same
time.

> Since it is relatively flat compared to
> the viewing angle, it should be difficult to focus in on the whole disc in
a
> stereogram just as in reality. Or maybe i misunderstand what you want to
> achieve.

The answer to my question affects my thesis at Technical University of
Budapest ( http://www.bme.hu ), so I keep on searching for an answer. Thank
you for your patience.

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. Please compare the horizontal blue-white transitions on the
checker texture on the "bad" and "good" versions.

It seems to be impossible to render a part of the image plane other than
<-0.5,-0.5>-<0.5,0.5> (right and up vectors respectively). These limits
seems to be graven into stone when using a perspective camera. Using
rendering settings like start_row, end_row, start_column, end_column is not
enough, because they have only pixel precision and hard to integrate with
camera placement.

Is there a way to set the "viewport limits" to other values than
<-0.5,-0.5>-<0.5,0.5>?

I will try to make some material with more descriptive examples if the
problem is not clear enought.

Again: Thank you for your patience.

- Vic -

Post a reply to this message

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 :-;

Hermann Voßeler

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.

Hermann Voßeler

Post a reply to this message

In article <3CC### [at] webconde> , Hermann Voßeler <h.v### [at] webconde>
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

Thorsten Froehlich wrote:
> Hermann Voßeler 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.
> 

Thanks, I overlooked the "look_at".
I never used look_at when generating stereo pairs.

But if we omit look_at, we can use non-perpendicular right and
direction vectors, is this correct?

If this were correct, the mentioned problem could be solved this way,
without the need of a matrix transform.
Of course it is inconvienient to set up the camera without look_at,
but one could write a macro for this.

Hermann

Post a reply to this message

In message <3ccc75bc@news.povray.org>, Thorsten Froehlich 
<tho### [at] trfde> writes
>In article <3CC### [at] webconde> , Hermann Voßeler <h.v### [at] webconde>
>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.

Ah, now that's interesting. Shame the beta's just expired, I was gonna 
experiment with this.

>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

-- 
Alex

Post a reply to this message

Hi Pov fans!

Bad news: The "matrix" solution is wrong. It works only if the camera
direction vector is very close to the z axis. Sorry guys, other solution is
required. Other matrix values? Manual camera setup including a replacement
of look_at?

I've considered Hermann Voßeler's StereoPov patch and it seems to be a good
solution. Only stereo_base required and scene parsing and transformations
can be reused efficiently. The stereo cache has some problems (sky_sphere
and others), but it could be a good idea.

I'm trying to create my own "Stereo.inc" include file with a special camera
macro to set up a stereo camera. Left and right images are based on the
lowest bit of frame_number, so new clock and frame_number constants had to
be introduced. Animations always have a doubled number of frames, and so on.
This is only an "transitional" solution. Pov should provide support for
stereo_base camera modifier and a double-width output image format, like the
StereoPov patch.

I'll try to implement this feature if I have time to do this.
But now, I've to work on my thesis and 3 other applications.

Best wishes - Vic

Post a reply to this message

Vic wrote:
> Bad news: The "matrix" solution is wrong. It works
> only if the camera direction vector is very close
> to the z axis. Sorry guys, other solution is required.
> Other matrix values?

Yes. A single matrix transformation can be used to specify any possible
transformation. Place the camera at the origin facing in the +z
direction and then use just the matrix to align the camera. The first
three values are used for the x (right) vector, the next three the y
(up) vector, the next three for the z (direction) vector and the last
three for the location.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Apr 14)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Important:

I've tried to replace look_at with my own mechanism to get rid of keystone
distortion. I've faced a vector rotation problem, where the base angle of
the rotation had not been determined. I've recognized, that not only
stereo_base (the distance between the eyes of the viewer in the appropriate
metric)  important, but the direction of the vector between the two eyes!
This is the base (zero degrees) of the camera rotation around the distance
vector (the roll of the camera as I know).

With the "monoscopic" camera model this was not an issue, because this can
be corrected by trial and error camera placement. With stereoscopy this must
be the result of precise calculation, otherwise the left and right images
stress your eyes and brain. This could be the source of most stereography
problems arised using PovRay.

Hermann and Harold? What's your opinion about the issue detailed above?

- Vic -

Post a reply to this message

Vic <let### [at] fwhu> wrote:
> Bad news: The "matrix" solution is wrong. It works only if the camera
> direction vector is very close to the z axis.

  Ever heard of the rotate and translate commands?

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Vic,

Great precision in stereo base calculation is not necessary.
Stereo photographers rarely need to resort to complex
equations, the 1:30 rule is more than enough unless extreme
lens focal lenghths are involved.

By "vector between the two eyes" do you mean convergence?
Again, parallel cameras is your best solution, but if you do
"toe in" or converge the cameras then you do need to be
precise. You will also need to limit the depth of field because
what is sometimes called "on screen deviation" (the displacement
of left and right images on the screen) may cause the eyes to
diverge (rotate out) which is very uncomfortable!

I've never created an difficult to view stereo pair result from
using the 1:30 rule and parallel cameras.

HB

Vic <let### [at] fwhu> wrote in message news:3ccd9bb0@news.povray.org...
> Important:
>
> I've tried to replace look_at with my own mechanism to get rid of keystone
> distortion. I've faced a vector rotation problem, where the base angle of
> the rotation had not been determined. I've recognized, that not only
> stereo_base (the distance between the eyes of the viewer in the
appropriate
> metric)  important, but the direction of the vector between the two eyes!
> This is the base (zero degrees) of the camera rotation around the distance
> vector (the roll of the camera as I know).
>
> With the "monoscopic" camera model this was not an issue, because this can
> be corrected by trial and error camera placement. With stereoscopy this
must
> be the result of precise calculation, otherwise the left and right images
> stress your eyes and brain. This could be the source of most stereography
> problems arised using PovRay.
>
> Hermann and Harold? What's your opinion about the issue detailed above?
>
> - Vic -
>
>

Post a reply to this message

Harold,

> Great precision in stereo base calculation is not necessary.

You must have much more experience in this field accoring to your postings.
The human eyes and brain can compensate large keystone distortions in some
cases. In other cases a small distortion causes the eyes not to converge.
What is the important difference between the situations?

> Stereo photographers rarely need to resort to complex
> equations, the 1:30 rule is more than enough unless extreme
> lens focal lenghths are involved.

But the resulting images are adjusted when mounted. In raytracing, my goal
is to do this adjustment by setting the camera properly.

> By "vector between the two eyes" do you mean convergence?

Unfortunately (due to my poor English), I don't know the English counterpart
of all the ususal expressions in this field. For example: I've learned the
"keystone distortion" expression from this thread. Can I learn convergence
too? ;-))

"vector between the two eyes":

#declare rv=<0.0325,0,0>    // position vector of the right eye
#declare lv=<-0.0325,0,0>    // position vector of the left eye
#declare ev=rv-lv                    //vector between the two eyes

> Again, parallel cameras is your best solution, but if you do
> "toe in" or converge the cameras then you do need to be
> precise.

This can be the difference between the situations mentioned above. :-)

You're right. Parallel cameras are the best solution, but post-rendering
adjustment of images are needed to view with red-green glasses or shutter
glasses, where the images should go to the same surface (not cross-eyed
view).

> You will also need to limit the depth of field because
> what is sometimes called "on screen deviation" (the displacement
> of left and right images on the screen) may cause the eyes to
> diverge (rotate out) which is very uncomfortable!

StereoTestA.pov renders a "star field" pattern to the skyglobe at infinite
distance. It causes the human eyes to converge at infinity, so the eyes goes
parallel. Divergence is really unconfortable. I couldn't cause my eyes to
diverge, because stereo_base measured in display metric did not exceed
6.55cm. Conclusion: Physical dimensions of display is important when
displaying stereo images, because stereo_base can easily go above 6.55cm in
real world (monitor) metrics.

> I've never created an difficult to view stereo pair result from
> using the 1:30 rule and parallel cameras.

Are your final prictures (on paper or something else) much smaller than the
visible area of a 17" computer monitor?

Thanks for your help, Vic

Post a reply to this message

Vic wrote:
> ... I've recognized, that not only
> stereo_base (the distance between the eyes of the viewer in the appropriate
> metric)  important, but the direction of the vector between the two eyes!
> This is the base (zero degrees) of the camera rotation around the distance
> vector (the roll of the camera as I know).
> 
> With the "monoscopic" camera model this was not an issue, because this can
> be corrected by trial and error camera placement. With stereoscopy this must
> be the result of precise calculation, otherwise the left and right images
> stress your eyes and brain. This could be the source of most stereography
> problems arised using PovRay.
> 
> Hermann and Harold? What's your opinion about the issue detailed above?
> 

Vic,

You are 100% right.
All vectors of the camera must be transformed as a whole.
It's a good idea to treat the stereoscopic base as a vector too.
See my other post in the new "Stereoscopy" thread for details.

The whole theme is tricky and often very frustrating for beginners.
In my opinion, the reason is: you have to be extremely precise in some
points (e.g alignement, mounting of slides). And then there are other
important points, where you have to be rather intuitive. I mean 
especially the length of the stereo base or (in photography) the 
horizontal alignement of the slides while mounting. There are certain
limits to obey, there are some empirical rules (like the 1:30 rule), 
but to a large extent it's a question of taste.

What is most interesting to me as an artist is, that image composition 
works somewhat different to common (2D) photography or painture.

Hermann

Post a reply to this message

Vic,

 > Unfortunately (due to my poor English), I don't know the English
 > counterpart of all the ususal expressions in this field. For
 > example: I've learned the "keystone distortion" expression from
 > this thread. Can I learn convergence too? ;-))
 >
:-) I often have the same problem. You probably noticed this,
when reading the texts on my StereoPOV webpage.

If I understand your first posting right, you didn't mean
"convergence", but the stereoscopic base interpreted as a vector.
Convergence measures, how much the eyes are turned inward to look
at a given object. If we shoot a (virtual) ray from the eye through
the corresponding image element on the stereoscopic pair, then
the two rays (one for each eye) usually will be convergent, i.e
they intersect at the location, where the original object is/was.
And at this location, you will percieve the 3D image of the object.

That means, for near objects, there is much convergence of the
"viewing rays", and for distant objects, there is less convergence.

With convergence, there is one "hard limit": For objects at infinite
distance, the viewing rays are parallel ("they intersect at
infinity"). With natural stereoscopic viewing, there will be never
divergence of the viewing rays.

This limit is very hard. Even if there is a little bit tolerance,
people viewing stereoscopic images won't have much fun, if their
eyes are forced to diverge in order to see the image.


Maybee, I should summarize some important rules for
getting easy-to view stereoscopic images.

Hard limits:
(1) Vertical Alignement: Corresponding image elements must be
     presented at exactly the same height.
(2) No Divergence: The spacing for image elements for objects
     at infinite distance must not be larger than the average
     human eye spacing (65 mm). This spacing often is called
     "maximal on screen deviation"

"Should be"-Rules:
(3) You should try to avoid to large "depth contrasts" or
     "depth gaps". The overall depth-of-field should not be to large.
(4) You should try to arrange your objects behind a well defined
     stereoscopic window. Objects placed before the window
     ("off screen") should not touch the image borders.



Vic wrote:
 > You must have much more experience in this field accoring to your
 > postings. The human eyes and brain can compensate large keystone
 > distortions in some cases. In other cases a small distortion causes
 >  the eyes not to converge. What is the important difference between
 >  the situations?
 >

In many cases, there is a large range of tolerance when breaking the
mentioned rules or limits. In my opinion, the key concept for
understanding this tolerance is "image pregnance".
If you are presenting a very visually pregnant, eye-catching Sujet,
then there will be much tolerance. If the things you show are
complicated (I mean visually), difficult to recognize etc, then
allredy going a little bit beyond the mentioned rules will cause
problems for a lot of people.
If you nicely arrange your objects near the stereoscopic window,
give them a well-balanced distribution in space etc. then your
stereo image will "work" on virtually every device (monitor,
anaglyph print, slide projection...) and you can be shure everyone
will be saying "WOW".
If you want to show architecture, large landscapes, mountains in
there real dimensions and proportions, you have to be much more
precise.

It is well known, that we stereo enthusiasts have allmost infinite
tollerance with respect to stereo images. We can fuse (=see in 3D)
allmost everything, even 2 beer bottles posed side by side on a table
:-)


Harold wrote
 >> Stereo photographers rarely need to resort to complex equations,
 >> the 1:30 rule is more than enough unless extreme lens focal
 >> lenghths are involved.
 >

Vic wrote
 > But the resulting images are adjusted when mounted. In raytracing,
 > my goal is to do this adjustment by setting the camera properly.
 >
....
 > I couldn't cause my eyes to diverge, because stereo_base measured
 > in display metric did not exceed 6.55cm. Conclusion: Physical
 > dimensions of display is important when displaying stereo images,
 > because stereo_base can easily go above 6.55cm in real world
 > (monitor) metrics.
 >

This is especially an issue when making stereo films (or videos).
In most cases, it is practically impossible to readjust the film
after the shot, so the camera has to be constructed in a way, that
it gets the window adjustment right from beginning. This is ofted
done by shifting the optics inward, so the optical axes converge.
(This again is often denoted by the term "convergence")
The intersection point of the optical axes defines, where the
stereoscopic window will be. Note the image planes stay parallel.

This was the background, why I built a similar behaviour into
my StereoPOV patch. Stereo images indeed are linked to specific
physical display dimensions. (Of course, there is tolerance
to view them on a display with differing dimensions; see my
discussion about tolerance breaking the rules above)

If a stereo image is *optimally* suited for a slide projection
screen of 1,80 m width, it can not be scaled arbitrary. If you
make it larger, you will get divergence. If you make it smaller,
you will get less depth (i.e. objects at larger distance will
look "flat"). You can compensate by readjusting the images though.

So, for my StereoPOV patch, I defined the camera in a way, that
the stereoscopic window ist identical with the "natural window"
defined by the image plane, i.e. defined by the "up" and "right"
vector. So, if you define the "up" and "right" vector to the
size of your final presentation device, you will get the correct
maximal on screen deviation, i.e. the correct spacing of 65mm
for objects at infinite distance.

It showed up, that some users were rather confused by this
behaviour of my patch. In normal 2D imaging, the image size is
not this important. "up" and "right" there only define the
aspect ratio. Especialy scenes of the type of the "skyvase"
mentioned by Harold Baize caused problems.
So I need to introduce some means to readjust the distance
of the stereoscopic window. I am considering to add a second
keyword besides "stereo_base" in the next Version of StereoPOV
(that will be POV 3.5-based, if possible). What is to be done
internally is evenly scaling the whole camera while pertaining
the position and look_at.


Hermann

Post a reply to this message