Hi all

What does this camera "right" statement imply?

Does it have to do with aspect ratio? I am guessing that "image_width" and
"image_height" are PovRay built-in variables, taken from the command line
or an .INI file, and that this has to do aspect ratio?

Why does Moray use

right     <    1.35836,         0.0,         0.0>

and not the line above?

Thanks!
-- 
Stefan Viljoen
Software Support Technician
Polar Design Solutions

Post a reply to this message

In article <40b70c5a@news.povray.org> , Stefan Viljoen <rylan@<deletehis> 
wrote:

> What does this camera "right" statement imply?
>
> Does it have to do with aspect ratio? I am guessing that "image_width" and
> "image_height" are PovRay built-in variables, taken from the command line
> or an .INI file, and that this has to do aspect ratio?
>
> Why does Moray use
>
> right     <    1.35836,         0.0,         0.0>
>
> and not the line above?

Don't be confused by the x*image_width/image_height.  It simply is a short
form of writing a vector with the x-component having the value
image_width/image_height.  That plague with x*image_width/image_height
started with 3.5 as some users put it in every scene, which is not the
intended use.  It only makes sense if you plan to render a scene at a fixed
aspect ratio regardless of the image aspect ratio (that is, if different
resolutions of an image when rendered are not expected to be proportional).

Most of the time the camera "right" is specifying the width of the the view
only.  However, it is a vector also able to specify a part of the camera
direction together with the other camera vectors.  Please refer to the
reference part of the manual, which has a lengthy camera section describing
the camera parameters in detail.

What Moray outputs is simply an aspect ratio in a vector.

    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" <tho### [at] trfde> a écrit dans le message de
news:40b719ac$1@news.povray.org...
> Don't be confused by the x*image_width/image_height.  It simply is a short
> form of writing a vector with the x-component having the value
> image_width/image_height.  That plague with x*image_width/image_height
> started with 3.5 as some users put it in every scene, which is not the
> intended use.  It only makes sense if you plan to render a scene at a
fixed
> aspect ratio regardless of the image aspect ratio (that is, if different
> resolutions of an image when rendered are not expected to be
proportional).

Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
issue is such a common headache for newcomers that it made its way into FAQ
9.1.2.4, which is the primary source of the image_width/image_height trick.
Hey, for a couple of years in the pre-internet days (no peer support then) I
rotated all my vertical scenes to render then at 800*600, so I'm talking
about "real" headaches... As far as I'm concerned, automatic aspect ratio
should have been the default setting (instead of 4/3) because it's extremely
practical and something less to worry about. The FAQ says that the current
behaviour is necessary because of the possibility of non-square pixels, but
only gives the old Windows startup screen as an example. Are there other
common circumstances (video output?) where having square pixels by default
would be problem?

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Gilles Tran wrote:
> 
> As far as I'm concerned, automatic aspect ratio
> should have been the default setting (instead of 4/3) because it's extremely
> practical and something less to worry about.

I agree the 'trick' is not as bad as Thorsten tries to make it in 
practical scene design (i often play with the aspect ratio of the render 
when creating a scene and don't want to be required to modify both 
render parameters and camera settings every time i change it).  But 
automatic aspect ratio is not as easy as it might seem because there are 
at least two ways to implement it (automatic right vector length or 
automatic up vector length).

And note changing the default is a problem in terms of backwards 
compatibility (otherwise the current '1.33' would already have been 
changed).

> Are there other
> common circumstances (video output?) where having square pixels by default
> would be problem?

The most common probably is printing on a printer with anisotropic 
resolution.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
> issue is such a common headache for newcomers that it made its way into FAQ
> 9.1.2.4, which is the primary source of the image_width/image_height trick.

  The problem I see with this "trick" is that it's unpredictable.

  Even though a perfect model of the scene models everything which could
be viewed from the camera location (looking at any direction), it's quite
common that to save work people just model the visible part of the
scene (visible with the current camera location and look_at).
  What happens if he (or worse, someone else) decides to render the image
with a different aspect ratio? The image doesn't get squeezed, but at the
cost of either extra scene (which may not be modelled at all) coming into
view or part of the original scene going out of view (which may leave
important details out of the image).
  Both of these phenomena may be as bad as a squeezed image because they
can potentially destroy the look of the image by introducing modelling
artifacts (lack of proper modelling of the scene) or by leaving out important
details of the image.

  Another problem is that the automatic control of aspect ratio can only
be done by adding/removing extra image vertically. (Making image_width
and image_height change the 'up' vector does not help: The elongation of
the image is still done vertically.)
  One could think "my scene is ok regardless of how much the viewing plane
is elongated horizontally... but why is 'right x*image_width/image_height'
doing it the wrong way? What should I do?".
  The only way to control the aspect ratio horizontally would be to make
the 'angle' change as well. Are you willing to guess the correct formula?
  Scenes are quite often designed so that they look good even if a
"widescreen shot" is done of them. It's not unusual that modelling
extra scene vertically is skipped.

  Even though this trick may sound pretty handy at first, personally I'm
not completely happy with it.
  IMHO this trick should not be freely preached without a good warning
about its (often surprising) side-effects.

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

In article <40b72edf$1@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:
> Uh? I'm not sure I understand why this is a "plague"... The stretch/squeeze
> issue is such a common headache for newcomers that it made its way into FAQ
> 9.1.2.4, which is the primary source of the image_width/image_height trick.
> Hey, for a couple of years in the pre-internet days (no peer support then) I
> rotated all my vertical scenes to render then at 800*600, so I'm talking
> about "real" headaches... As far as I'm concerned, automatic aspect ratio
> should have been the default setting (instead of 4/3) because it's extremely
> practical and something less to worry about. The FAQ says that the current
> behavior is necessary because of the possibility of non-square pixels

The drawbacks have been discussed in this thread:
<http://news.povray.org/*/thread/%3Cslrnc079it.ntq.cera%40queen.mcs.drexel.e
du%3E/>

The summary is that for new users image_width/image_height does more harm
than good as it is not really easy to predict how it behaves.  In particular
Warp gave a good summary of all the problems related to this.

> Are there other
> common circumstances (video output?) where having square pixels by default
> would be problem?

Apart from DV and fullscreen DVD video and most video output systems
available, which are non-square, DVD widescreen is heavily stretched - the
compressed video is always 720 pixels in width and 480 (NTSC) or 576 (PAL)
in height. And there are also non-square pixels with 1280*1024 on a CRT
monitor.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> But 
> automatic aspect ratio is not as easy as it might seem because there are 
> at least two ways to implement it (automatic right vector length or 
> automatic up vector length).

  Have you actually tried them? They do exactly the same thing: The viewing
area is always modified vertically, never horizontally. (If you wanted
automatic horizontal viewing area change, you would have to deal with
both 'right' and 'angle', with a less trivial formula.)
  I see this even more problematic.

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

In article <40b72edf$1@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:

> 9.1.2.4, which is the primary source of the image_width/image_height trick.

Note that it does by no means suggest the use of the keywords, but rather
expressed the formula for computing the correct square-pixel aspect ratio.
Maybe it should be more elaborate and explain why image_width/image_height
are not the optimal or recommended solution.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Warp wrote:
> 
>>But 
>>automatic aspect ratio is not as easy as it might seem because there are 
>>at least two ways to implement it (automatic right vector length or 
>>automatic up vector length).
> 
> 
>   Have you actually tried them? They do exactly the same thing: The viewing
> area is always modified vertically, never horizontally. (If you wanted
> automatic horizontal viewing area change, you would have to deal with
> both 'right' and 'angle', with a less trivial formula.)

It works perfectly with an orthographic camera.  With perspective it is 
indeed quite complicated but this does not mean it would not be possible 
implement an automatic aspect ratio in both ways i described.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 01 May. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> a écrit dans le message de
news:c97cgl$64o$1@chho.imagico.de...

> And note changing the default is a problem in terms of backwards
> compatibility (otherwise the current '1.33' would already have been
> changed).

Yes, it's certainly stuck that way in the current POV-Ray line, no big deal
anyway. Changing 1.33 into image_height/image_width is certainly the first
thing I do when reusing old scenes though...

> The most common probably is printing on a printer with anisotropic
> resolution.
But is that a common problem? I can imagine that some printers are able to
do anisotropic printing, but I guess that these machines would be able to
print standard, square-based images too. What would be the point of not
being able to do so, or am I missing something obvious there?
Googling about pixel ratio returns links to (professional?) video
production, with people complaining that entry-level software like Bryce or
Poser cannot do non-square pixels for video, unlike professional apps like
AfterEffects.

G.


-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> a écrit dans le message de
news:40b73660@news.povray.org...

>   Both of these phenomena may be as bad as a squeezed image because they
> can potentially destroy the look of the image by introducing modelling
> artifacts (lack of proper modelling of the scene) or by leaving out
important
> details of the image.
>
>   Another problem is that the automatic control of aspect ratio can only
> be done by adding/removing extra image vertically. (Making image_width
> and image_height change the 'up' vector does not help: The elongation of
> the image is still done vertically.)

I still don't get it (and I've read the thread posted by Thorsten too).
Unless it's one single colour, a squeezed/stretched image is *** always ***
bad. There's zero point in rendering it, period. So, at its
worst, the automatic trick is the lesser of two evils. And in fact, from a
practical point of view, it's far from being such a problem. During scene
development, I usually cycle through my 4 favourite ratios (1.33, 0.75, 1
and 2.66) and the automatic trick makes it a breeze until I decide on what
ratio I'll finally use for the scene. Then, scene adjustments have to be
made to accommodate the ratio (zooming, moving/adding objects etc.), but
that's basically an artistic choice, as composition is deeply linked to the
aspect ratio.
Simply put, before the trick existed, I had the various ratios x*1.33, x*1
etc. in commented form, so all the drawbacks were already there, but it was
just a real pain as I kept forgetting to uncomment the right one... I'm not
saying that problems with automatic ratio don't exist, but I still have to
see people
complaining about them and I never considered them to be drawbacks at all,
let alone harmful.
However, we still have people puzzling about stretched/squeezed images due
to
the default 1.33.
Professional video output is more a real issue (though a niche one
IMHO) but for this the user could still have the choice of using a
non-square pixel ratio, as it's the case now.

G.

-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

In article <40b750cb$1@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:

> However, we still have people puzzling about stretched/squeezed images due
> to the default 1.33.

Well, for a 1024*768 image the difference to a 4:3 aspect ratio is just two
pixels.  I doubt many will ever notice.

> Professional video output is more a real issue (though a niche one
> IMHO) but for this the user could still have the choice of using a
> non-square pixel ratio, as it's the case now.

Not only professional video output: DV is the standard format used for
digital video cameras.  Practically all video editing software supports
exports to DV cameras attached via IEEE 1394 (aka FireWire aka iLink).  And
if you do your own animations on DVDs or just static DVD menu background
images, you also have to deal with non-square pixels.

Oh, and as for inexpensive programs having problems with non-square output,
well, rendering at twice the resolution and then scaling down will be
sufficient regarding quality as far as DCT-based algorithms are concerned
(btw, DCT yields better compression of blurred or anti-aliased images and
video).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> a écrit dans le message de
news:40b75628@news.povray.org...

> Well, for a 1024*768 image the difference to a 4:3 aspect ratio is just
two
> pixels.  I doubt many will ever notice.

Hmm, we have a failure to communicate here ;) This is about the unending
flow of users who try to get a vertical, square or widescreen image and get
a squeezed/stretched one because of the default 1.33 and then complain about
it in newsgroups or to TAG members because they expect the width and height
values to work right away (without requiring another parameter change), as
they do in other renderers and 3D apps (at least all those I'm using). The
automatic ratio trick is popular for a reason.

G.



-- 

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

In article <40b76476@news.povray.org> , "Gilles Tran" <tra### [at] inapginrafr>
wrote:

> Hmm, we have a failure to communicate here ;) This is about the unending
> flow of users who try to get a vertical, square or widescreen image and get
> a squeezed/stretched one because of the default 1.33 and then complain about
> it in newsgroups or to TAG members because they expect the width and height
> values to work right away (without requiring another parameter change), as
> they do in other renderers and 3D apps (at least all those I'm using). The
> automatic ratio trick is popular for a reason.

Making it automatic will not help.  Just because those who report never read
the documentation do not understand a feature does not imply at all it
should work differently.  There are a million things they won't understand
without reading it.  And it is very likely that changing it to behave the
other way there will be as many people asking the opposite question.
Consequently, we cannot make a program fool-proof, every time we try we just
create better fools or get other fools reporting the opposite behavior as
unexpected.

I bet many CD player manufacturers also got many reports in the early days
that CD did not work because people inserted them upside-down.  Today people
would probably face the opposite problem when dealing with an ancient
playback device.  Either way, one can only figure out the correct usage of
any complex device by reading the manual.  Bad luck if one doesn't...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Are there other
> common circumstances (video output?) where having square pixels by default
> would be problem?


I recently rendered a 720x480 series of images to be edited with video that
had an aspect ratio of 4:3. In addition, occasionally I renderer images
intended to be used as textures for my OpenGL programs; textures must have a
2^n x 2^m resolution, so non-square pixel aspect ratios are necessary if I
plan on drawing the texture at a different size in my program.

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

Post a reply to this message

Christoph Hormann nous apporta ses lumieres ainsi en ce 2004/05/28 
08:49... :

>
> The most common probably is printing on a printer with anisotropic 
> resolution.
>
> Christoph
>
Well, any decent printer drivers are made to compensate for any 
anisotropy the printer may have. There may be some oddball drivers that 
don't do it automaticaly. The real isue with anisotropic printer is when 
doing a raw transfert bypassing the drivers.

Alain

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> Unless it's one single colour, a squeezed/stretched image is *** always ***
> bad.

  What do you mean always?
  If I'm making a 320x400 windows startup image, I *want* the image to
still have 4:3 aspect ratio even though the resolution is not. The image
will look stretched when viewed normally, but it's exactly what I want.
  You can't say "always".

> There's zero point in rendering it, period. So, at its
> worst, the automatic trick is the lesser of two evils.

  I wouldn't be so sure that automatic aspect ratio setting is the lesser
of two evils.
  When you render with the wrong aspect ratio, you can at least clearly
*see* that there's something wrong with the image. This is specially
the case when you try to render a scene with a wider aspect ratio
in a default 4:3 resolution (some of the POV-Ray example scenes are
good examples of this): You will *see* that there's something wrong
with it.
  However, if the scenes had automatic aspect ratio correction, there's
a big chance you won't notice that you did something wrong when you
make a 4:3 render of it. You might wonder why there are some oddities
at the top and the bottom of the image (if the author didn't bother
to properly model those parts) but you would simply assume it's a
mistake of the author, not your mistake. However, you will be rendering
the image in a way the original author didn't intend.

  I personally find this specially bothering because the automatic
aspect ratio setting modifies the viewing area *vertically*, which
is the less usual image area change (usually images are made to
be viewed in widescreen, if anything). You may eg. model a landscape
which looks ok no matter where you look at it by rotating the camera
horizontally, but you don't care how the landscape looks below the
camera because it's outside the image... except if someone happens
to render the image with a different aspect ratio than you.

  So my strong opinion is that *no* automatic aspect ratio setting in
POV-Ray by default, and people should really give the "trick" with
a warning of its side-effects. (Something like "be aware that if
you render using a resolution with a different aspect ratio, the
viewing area will be modified in the vertical direction, thus giving
or removing image area from the top and bottom of the image".)

  I would like the trick more if it modified the viewing area horizontally,
but it doesn't.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message