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.

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

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.

So, if you're rendering for a target where the pixels are half as high 
as they are wide, then you would specify the above Pixel_Squat = 0.5, 
and an 800x600 image would be rendered at 800x1200 to give the 
appropriate image.

This approach allows scene authors to control their scene aspect ratios, 
and scene consumers / perusers to easily scale images for their native 
displays.

Images won't necessarily fill your screen, but then neither do movies or 
TV shows (unless you get really lucky).  Live with it.

-- 
Chambers

Post a reply to this message

> 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 would be a great improvement, especially with the default as 1.0.

Next we have to decide what POV does when you specify the width *and* the 
height, and these don't match the camera (assuming pixel_squat is the 
default of 1.0).  The default should be to keep the image at the specified 
aspect ratio and fitting inside the specified output resolution (ie one 
dimensions of the image output resolution will be lower than you specified 
in the ini file or command line).

But there should also be a "clip" option where the image is scaled up (and 
cropped) so the image output size is exactly as you specified and completely 
filled.  This would be useful for lots of images, and would save the process 
of multiple-renderings (or searching for the camera block) to work out the 
correct resolution to give POV, then clipping in an external program.  It 
would be very easy to code in POV, but save a lot of people work.

Post a reply to this message

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

scott wrote:
> But there should also be a "clip" option where the image is scaled up 
> (and cropped) so the image output size is exactly as you specified and 

I would be against that, as it would (essentially) be POV-Ray 
automatically editing your image.  Let the scene designer edit the 
image; let POV render it.

As far as specifying both width and height, with this system there are 
three options:

1) Change the Pixel_Squat value *for this render only* to match the 
specified dimensions.
2) Use the final of the two values as your input.
3) Throw an error at the user.

-- 
Chambers

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> scott wrote:
> > But there should also be a "clip" option where the image is scaled up
> > (and cropped) so the image output size is exactly as you specified and
>
> I would be against that, as it would (essentially) be POV-Ray
> automatically editing your image.  Let the scene designer edit the
> image; let POV render it.

I can imagine situations where even the scene author himself (!) may *want* that
to happen.

Yes, scene designer and "end user" may be different persons.

No, they need not necessarily be.

Yes, the scene designer may have a very categoric opinion about this issues.

No, it doesn't necessarily have to be the same opinion you are holding.


I say, give freedom to *both* the scene editor (by allowing him to express
clearly what his thoughts about this issue are, and respect them by default),
and the "end user" (by allowing him to deliberately override the author's
intentions).

For instance, when someone buys a poster, you can't prevent him from cropping it
to fit a frame he happens to have.

Now you'll surely argue that anyone is free to crop the output of a render
afterwards with image editing software.

However, I say that this argument falls short, because being able to
automatically crop may also be considered a feature even by scene authors
themselves.

So in order to protect *some* scene authors from oh-so-evil "end users", you
want to forfeit something that *other* scene authors may want for themselves?

Post a reply to this message

clipka wrote:
> So in order to protect *some* scene authors from oh-so-evil "end users", you
> want to forfeit something that *other* scene authors may want for themselves?

Scene authors already have the ability to change the aspect ratio... in 
fact, so do end users.  If you're working with the code, just change the 
"up" and "right" vectors in the camera statement.

This is the proper way to change the image... by changing the source!

You should NOT change the image by specifying render options on the 
command line.

-- 
Chambers

Post a reply to this message

> You should NOT change the image by specifying render options on the 
> command line.

The person rendering the image can already specify which section of the 
image to render, how many colours to use, how much AA to use etc on the 
command line, why shouldn't he also specify if the image should be cropped 
or scaled to fit his desired output resolution?  Seems completely logical to 
me and familiar to many users in other apps and the OS itself.

Not allowing POV to crop images because you think it's wrong is completely 
ridiculous, if someone wants to crop an image they will, so why not make it 
way easier?

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> clipka wrote:
> This is the proper way to change the image... by changing the source!
>
> You should NOT change the image by specifying render options on the
> command line.

Says who? And why?

Don't start again with that "scene author's decision" argument, because that
would be a circular one in this case.


Render options are *THE* thing to use to adapt the scene to certain image output
constraints. Like file formats. Or pixel aspect ratios. Or media aspect ratios,
for that matter.

You should NOT change the scene to fit it to some particular, media-dependent
output constraints.

Post a reply to this message