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