I was thinking about the separation between SDL and command line parameters for
a few things:


* Image & Pixel Aspect Ratio:

There are two common practices to write scenes regarding this:
(a) write a scene for a fixed image aspect ratio (e.g. 4:3);
(b) write a scene for a 1:1 pixel aspect ratio.

I personally favor (b), as it always gives me an undistorted image even if I
happen to choose the wrong image aspect ratio - or even happen to choose a
different one later in the process.

The FAQ argues strongly against (b), obviously favoring (a), claiming that this
makes the user aware that he chose the wrong aspect ratio because he can see
that the image is distorted, while in the other case he may get a different
"viewport" than intended by the scene author, without even noticing.

I insist that this argument does not hold, because the difference between the
intended aspect ratio and the one picked for rendering may be ever so subtle,
and the scene may not contain enough objects that hint at the originally
intended aspect ratio clear enough. This is especially a problem with 4:3 vs.
5:4 aspect ratios.

I agree, however, that (b) is not an ideal solution either, as a 1:1 pixel
aspect ratio may not always be desired.

Now the POV sample scenes always come with a comment that indicates the aspect
ratio intended by the scene author.

My proposal is to add a new statement to the POV camera{} section specifying the
originally intended aspect ratio.

(The rationale of specifying this in the camera instead of the globals{} section
is that someone may want to add alternative cameras to their scene that may be
designed for different aspect ratios.)

The statement might have the form (e.g for a 4:3 image aspect ratio):

    camera {
        ...
        aspect_ratio 4/3
    }

The value specified could be used as follows:

- automatically produce a warning if the scene is rendered with a resolution
that doesn't fit this ratio (a complementary command line switch could be used
to explicitly specify a pixel aspect ratio in case this is not the usual 1:1)

- allow for either the image height or width to be specified as "auto" on the
command line, causing the corresponding value to be computed automatically from
the other parameter (note that this could *drastically* reduce the number of
quickres entries for people frequently messing with various aspect ratios)

- automatically compute all relevant camera parameters by just specifying camera
location, look_at, opening angle and aspect_ratio


* Frame Count:

Instead of using the 0.00-to-1.00 clock, animations may instead use the
frame_number for timing reference. In that case, it may be desirable to specify
the number of frames not on the command line, but in the SDL file, either to be
warned if different values are specified on the command line, or to always
override those values.


* Render batch:

Occasionally, a full render may consist of several images to be rendered in
sequence, e.g.:

- a scene file requiring to generate its own bitmaps for the main render

- a scene to be post-processed using another SDL script

- a scene to be rendered in multiple passes to take advantage of some other POV
effects (e.g. to do a radiosity pre-pass with area lights turned off or the
like)

In some cases this can be achieved with a single invocation of POV by exploiting
the animation facilities. Sometimes, however, this is impossible because it is
desired to have different image sizes for the various passes.

Of course, virtually every OS provides *some* way of batch processing. However,
it would be desirable if this could be done in a way that works with all
platforms on which POV runs.

Something that comes to my mind would be to have an .ini option to specify a
list of .ini file sections that are to be rendered, e.g.:

  ; valid for all passes
  Output_File_Type=N
  Render_Sections=FooTexturePass,RadiosityPass,MainPass

  [FooTexturePass]
  +W1024 +H1024
  Input_File="Generate_Foo_Texture.pov"
  Output_File_Name="Foo.png"

  [RadiosityPass]
  +W320 +H240
  InputFile="MyScene.pov"
  Output_File_Name="MyScene_RadiosityPass.png"
  Declare="RadiosityPrePass=1"

  [MainPass]
  +W1024 +H768
  InputFile="MyScene.pov"
  Output_File_Name="MyScene.png"
  Declare="RadiosityPrePass=0"

Post a reply to this message

clipka <nomail@nomail> wrote:
> I agree, however, that (b) is not an ideal solution either, as a 1:1 pixel
> aspect ratio may not always be desired.

  There is a practical example which, while not extremely common, is
nevertheless very plausible: Rendering a widescreen DVD video.

  If I remember correctly, the DVD format has two basic aspect ratios:
the traditional 4:3 and the newer standard 16:9. However, the raw image
pixel data is *always* in a 4:3 format. A 16:9 video is anamorphically
squeezed to 4:3 (and thus a DVD player will make the reverse stretching
when it has to display on a 16:9 resolution).

  In other words, if you wanted to render a 16:9 video for DVD, you will
have to set the aspect ratio of the camera to 16:9, but render using a
4:3 resolution, thus getting non-square (ie. anamorphic) pixels.

  (I might remember the details wrongly, but anamorphic images are
definitely involved in widescreen DVD video streams.)

  If someone took an existing widescreen animation SDL file and wanted to
render it for DVD, if the SDL file used an "autocorrected" aspect ratio
setting, it would be problematic. You would have to go and modify the camera
definition in order to be able to render anamorphically.

  Another practical example is a 4:3 monitor with a non-4:3 resolution
(such as for example 1280x1024), and someone wanting to render a fullscreen
desktop image for it. The image has to be, once again, anamorphic in order
to look correct in the target system. An "auto-correcting" aspect ratio
setting in the camera definition (which assumes square pixels) would cause
trouble.

> * Frame Count:

> Instead of using the 0.00-to-1.00 clock, animations may instead use the
> frame_number for timing reference. In that case, it may be desirable to specify
> the number of frames not on the command line, but in the SDL file, either to be
> warned if different values are specified on the command line, or to always
> override those values.

  I think that causes problems with the frontend-backend division in
POV-Ray 3.7. The backend, ie. the rendering engine, cannot affect the
rendering settings (such as animation settings). It's the frontend which
determines these settings.

  The reason for this is, among other things, support for distributed
rendering. Distributing, for example, an animation among different machines
is a duty of the frontend. The frontend cannot do that if the animation
settings are determined in the SDL file (possibly inside complex scripting,
which can only be determined by parsing and interpreting the entire file).

-- 
                                                          - Warp

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Warp wrote:
> clipka <nomail@nomail> wrote:
>> I agree, however, that (b) is not an ideal solution either, as a 1:1 pixel
>> aspect ratio may not always be desired.
> 
>   There is a practical example which, while not extremely common, is
> nevertheless very plausible: Rendering a widescreen DVD video.
> 
>   If I remember correctly, the DVD format has two basic aspect ratios:
> the traditional 4:3 and the newer standard 16:9. However, the raw image
> pixel data is *always* in a 4:3 format. A 16:9 video is anamorphically
> squeezed to 4:3 (and thus a DVD player will make the reverse stretching
> when it has to display on a 16:9 resolution).
> 
	Actually, it's almost *never* a 4:3 ratio. Typical formats include:
720x576 (PAL), 640x576 (PAL), 480x576 (PAL), 720x480 (NTSC), 640x480
(NTSC, the only 4:3 format here) and 480x480 (NTSC). Of course, this
is only for SD. Typical HD formats do have 16:9 ratio...

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknCpeIACgkQd0kWM4JG3k+rAwCgozMeh/nZZ9zUPy8IZmD996cb
xTYAn2OGj+bw5nyBum5wE/OibG2VXzFY
=Bgie
-----END PGP SIGNATURE-----

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   There is a practical example which, while not extremely common, is
> nevertheless very plausible: Rendering a widescreen DVD video.
....
>   Another practical example is a 4:3 monitor with a non-4:3 resolution
....

Yes, I didn't want to go into detail on these. To the best of my knowledge
you're perfectly right on these issues, and a good deal of them is already
mentioned in the FAQ.


> > * Frame Count:
>
> > Instead of using the 0.00-to-1.00 clock, animations may instead use the
> > frame_number for timing reference. In that case, it may be desirable to specify
> > the number of frames not on the command line, but in the SDL file, either to be
> > warned if different values are specified on the command line, or to always
> > override those values.
>
>   I think that causes problems with the frontend-backend division in
> POV-Ray 3.7. The backend, ie. the rendering engine, cannot affect the
> rendering settings (such as animation settings). It's the frontend which
> determines these settings.
>
>   The reason for this is, among other things, support for distributed
> rendering. Distributing, for example, an animation among different machines
> is a duty of the frontend. The frontend cannot do that if the animation
> settings are determined in the SDL file (possibly inside complex scripting,
> which can only be determined by parsing and interpreting the entire file).

This may be true when we're talking about overriding the values; however, even
then it would still allow for checking and *warning* about mismatches in scene
vs. command line / .ini file settings.

Post a reply to this message

clipka wrote:

> Of course, virtually every OS provides *some* way of batch processing. However,
> it would be desirable if this could be done in a way that works with all
> platforms on which POV runs.

It would be really cool to integrate this into SDL itself ;)

#declare MY_TEXTURE = scene
{
   camera {orthographic ...}
   light_source {...}
   plane {...}
}

#declare MY_SCENE = scene
{
   camera {...}
   light_source {...}
   sphere {0,1 pigment {image_map "foo.png"}}
}

render
{
   scene {MY_TEXTURE}
   width  1024
   height 1024
   output_file_name "foo.png"
}

render
{
   scene {MY_SCENE}
   width  1024
   height 768
   output_file_name "myscene.png"
}

This also allows for variables which persist across multiple frames
in animations (done manually using a #while loop). And just imagine
what you can do with macros. Well, better not to hold my breath ;)

Post a reply to this message

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>  Actually, it's almost *never* a 4:3 ratio. Typical formats include:
> 720x576 (PAL), 640x576 (PAL), 480x576 (PAL), 720x480 (NTSC), 640x480
> (NTSC, the only 4:3 format here) and 480x480 (NTSC).

Actually, PAL and NTSC have nothing to do with resolution or aspect ratios -
they're just standards for color encoding in analog TV signals.

(The DVD-formats often maldesignated as PAL and NTSC are in fact EIA 525/60
(NTSC) or CCIR 625/50 (PAL), respectively.)

With Analog TV in turn, it doesn't make *any* sense at all to speak about
horizontal resolution. They only have a certain number of lines per "field",
and a nominal aspect ratio - which as a matter of fact has *always* been 4:3
for *all* non-widescreen formats (even pre-WW2 experimental TV systems often
used 4:3, although 7:3 seems to have been used surprisingly often, too).

Film, on the other hand, has been using a wide variety of formats since its
birth, both for stills and movies: 4:3, 11:8, 5:3, 2:1, 3:2, and probably some
more odds & ends.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> I was thinking about the separation between SDL and command line parameters
> for a few things: ...

This time, clipka, you aren't *enlightened me immensely*.
For this, sorry! :-D

Frankly, the *Image & Pixel Aspect Ratio*, I think it unnecessary, even for a
*Beginner*.

About "Frame Count" and "Batch Render" I am in *loud silence*, for now.


--
Carlo

Post a reply to this message

"Carlo C." <nomail@nomail> wrote in message
news:web.49c35e68a38ff5307cb988ed0@news.povray.org...
> Frankly, the *Image & Pixel Aspect Ratio*, I think it unnecessary, even
for a
> *Beginner*.

Thanks Carlo for speaking up .... I read clipka's post several times and I
kept thinking isn't that what the 'right' keyword is for?

I use this in my camera definition:
right x*image_width/image_height

then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!

What have I missed?

Jim

Post a reply to this message

Jim Holsenback <jho### [at] hotmailcom> wrote:
> Thanks Carlo for speaking up .... I read clipka's post several times and I
> kept thinking isn't that what the 'right' keyword is for?

> I use this in my camera definition:
> right x*image_width/image_height

> then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!

> What have I missed?

  You get all the problems inherent with it. They are mentioned in the Q&T
list.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Jim Holsenback <jho### [at] hotmailcom> wrote:
> > Thanks Carlo for speaking up .... I read clipka's post several times and I
> > kept thinking isn't that what the 'right' keyword is for?
>

Thanks for what, Jim?
I am the "last of the last", here. :-D


> > I use this in my camera definition:
> > right x*image_width/image_height
>
> > then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!
>
> > What have I missed?
>
>   You get all the problems inherent with it. They are mentioned in the Q&T
> list.
>
> --
>                                                           - Warp

Here?
http://tag.povray.org/povQandT/languageQandT.html#aspectratio

--
Carlo

Post a reply to this message