Port of FS85 - Aspect ratio issues

wfpokorny commented 7 years ago

http://bugs.povray.org/task/85 (Juha Nieminen (Warp))

(Better aspect ratio control)

Details:

Background

When rendering an image, there are actually three aspect ratios involved:

1) The aspect ratio of the camera, set with the up and right vectors.

2) The aspect ratio of the rendered image, set with the +W and +H parameters.

3) The aspect ratio of the pixels in the intended target medium. While this is very often 1:1, it's definitely not always so (anamorphic images are common in some media, such as DVDs).

The aspect ratio of the camera does not (and arguably should not, although some people might disagree) define the aspect ratio of the image resolution, but the aspect ratio of the image as shown on the final medium. In other words, it defines how the image should be displayed, not what the resolution of the image should be.

This of course means that the aspect ratio of the target medium pixels has to be taken into account when specifying the image resolution. If the target medium pixels are not 1:1 (eg. when rendering for a medium with non-square pixels, or when rendering an anamorphic image eg. for a DVD), the proper resolution has to be specified so that the aspect ratio of the displayed image remains the same as the one specified in the camera block.

This isn't generally a problem. It usually goes like "my screen is physically 4:3, so I design my scene for that aspect ratio, but the resolution of my screen is mxn which is not 4:3, but that doesn't matter; I just render with +Wm +Hn and I get a correct image for my screen".

However, problems start when someone renders an image using an image aspect ratio / pixel aspect ratio combination which does not match the camera aspect ratio. By far the most common situation is rendering a scene with a 4:3 camera for a screen with square pixels but with a non-4:3 resolution (most typically 16:9 or 16:10 nowadays). The image will be horizontally stretched.

In a few cases the effect is the reverse: The scene (and thus the camera) has been designed for some less-typical aspect ratio, eg. a cinematic 2.4:1 aspect ratio, but then someone renders the image with a 4:3 resolution. The resulting image will be horizontally squeezed.

In a few cases this is actually the correct and desired behavior, ie. when you are really rendering the image in an anamorphic format (eg. for a DVD). However, often it's an inadverted mistake.

Some people argue that this default behavior should be changed. However, there are also good arguments why it should not be changed. Some argue that POV-Ray should have more features (at the SDL level, at the command-line level or both) to control this behavior.

There are several possible situations, which is why this issue is so complicated. These situations may include:

The scene author doesn't really care what aspect ratio is used to render the image, even if it means that additional parts of the scenery become visible or parts are cropped away when using a different aspect ratio than what he used.

In this case the choice of camera aspect ratio should be up to the person who renders the image, and thus selectable on the command-line. However, he should have an easy choice of how changing the aspect ratio affects the image: Should it extend the viewing range, or should it crop part of it, compared to the original?

And this, of course, while still making it possible to render for an anamorphic format.

The author wants to support different aspect ratios, but he wants to control precisely how it affects the composition of the image. Maybe he never wants anything cropped away within certain limits, but instead the image should always be extended in whichever direction is necessary due to the aspect ratio. Or maybe he wants to allow cropping the image, but only up to a certain point. Or whatever.

In this case the choice of camera aspect ratio should be up to the author, and thus selectable in the scene file, while still allowing some changes from the command-line.

The author designed his scene for a precise aspect ratio and nothing else, and doesn't want the image to be rendered in any other aspect ratio. Maybe he used some very peculiar aspect ratio (eg. something like 1:2, ie. twice as tall as wide) for artistic composition reasons, and wants the image rendered with that aspect ratio, period.

Perhaps the author should be able to completely forbid the change of camera aspect ratio in the command-line.

Of course anamorphic rendering should still be supported for targets with a different pixel aspect ratio.

Possible solution

This solution does not necessarily address all the problems described above perfectly, but could be a good starting point for more ideas:

Add a way to specify in the camera block minimum and maximum limits for the horizontal and vertical viewing angles (and if any of them is unspecified, it's unlimited). Of course for this to be useful in any way, there should also be a way to change the camera and pixel aspect ratios from the command line.

The idea with this is that the author of the scene can use these angle limits to define a rectangular "protected zone" at the center of the view, using the minimum angle limits. In other words, no matter how the camera aspect ratio is modified, the horizontal and/or vertical viewing angles will never get smaller than these minimum angles. This ensures that the image will never be cropped beyond a certain limit, only extended either horizontally or vertically to ensure that the "protected zone" always remains fully visible regardless of what aspect ratio is used.

The maximum angles can be used for the reverse: They ensure that no scenery beyond a certain point will ever become visible, no matter what aspect ratio is used. This can be used to make sure that unmodelled parts of the scene never come into view. Thus the image will always be cropped to ensure this, depending on the aspect ratio.

I'm not completely sure what should be done if both minimum and maximum angles are specified, and the user specifies an aspect ratio which would break these limits. An error message could be a possibility. At least it would be a way for the author to make sure his scene is never rendered using an aspect ratio he doesn't want. He can use these angle limits to give some leeway how much the aspect ratio can change, to an extent, or he could even force a specific aspect ratio and nothing else (by specifying that both the minimum and maximum angles are the same).

So in short:

Add a "minimum/maximum horizontal/vertical angles" feature to the camera block. These can be used to define a "protected zone" in the image which must not be breached by command-line options.
Add a command-line syntax to change the camera aspect ratio (which automatically obeys the "protected zone" settings). Could perhaps give an error message if the command-line options break the limits in the scene camera.
Add a command-line syntax to specify a pixel aspect ratio other than 1:1. This can be used to render anamorphic versions of the image on purpose (iow. not by mistake).

This can probably be made backwards-compatible in that if none of these new features are used, the behavior could be the same as currently (or at least similar).

Comments:

Comment by Christoph Lipka (clipka) - Tuesday, 23 March 2010, 03:04 GMT+5

Angles are rather difficult to control, and problems with the many existing ways of specifying the camera viewport are likely. Therefore, instead of SDL statements to specify min/max angles, I'd propose to instead specify a "nominal camera viewport" the traditional way, and specify the "protected zone" and "maximum zone" dimensions relative to the nominal viewport's dimensions; i.e. a scene author might specify that e.g. the viewport is to be at least 0.9 = 90% as wide and 0.95 = 95% as high as the nominal viewport, and at most 1.0 = 100% as wide and 1.2 = 120% as high.

As for the pixel aspect ratio, I'd advocate specifying it indirectly via the display's aspect ratio, e.g. in order to render an image at 1280x1024 pixels resolution for a 4:3 display, the user would specify something like "-w1280 -h1024 Aspect_Ratio=4:3" to achieve the required pixel aspect ratio of 16:15. I guess for any given output medium the display aspect ratio is much more commonly known than the pixel aspect ratio.

Comment by Thorsten Fröhlich (thorsten) - Friday, 02 July 2010, 09:59 GMT+5

With (1) and (2) the system is fully determined. To let others match the image size, supplying an INI file with a scene lets them do that. In particular the ability to have multiple sections in an INI file is useful for this (note to self: Is this feature implemented in the core code yet?).

After all, it should be kept in mind that POV-Ray is not a video viewer, but a rendering program. Users need and want control over the image they render beyond what the original author of a scene intended. As the scene is plain text, there is no way to prevent this, and it seems counter-intuitive to add obscure means to get what an author of a scene "wants" other users to do.

Comment by Juha Nieminen (Warp) - Friday, 02 July 2010, 22:46 GMT+5

The main purpose of the feature request is not to give a scene author the means to limit what another person can do with his scene. The idea is to give the author tools to prevent his image from being accidentally rendered with the wrong aspect ratio. This is an actual problem. I haven't even counted how many renders I have seen of scenes/advanced/abyss.pov with a completely wrong aspect ratio (pretty much destroying the image).

Comment by Grimbert Jérôme (Le_Forgeron) - Thursday, 02 September 2010, 12:55 GMT+5

The more I think about it, the more I think we got it wrong from the very start.

There is in fact 2 set of related data, for a total of 6: view-height, view-width, view-ratio image-height, image-width, pixel-ratio

view-height & view-width are usually set in the SDL, (up & right, angle...) with an implicit view-ratio ( = view-width/view-height)

image-height & image-width are set from the command line, with an implicit pixel-ratio ( = image-width / (image-height * view-ratio) )

It could be better if instead of -H & -W, the user got to specify either -H or -W and the pixel-ratio ( -P float ? or -PH integer -PW interger ?).

That way, the view would stick to the intent of the scene's creator (in unmodified SDL) and the picture would be fine for the display of the final user.

The issue would be the usage of image_width & image_height in SDL, they would have to be gone.

If the final user wants to see more than intended by the file's creator, he would have, with that system, to open & edit the SDL.

Final note: I do not ask for the removal of -W or -H, but that instead the mandatory missing dimension should be provided by computation based on pixel ratio and the provided dimension (and it might be convenient to provide either of them to please the final user).

On the same line, an explicit "view_ratio" in the camera might compute the up length from the right/angle size (and it might be a clearer clue for the casual reader:

camera { ...
right x
angle 14
view_ratio 16/9
look_at ...
}

Comment by Christoph Lipka (clipka) - Thursday, 02 September 2010, 16:40 GMT+5

I basically agree with Grimbert. The idea of specifying the image aspect ratio in the scene file, and specifying only either width or height on the command line or in the ini file, already crossed my mind, too. Though I'd retain the image_height and image_width variables, as they might be useful for level-of-detail adjustments, or other special effects; I have already designed scenes myself that wouldn't work without.

Comment by Juha Nieminen (Warp) - Thursday, 02 September 2010, 22:50 GMT+5

The suggestion that instead of defining the width and height of the image to be rendered, the user instead defines the width only (or the height only), and then possibly defines a pixel aspect ratio (which defaults to 1:1), while the other dimension is determined automatically from the camera settings, is a good one and solves most of the problems described.

However, there may still be the possibility that the author of the scene would want to allow the view to be expanded or possibly cropped if a different image aspect ratio is defined, which the suggestion does not address. This may well be something one wants to support so that one could eg. render 4:3 and a 16:9 versions of the same scene (their difference being eg. that in the latter the horizontal angle of the camera is larger, so more scenery comes into view from the sides).

Comment by Thorsten Fröhlich (thorsten) - Tuesday, 23 August 2011, 11:23 GMT+5

I agree that some solution for this feature request needs to be found. However, this should not involve an interaction between INI/command-line parameters and the SDL, as we can't have a case where the SDL interacts with the frontend code

wfpokorny commented 7 years ago

Note: The sphere_sweep references from May 1 are bogus and have nothing to do with this issue. Guessing auto-reference created due typos since corrected in text for those issues.

wfpokorny commented 7 years ago

Link to related newsgroup discussion:

http://news.povray.org/povray.programming/thread/%3C594c2b82%241%40news.povray.org%3E/

jmichae3 commented 7 years ago

ummm, what if I have 3 monitors at xres each and need the resolution set to width=xres3monitors height=yres? I need 1:1 pixe;ls, no pixel aspect ratio there, that messes things up. just like 640x480 image is aspect ratio 4:3 is 1:1 pixel size and inches 4:3 and in pixel resolution is 4:3. when looking at a monitor, you are looking at xdpi and ydpi. windows does not set this very well, just assumes square pixels when indeed they are not square dpi. when you are talking multiple monitors, there is an aspect ratio of inches and an aspect ratio of pixels, which for my 2-monitor setup would be 16:5 total in pixels and in inches 16.56:9.312monitors=33.12:9.31. so don't forget pixel size. I had to measure my monitor with a tape measure to get parameters. camera space is not necessarily in inches so it's dp? or dots per space unit (dpsu?). unless you render your objects in inches on purpose. consider the viewport from the camera as (forgot my train of thought).

c-lipka commented 7 years ago

Your 16.56"-by-9.31" displays have an aspect ratio of pretty much exactly 16:9 each, and I would assume that the resolution in pixels is also 16:9 for each display (e.g. 1920x1080). Native PC display resolutions rarely use non-square pixels these days. (Things were a lot different in times of CRT displays.)

If you set Windows to a resolution that differs from the native display resolution, then of course you may get non-square "pixels", but I wouldn't recommend that anyway.

That said, whatever mechanism we'll ultimately implement to make aspect ratio handling easier, we'll also make sure that non-square-pixel images can still be generated.

I'm not sure why you're mentioning 2-monitor setup. There are no plans to automatically set the output image resolution to the system's display resolution, so it's irrelevant whether you have one or two monitors of any given aspect ratio connected. As a matter of fact, the monitor aspect ratio per se is also entirely irrelevant -- unless you want to render desktop backgrounds.

POV-Ray / povray

Port of FS85 - Aspect ratio issues #284