Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> How about a compromise regarding the recent debate:

> The scene viewport (angle and aspect ratio) should be set within the
> SDL.  By some convenient coincidence, this is already the case, so no
> change to the SDL would be necessary in this regard.

This is good, because it allows the scene author to suggest an aspect ratio.

The problem here that needs to be addressed by a new camera statement is that
there currently is not a standardized way of specifying this AND at the same
time allowing for some flexibility in handling mismatches between scene author
and "end user" desires.


> If you want to render to non-square pixels, you must specify so in an
> INI file or via commandline parameter.  I'm sure better keywords could
> be found, but since I can't think of any we could just use:
> Pixel_Squat = 0.5 // Pixels are half as tall as they are wide

This, too, is good (how come this suggestion sounds familiar to me? :P), because
it allows the "end user" to clearly specify to what pixel aspect ratio he is
rendering to, which is definitely required to discern between *apparent* apsect
ratio mismatches due to non-square target pixel size, and *real* mismatches.

(I'd suggest a different name though, e.g. "Pixel_Aspect_Ratio" - and a pixel
shape of X by Y units being specified as the quotient X/Y, i.e.
"Pixel_Aspect_Ratio=0.5" specifying that the pixels are supposed to be twice as
tall as they are wide - just the other way round as you suggested.)


> Whenever you set either the width or the height of the image, POV checks
> your pixel aspect ratio (the Pixel_Squat value, which defaults to 1.0
> {square pixels}) and adjusts the other dimension accordingly to give an
> appropriately scaled image.

This, too, is good, as it allows the end user to set a resolution without
worrying about whether it matches the intended aspect ratio.


I'd not stop here however, and instead suggest (once again) to support
specifying *both* desired output height and width (in pixels) of the image,
with the following results (to be chosen by the "end user"):

(a) Treat those values as *minimum* values, increasing one of the values as
necessary to fit the aspect ratio suggested by the scene author.

(b) Treat those values as *maximum* values, decreasing one of the values as
necessary to fit the aspect ratio suggested by the scene author.

(c) Similar to (b), but automatically add "blank space" to match the specified
width and height, filled with a user-specified RGBA color value (probably
defaulting to black for image output without alpha channel, and transparent for
image output with alpha channel).

(d) Similar to (a), but automatically crop the resulting image to fit the
specified width and height.

(e) Override the scene author's suggested aspect ratio (use at your own risk;
actually, again quite a bunch of variations that might be worth supporting)


In addition, it might be worth providing a way for the scene author to specify
that other aspect ratios are also safe - e.g. specifying a range instead of a
fixed value, and using a formula to compute the camera angle (library functions
could be provided for keeping a fixed vertical or horizontal angle,
respectively).


Further, for some (if not actually all) use cases it might be easier for the
"end user" to not specify the pixel aspect ratio, but to instead specify both
the intended output image aspect ratio (with the above results), and the output
image resolution in pixels. I guess usually this information will be more
readily available than the pixel aspect ratio.

Post a reply to this message