It took me 13 years of povving to understand the camera. That is, to come up
with the code for a box which exactly fills the screen, regardless of camera
angle/ distance and image aspect ratio.

I believe that the documentation provided with povray tells no lies, but it
doesn't tell enough of the truth. If you already fully understand how the
camera works, what is written there makes sense. But there are notable
omissions from the documentation:

i) no mention of how +W and +H affect the camera.
ii) no mention of the hierarchy of all these redundant little variables.

Q: If one were to redesign the camera object from scratch, could you make it
more intuitive? Could the camera either require either  more heavily lifting or
less?
What if it automatically gave you circular-cross-section spheres regardless of
the pixel ratio?  How many people *want* elliptical-looking spheres when they
change the pixel ratio?

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> i) no mention of how +W and +H affect the camera.

  Perhaps because those parameters don't affect the camera in any way?

  (Ok, there's an exception: If you use image_width or image_height for
defining anything in the camera block, then they do affect it. But that's
not all that relevant.)

> What if it automatically gave you circular-cross-section spheres regardless of
> the pixel ratio?  How many people *want* elliptical-looking spheres when they
> change the pixel ratio?

  What happens when you *want* to render the image for a resolution with
non-square pixels?

  (Yes, there are such situations, and they are pretty common. Search for
"anamorphic" if you don't believe me.)

  And if the aspect ratio of the pixels were always assumed to be 1:1 when
changing the resolution of the rendered image, which dimension or the camera
should change when the aspect ratio of the image changes?

-- 
                                                          - Warp

Post a reply to this message

>> What if it automatically gave you circular-cross-section spheres 
>> regardless of
>> the pixel ratio?  How many people *want* elliptical-looking spheres when 
>> they
>> change the pixel ratio?
>
>  What happens when you *want* to render the image for a resolution with
> non-square pixels?

You specify in some way that you want this, rather than it being the default 
behaviour.

>  (Yes, there are such situations, and they are pretty common. Search for
> "anamorphic" if you don't believe me.)

Whilst they may be pretty common, I can't believe they are as common 
compared to people who change the aspect ratio for rendering as a desktop 
wallpaper or printing out on certain sized paper.

>  And if the aspect ratio of the pixels were always assumed to be 1:1 when
> changing the resolution of the rendered image, which dimension or the 
> camera
> should change when the aspect ratio of the image changes?

The scene file author should get to decide.  How about the following syntax:

camera{
 hfov 90
}

This would fix the horizontal field of view to 90 degrees, POV would 
automatically calculate the vertical FOV to ensure square pixels based on 
the image aspect ratio.  This would work if you made some landscape scene 
and didn't want any more to be visible left/right, or any part to be cropped 
left/right, by rendering at different aspect ratios you just get to see more 
or less sky.

Of course the scene author could also use just the "vfov" keyword if they 
wanted the vertical FOV to remain fixed and the horizontal to be calculate 
automatically.

Then, of course you could specify both "hfov" *and* "vfov" if you really 
wanted both directions to be fixed, this would allow for non-square pixels. 
POV *could* even warn you that this was about to happen (maybe just once for 
each scene file, IDK), and give you three options: 1) render non-square, 2) 
adjust the horizontal image resolution to give square pixels, 3) adjust the 
vertical image resolution to give square pixels.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  What happens when you *want* to render the image for a resolution with
> > non-square pixels?

> You specify in some way that you want this, rather than it being the default 
> behaviour.

  I'd want it the other way: If you want to use a different camera aspect
ratio you have to specify it. By default the camera aspect ratio should be
preserved.

> >  (Yes, there are such situations, and they are pretty common. Search for
> > "anamorphic" if you don't believe me.)

> Whilst they may be pretty common, I can't believe they are as common 
> compared to people who change the aspect ratio for rendering as a desktop 
> wallpaper or printing out on certain sized paper.

  Have you taken into account that someone rendering someone else's scene
using an aspect ratio different than what the original author intended
might end up with an image which either clips out parts of the original
image or, worse, shows undermodeled parts which were not meant to be seen?

  Shouldn't the choice of how changing the aspect ratio of the camera
affects the composition of the image be left to the author of the image
rather than the person who renders the image (given that sometimes these
are two different people)?

-- 
                                                          - Warp

Post a reply to this message

>  Have you taken into account that someone rendering someone else's scene
> using an aspect ratio different than what the original author intended
> might end up with an image which either clips out parts of the original
> image or, worse, shows undermodeled parts which were not meant to be seen?
>
>  Shouldn't the choice of how changing the aspect ratio of the camera
> affects the composition of the image be left to the author of the image
> rather than the person who renders the image (given that sometimes these
> are two different people)?

If you read the rest of my post you'll see that I 100% agree with you, and 
this is what my proposed syntax allows, albeit with more flexibility than 
the existing one.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> If you read the rest of my post you'll see that I 100% agree with you, and 
> this is what my proposed syntax allows, albeit with more flexibility than 
> the existing one.

  It is currently possible to make a camera which always assumes square
pixels. Doing so in a way that changing aspect ratio affects the composition
of the image vertically (ie. the image is clipped or extended on the upper
and lower sides) is easy. The horizontal equivalent requires a bit more
work, but is also perfectly possible.

  (Personally I don't really recommend doing so, for the stated reasons.
I'd say the principal reason is that rendering for an anamorphic resolution
with non-square pixels cannot be done without modifying the scene file.)

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> camera{
> hfov 90
> }

What's wrong with the "angle" keyword?

-- 
Chambers

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> Then, of course you could specify both "hfov" *and* "vfov" if you really
> wanted both directions to be fixed, this would allow for non-square pixels.

Not the ideal solution, as getting from the desired image & pixel aspect ratios
(which I expect to be *the* known values in such cases) to the angles requires
some messing around with trigonometrics.

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> scott wrote:
> > camera{
> > hfov 90
> > }

> What's wrong with the "angle" keyword?

  It sets the horizontal field of view (regardless of what the camera
aspect ratio is). Making it set the vertical field of view instead requires
something more complicated.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > You specify in some way that you want this, rather than it being the default
> > behaviour.
>
>   I'd want it the other way: If you want to use a different camera aspect
> ratio you have to specify it. By default the camera aspect ratio should be
> preserved.

Me, I cast my vote for the default-to-square-pixels approach.

>   Have you taken into account that someone rendering someone else's scene
> using an aspect ratio different than what the original author intended
> might end up with an image which either clips out parts of the original
> image or, worse, shows undermodeled parts which were not meant to be seen?

This argument is a bit short-sighted: The same could be said about rendering an
image at a much higher resolution than originally intended by the author -
which may get you "undermodeled" parts *everywhere*.

Furthermore, an author cannot pass on his scene's source code and at the same
hide those undermodeled parts from curious eyes - just a few changes to the
camera block will reveal them anyway.


Even so, as some previous poster mentioned, a possible solution to this issue
would be to allow the scene author to specify (in the camera settings) how to
deal with non-matching aspect ratios, by choosing between (e.g.)

  a) adjust horizontal field of view to fit
  b) adjust vertical field of view to fit
  c) enlarge field of view to fit
  d) reduce field of view to fit
  e) distort to fit
  f) enforce aspect ratio

(Option f) could pick a resolution with about the same total number of pixels as
specified on the command-line / ini file, but the ratio chosen by the scene
author.)

If complemented with command-line / ini options to explicitly specify a pixel
aspect ratio, I guess we'd have all aspect ratio issues solved.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Me, I cast my vote for the default-to-square-pixels approach.

  Why? You can *already* do that with the current POV-Ray. There's no need
to add anything new to get the behavior.

> >   Have you taken into account that someone rendering someone else's scene
> > using an aspect ratio different than what the original author intended
> > might end up with an image which either clips out parts of the original
> > image or, worse, shows undermodeled parts which were not meant to be seen?

> This argument is a bit short-sighted: The same could be said about rendering an
> image at a much higher resolution than originally intended by the author -
> which may get you "undermodeled" parts *everywhere*.

  There is a big difference between rendering at higher resolution and
outright clipping big parts of the image out, or adding big parts which
weren't intended to be seen.

> Furthermore, an author cannot pass on his scene's source code and at the same
> hide those undermodeled parts from curious eyes - just a few changes to the
> camera block will reveal them anyway.

  You would have to intentionally tamper with the scene file in order to
destroy the image composition. With an automatic square-pixel assumption
the tampering would be inadverted.

> Even so, as some previous poster mentioned, a possible solution to this issue
> would be to allow the scene author to specify (in the camera settings) how to
> deal with non-matching aspect ratios, by choosing between (e.g.)

>   a) adjust horizontal field of view to fit
>   b) adjust vertical field of view to fit
>   c) enlarge field of view to fit
>   d) reduce field of view to fit
>   e) distort to fit
>   f) enforce aspect ratio

  All of those can be already done with the current version of POV-Ray.

> If complemented with command-line / ini options to explicitly specify a pixel
> aspect ratio, I guess we'd have all aspect ratio issues solved.

  In fact, that can also be done currently, albeit indirectly. You can use
the 'Declare' command-line option to pass values to the scene file. You
can create a camera definition which sets its aspect ratio according to
such an identifier.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   All of those can be already done with the current version of POV-Ray.

In fact, I fail to see a need for changing the camera at all.  Of 
course, I'm one of the people who simply "got it" when reading (gasp!) 
the docs.

-- 
Chambers

Post a reply to this message

>>   a) adjust horizontal field of view to fit
>>   b) adjust vertical field of view to fit
>>   c) enlarge field of view to fit
>>   d) reduce field of view to fit
>>   e) distort to fit
>>   f) enforce aspect ratio
>
>  All of those can be already done with the current version of POV-Ray.

I think the point of the request is to make easier to choose from the above 
options without needing to resort to some carefully figured out statements.

Post a reply to this message

>> camera{
>> hfov 90
>> }
>
> What's wrong with the "angle" keyword?

It isn't obvious from the keyword exactly what it sets, and there isn't a 
vertical equivalent.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> I think the point of the request is to make easier to choose from the above 
> options without needing to resort to some carefully figured out statements.

  That might have been a minor, secondary point. The main point was that
the current default camera behavior should be changed. *That* is what I
disagreed with.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>> What's wrong with the "angle" keyword?
> 
> It isn't obvious from the keyword exactly what it sets, and there isn't 
> a vertical equivalent.

 From 3.3.1.1.3:
"The angle keyword followed by a float expression specifies the 
(horizontal) viewing angle in degrees of the camera used."

Am I wrong to assume that someone can look up the documentation?

Aside from that, if you want to change the aspect ratio of the image, I 
find POV's up and right vector usage quite easy to use.

But again, I'm one of those weirdos who actually knows how to read (the 
docs).

-- 
Chambers

Post a reply to this message

>  That might have been a minor, secondary point. The main point was that
> the current default camera behavior should be changed. *That* is what I
> disagreed with.

The current default behaviour means that if you want to render someone elses 
scene for your desktop wallpaper or to print out, you have to search through 
their code for the right camera block and make some changes, I can't even 
remember the number of times I have had to search through and put in some 
"image_width/image_height" statement.  Is this really the best thing for the 
default behaviour?  IMO the default behaviour should mean the least work for 
what is most common, ie if you actually *want* non-square pixels you should 
have to go and fiddle with the code.

Post a reply to this message

>>> What's wrong with the "angle" keyword?
>>
>> It isn't obvious from the keyword exactly what it sets, and there isn't a 
>> vertical equivalent.
>
> From 3.3.1.1.3:
> "The angle keyword followed by a float expression specifies the 
> (horizontal) viewing angle in degrees of the camera used."
>
> Am I wrong to assume that someone can look up the documentation?

Of course not, but using eg "hfov" instead of "angle" means you don't even 
need to open the documentation to realise what it is setting.  It also then 
means the corresponding vfov could be used, again, without having to lookup 
in the documentation.  Once a language syntax gets more complex it's 
actually really handy to work like this, where most things are "obvious" 
without having to look up in the documentation each time.

> But again, I'm one of those weirdos who actually knows how to read (the 
> docs).

...and I'm one of those weirdos who doesn't like needless inefficiencies, no 
matter how small :-)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> The current default behaviour means that if you want to render someone elses 
> scene for your desktop wallpaper or to print out, you have to search through 
> their code for the right camera block and make some changes, I can't even 
> remember the number of times I have had to search through and put in some 
> "image_width/image_height" statement.

  If the author didn't put such a statement in their camera block, then
maybe the author didn't even intend for the image to be rendered in other
aspect ratios?

  And if you really want to censor part of the image so that it will fit
your screen, then how about rendering it with the intended aspect ratio
and the width of your screen, and then clip it with image editing software?
At least that way you have more control over what you are censoring.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > Am I wrong to assume that someone can look up the documentation?

> Of course not, but using eg "hfov" instead of "angle" means you don't even 
> need to open the documentation to realise what it is setting.

  And exactly how would you even know about the "hfov" keyword without
reading the documentation?

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> I can't even remember the number of times I have had to search 
> through and put in some "image_width/image_height" statement.

Then you're abusing other peoples' images.  Maybe you should accept the 
fact that particular images are not going to fit your monitor 
full-screen, but will instead have to be either cropped or letterboxed.

 From what you've been saying, it sounds like you'd prefer cropping.

Anyway, I firmly believe that input should be separate from output, and 
that any image should be renderable at any resolution.

-- 
Chambers

Post a reply to this message

>> Of course not, but using eg "hfov" instead of "angle" means you don't 
>> even
>> need to open the documentation to realise what it is setting.
>
>  And exactly how would you even know about the "hfov" keyword without
> reading the documentation?

Because it comes in the default camera block? (Insert -> Camera -> ...) or 
has been already written in a scene you are looking at?  The benefit then is 
that you can be pretty sure what it means straight away without needing to 
look it up in the documentation.  That's why we use meaningful keywords, so 
you don't have to look up everything.  Otherwise we could just use random 
sequences of letters!

Post a reply to this message

>  If the author didn't put such a statement in their camera block, then
> maybe the author didn't even intend for the image to be rendered in other
> aspect ratios?

Or maybe they just used the default, couldn't be bothered, or didn't even 
realise?  I still think if you want to enforce some fixed aspect ratio you 
should have to add it specifically, as it is not the usual behaviour needed 
when rendering.

>  And if you really want to censor part of the image so that it will fit
> your screen, then how about rendering it with the intended aspect ratio
> and the width of your screen, and then clip it with image editing 
> software?

So what, I have to search for the correct camera block, figure out what 
aspect ratio is used, compare it to my monitor aspect ratio, work out the 
dimensions so that it will fill my monitor (either width of height is the 
same, the other dimension is calculated), render the image, then load it 
into an image program and crop it to exactly the monitor dimensions?  Sure 
it's possible, but a sensible default behaviour would make it easier...

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Sure 
> it's possible, but a sensible default behaviour would make it easier...

  And what, in your opinion, should the "sensible default behavior" be
if the author wanted, for example, for his image to be rendered in a very
widescreen format like, let's say, 2.4:1 (typical movie aspect ratio), and
this because he composed his image so that it will work the best with that
aspect ratio?

  I somehow get the feeling that you are making the assumption that all
scenes are designed for a 4:3 aspect ratio because that's the default,
and that you are arguing what happens when you want to render it for a
16:9 (or sometimes 16:10) monitor.

  However, often when an author uses a very different aspect ratio, eg.
a very widescreen one, or perhaps the other extreme, a square one (or
even one which is taller than wide, for artistic composition purposes)
it's because he really intends for the image to be rendered with that
aspect ratio. Imagine that someone composes a scene which has an aspect
ratio of 1:2 (twice as tall as wide), eg. for a postcard. He *definitely*
composed the scene for that precise aspect ratio, not anything else.

  So what would be, in your opinion, the "sensible default behavior"
when you then try to render that 1:2 image into a 16:9 one? Maybe render
a 16:9 part in the middle of the original 1:2 image?

  I'm sorry, but I just disagree with you. The original image composition
should be preferred over anything else, unless the author *specifically*
allows other aspect ratios to be used (which he can in the current POV-Ray).

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  And exactly how would you even know about the "hfov" keyword without
> > reading the documentation?

> Because it comes in the default camera block? (Insert -> Camera -> ...)

  You assume everyone uses winpov, and the insert menu?

> or has been already written in a scene you are looking at?

  So you are simply delegating reading the documentation to someone else?
And how's that different from someone else having read the documentation
about the 'angle' keyword and explaining it to you?

-- 
                                                          - Warp

Post a reply to this message

>  I somehow get the feeling that you are making the assumption that all
> scenes are designed for a 4:3 aspect ratio because that's the default,
> and that you are arguing what happens when you want to render it for a
> 16:9 (or sometimes 16:10) monitor.

Yes, that is my assumption for the default behaviour, that the author just 
uses the default aspect ratio without a second thought for anyone else who 
might want to render it.  This is quite typical of the images you see posted 
on this server, which often then people then want to render as a desktop 
wallpaper.

>  However, often when an author uses a very different aspect ratio, eg.
> a very widescreen one, or perhaps the other extreme, a square one (or
> even one which is taller than wide, for artistic composition purposes)
> it's because he really intends for the image to be rendered with that
> aspect ratio.

Sure, and in that case the author should have to force the aspect ratio in 
his scene file - but it shouldn't be the default behaviour.

>  I'm sorry, but I just disagree with you. The original image composition
> should be preferred over anything else, unless the author *specifically*
> allows other aspect ratios to be used (which he can in the current 
> POV-Ray).

I see what you're saying, but my point is that in most cases (just look at 
the last 20 or images from p.b.i) the author has not set any specifc aspect 
ratio or any particular scene geometry that wouldn't work with a different 
aspect ratio.  I see it that your example is the exception to the norm, the 
author chooses some carefully calculated aspect ratio and designs his scene 
specifically only to work with that exact aspect ratio.  In which case I see 
that as a silly choice for the default behaviour.

Post a reply to this message

>> Because it comes in the default camera block? (Insert -> Camera -> ...)
>
>  You assume everyone uses winpov, and the insert menu?

No, but it's a jolly useful time saver, I recommend it.

>> or has been already written in a scene you are looking at?
>
>  So you are simply delegating reading the documentation to someone else?

That is a silly argument, the "someone else" would need to read the 
documentation anyway, so what's the disadvantage of using more meaningful 
keywords.  No wonder POV is so slow to develop if you have to debate whether 
using more meaningful keywords is a good thing or not :-(  Oh well.

Post a reply to this message

I think that there's a fundamental problem that a 4:3 aspect ratio is built-in
to the current camera.  It's not just about taking other's code and abusing it
(albeit how many really *want* to wreck non 4:3 viewing). It's not about trying
to make something full screen-- there is the concept of making one's own "art"
for print with povray, and I've got one non-4:3 monitor anyway. And what about
making square avatars?!

Stepping back a moment, there is a problem with the docs, notably the diagram,
in that the aspect ratio is NOT part of the visual equation the reader is
invited to make.  The docs have all the truth in them, in that anyone who
complains can be pointed to a phrase where they didn't RTFM, but the doesn't
*teach*. The diagram also doesn't sufficiently tell the relation between angle
and distance. If you already know how it works, the diagram doesn't lie, but it
doesn't tell you how povray uses them or handles the hierarchy of the
potentially redundant variables.


Scott sums up my views with:

<< The current default behaviour means that if you want to render someone elses
scene for your desktop wallpaper or to print out, you have to search through
their code for the right camera block and make some changes, I can't even
remember the number of times I have had to search through and put in some
"image_width/image_height" statement.  Is this really the best thing for the
default behaviour?  IMO the default behaviour should mean the least work for
what is most common, ie if you actually *want* non-square pixels you should
have to go and fiddle with the code.>>


IMHO, the current camera object is something that a smart person *can* figure
out with some work. But with so many things in programming, eventually the
exercise in pure logic ends, and the question of "How did this person decide to
put it together?" starts.  It's not logical.

Post a reply to this message

Piling on:

How about making a one-pass anaglyph, doing image processing, or setting up a
captioning system for animation, submitting to an animation contest that wants
non-4:3 entries?  For doing "great things" in povray (as opposed to "petty
things" in povray like taking someone's code to make full-screen wallpaper),
you might have to know exactly where an object will be relative to the camera.

I submit that if you gave a bunch of intelligent people the docs, most of them
wouldn't be able to straight-up code a box that exactly fills the screen. You
could probably dig up phrases buried somewhere in the doc to embarrass them
however. That's a problem.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> In which case I see 
> that as a silly choice for the default behaviour.

  I asked what should, in your opinion, be the default behavior. You didn't
answer that question.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> No wonder POV is so slow to develop if you have to debate whether 
> using more meaningful keywords is a good thing or not :-(  Oh well.

  Have you ever thought that adding new keywords can potentially break
existing scenes? The SDL namespace is already heavily cluttered as it is.

-- 
                                                          - Warp

Post a reply to this message

gregjohn <pte### [at] yahoocom> wrote:
> How about making a one-pass anaglyph, doing image processing, or setting up a
> captioning system for animation, submitting to an animation contest that wants
> non-4:3 entries?  For doing "great things" in povray (as opposed to "petty
> things" in povray like taking someone's code to make full-screen wallpaper),
> you might have to know exactly where an object will be relative to the camera.

  If you have a 4:3 photograph and you want to fill your 16:9 screen with it,
what do you do?

  Why can't the same answer be applied to a 4:3 povray-generated image?

-- 
                                                          - Warp

Post a reply to this message

>> In which case I see
>> that as a silly choice for the default behaviour.
>
>  I asked what should, in your opinion, be the default behavior. You didn't
> answer that question.

I did already in an earlier post - no time to repeat sorry, go find it if 
you're interested.

Post a reply to this message

>  If you have a 4:3 photograph and you want to fill your 16:9 screen with 
> it,
> what do you do?

Well not what POV does by default, that's for sure, unless I want everyone 
to look fat :-)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  If you have a 4:3 photograph and you want to fill your 16:9 screen with 
> > it,
> > what do you do?

> Well not what POV does by default, that's for sure, unless I want everyone 
> to look fat :-)

  So my question stands: Why can't you do the exact same thing with a
povray-generated image as you would do with a photo?

-- 
                                                          - Warp

Post a reply to this message

>  So my question stands: Why can't you do the exact same thing with a
> povray-generated image as you would do with a photo?

Of course you can, but it's usually by some contrived method (either within 
POV or with some external tool).  If the default POV camera behaviour 
matched what most people want to do when showing a 4:3 image on a 16:9 
device then it would be a lot simpler (ie you just type in +w1920 +h1200 or 
whatever and hit render).

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Of course you can, but it's usually by some contrived method

  I wouldn't consider cropping an image "contrived", but whatever.

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
>>  I somehow get the feeling that you are making the assumption that all
>> scenes are designed for a 4:3 aspect ratio because that's the default,
>> and that you are arguing what happens when you want to render it for a
>> 16:9 (or sometimes 16:10) monitor.
> 
> Yes, that is my assumption for the default behaviour, that the author 
> just uses the default aspect ratio without a second thought for anyone 
> else who might want to render it.  This is quite typical of the images 
> you see posted on this server, which often then people then want to 
> render as a desktop wallpaper.

Alright then, let's ask this:

What should the behavior be, when a scene is composed "without a second 
thought for anyone else," and originally rendered in the default 4:3 
aspect ratio... and you want to render it in a 3:4 aspect ratio for a 
vertical poster?

How should POV handle this?

The way it currently works (and which I approve of), is that aspect 
ratio is set in the scene file, and resolution is completely independent 
of it.  That is, every time you render a scene file, the picture will 
fill exactly the same shape, with all the output pixels squished into 
that shape.  If you want square pixels, then you need to make sure that 
your file aspect ratio matches the camera aspect ratio; if you have (for 
some reason) non-square pixels, then you can adjust your file ratio 
appropriately.

Perhaps a sensible compromise would be that if only the width or height 
of the file is set, and not the other, POV will assume square pixels and 
adjust the other according to the camera aspect ratio.  That is, if you 
set +w1600, and don't set height, POV will check the camera aspect ratio 
(up and right vectors) and, in the case of the default 4:3, set +h1200 
on its own (and other values according to other ratios).  This would 
certainly make scaling images easier.

-- 
Chambers

Post a reply to this message

scott wrote:
> within POV or with some external tool).  If the default POV camera 
> behaviour matched what most people want to do when showing a 4:3 image 
> on a 16:9 device

What do most people want to do in this situation?

Some (myself) approve of letterboxing.  Others prefer pan&scan.  What 
should POV do, that appeases both groups?

-- 
Chambers

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>   So my question stands: Why can't you do the exact same thing with a
> povray-generated image as you would do with a photo?
>


I have published products at zazzle.com where I have povray generate the white
border around the image. Some of these are 1:1, some are 2:1.  It soon becomes
a labor-saving device when you generate 100 of these products. Before you call
me petty, I've sold about a dozen of them.

If the docs were to empower someone to understand the camera, none of this
discussion would be necessary-- it wouldn't have been started by me! :)  The
docs fail because they don't teach someone how to create an object that
precisely covers the screen, regardless of pixel aspect ratio or camera angle.
Once I figured out how to do it, I wondered if it were a cleanly written
algorithm. 4:3 is the tripping point.

Again, I'd say let's step back from the issue of forcing the developers to go
rewrite povray.  One thing that troubles me in this discussion is the concept
that there are petty uses of povray, that povray is only for certain noble
tasks. Don't worry about anything that could also be done by mouse-dragging in
photoshop (like cropping to get certain aspect ratios-- imagine doing THAT for
a 2000-frame animation!!!)  Suppose I were able to find an animation contest
(didn't in 5 m of googling) that required non 4:3 aspect ratio.  Would you say
povray is not for professional animation contests?  When you critique a
critique of the current system, think BIG, not small.

Post a reply to this message

gregjohn wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>>   So my question stands: Why can't you do the exact same thing with a
>> povray-generated image as you would do with a photo?
>>
> 
> 
> I have published products at zazzle.com where I have povray generate the white
> border around the image. Some of these are 1:1, some are 2:1.  It soon becomes
> a labor-saving device when you generate 100 of these products. Before you call
> me petty, I've sold about a dozen of them.
> 
> If the docs were to empower someone to understand the camera, none of this
> discussion would be necessary-- it wouldn't have been started by me! :)  The
> docs fail because they don't teach someone how to create an object that
> precisely covers the screen, regardless of pixel aspect ratio or camera angle.
> Once I figured out how to do it, I wondered if it were a cleanly written
> algorithm. 4:3 is the tripping point.
> 
> One thing that troubles me in this discussion is the concept
> that there are petty uses of povray, that povray is only for certain noble
> tasks.

That has nothing to do with it.  It's not about the ultimate intended 
purpose of the image; its about making the image display correctly.

Changing the aspect ratio of an image can cause serious problems because 
of either cutting out portions of the image, or displaying objects / 
textures that weren't meant to be "on camera."

> Don't worry about anything that could also be done by mouse-dragging in
> photoshop (like cropping to get certain aspect ratios-- imagine doing THAT for
> a 2000-frame animation!!!)

It's not about what's easy to do in Photoshop; it's about what's easy to 
do, period.  In this case, adjusting an image for different aspect 
ratios has two possible solutions: Letterbox it (ie just leave it 
alone), or crop it (which is a solved problem when you use other tools 
like Photoshop or the GIMP).

-- 
Chambers

Post a reply to this message

> Alright then, let's ask this:
>
> What should the behavior be, when a scene is composed "without a second 
> thought for anyone else," and originally rendered in the default 4:3 
> aspect ratio... and you want to render it in a 3:4 aspect ratio for a 
> vertical poster?
>
> How should POV handle this?

IMO the default behaviour should be to preserve the horizontal FOV, as this 
is usually where the detail is modelled - more or less vertical FOV tends 
just to be more or less sky or emtpy ground.  So in your example the 3:4 
rendering would show more sky and ground (or whatever is in the image) than 
the original rendered at 4:3.

> Perhaps a sensible compromise would be that if only the width or height of 
> the file is set, and not the other, POV will assume square pixels and 
> adjust the other according to the camera aspect ratio.  That is, if you 
> set +w1600, and don't set height, POV will check the camera aspect ratio 
> (up and right vectors) and, in the case of the default 4:3, set +h1200 on 
> its own (and other values according to other ratios).  This would 
> certainly make scaling images easier.

So explain how you render a 3:4 version for a poster with your compromise?

Post a reply to this message

>> within POV or with some external tool).  If the default POV camera 
>> behaviour matched what most people want to do when showing a 4:3 image on 
>> a 16:9 device
>
> What do most people want to do in this situation?
>
> Some (myself) approve of letterboxing.  Others prefer pan&scan.  What 
> should POV do, that appeases both groups?

Assuming the scene file author has specifically written in the camera block 
that the aspect ratio should not be changed, then POV should give the person 
starting the render the choice of what to do from your choice - and an 
additional choice of changing the actual image resolution to match the 
aspect ratio fixed in the scene file.

Post a reply to this message

>> Of course you can, but it's usually by some contrived method
>
>  I wouldn't consider cropping an image "contrived", but whatever.

How do you work out what to type in for +w and +h to start with?  YOu need 
to go and find the correct camera block for the render, which is often not 
trivial for complex scenes due to multiple cameras being defined in 
different files.  Then you need to wait for the render, and start up a 
separate image editing program.  Is all that really necessary when you just 
want to put the image on your desktop?  It certainly seems unnecessary to 
me.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I'm sorry, but I just disagree with you. The original image composition
> should be preferred over anything else, unless the author *specifically*
> allows other aspect ratios to be used (which he can in the current POV-Ray).

To the contrary, I think that the default behavior should fit an "out of the
box" approach.

To this end, the default would have to fit scenes where *no* thought whatsoever
has been put into aspect ratio - neither from the author, nor from the person
rendering the scene. (Unfortunately, this is not the case.)

If an author has put enough thought into the aspect ratio issue to favor a
particular one, I think it is reasonable to expect from him to *explicitly*
specify this in the scene file in some way or the other.

Therefore, I advocate the original composition should be preferred *only* if the
author specifically *disallows* (or shall we rather say, disocurages) other
aspect ratios. Which, in current POV-Ray, he can do - though I'd agree that a
simpler mechanism to do so would be helpful.

The biggest issue in this area, however, is IMHO the fact that current POV-Ray
has no mechanism whatsoever to detect the difference between a mismatching
screen aspect ratio and a non-square pixel aspect ratio.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > No wonder POV is so slow to develop if you have to debate whether
> > using more meaningful keywords is a good thing or not :-(  Oh well.
>
>   Have you ever thought that adding new keywords can potentially break
> existing scenes? The SDL namespace is already heavily cluttered as it is.

Have you checked lately where we're discussing?

I guess POV 4 will break quite a lot of existing scenes anyway. Well, at least I
hope so, because I hope for a better SDL.

Post a reply to this message

>   If you have a 4:3 photograph and you want to fill your 16:9 screen with it,
> what do you do?
>
>   Why can't the same answer be applied to a 4:3 povray-generated image?

Yes, that's probably a sensible answer to the question for a default behavior:

- assume 1:1 pixel aspect ratio
- use a "virtual" field of view as specified in the scene file
- render only a subset of the image, so that it fits the specified output
resolution

Or, alternatively:

- assume 1:1 pixel aspect ratio
- reduce the field of view as needed to fit the specified output resolution


Note that the second approach is probably a bit easier to implement, but the
first one would be superior when it comes to preserving exact scene content, in
case the field of view is used as parameter to scene content creation.

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> Perhaps a sensible compromise would be that if only the width or height
> of the file is set, and not the other, POV will assume square pixels and
> adjust the other according to the camera aspect ratio.  That is, if you
> set +w1600, and don't set height, POV will check the camera aspect ratio
> (up and right vectors) and, in the case of the default 4:3, set +h1200
> on its own (and other values according to other ratios).  This would
> certainly make scaling images easier.

I'm repeating myself here, but I think what POV-Ray *really* lacks is a separate
option to explicitly specify the output image pixel aspect ratio.

From there on, the door would be wide open to all sorts of "automatic fixing" of
the residual aspect ratio issues.


Even your suggestion would not catch cases where a user may want to preserve the
original image's aspect ratio, but render for a different pixel aspect ratio.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> IMO the default behaviour should be to preserve the horizontal FOV, as this
> is usually where the detail is modelled - more or less vertical FOV tends
> just to be more or less sky or emtpy ground.  So in your example the 3:4
> rendering would show more sky and ground (or whatever is in the image) than
> the original rendered at 4:3.

As a matter of fact, I recently did a submission to the TC-RTC where this
approach would fail if the aspect ratio was significantly narrower than my
design: It includes grass "planted" all over the visible section of the ground,
with the algorithm requiring that the top edge of the shot is still below the
horizon.

Post a reply to this message

scott wrote:
>>> Of course you can, but it's usually by some contrived method
>>
>>  I wouldn't consider cropping an image "contrived", but whatever.
> 
> How do you work out what to type in for +w and +h to start with?  YOu 
> need to go and find the correct camera block for the render, which is 
> often not trivial for complex scenes due to multiple cameras being 
> defined in different files.  Then you need to wait for the render, and 
> start up a separate image editing program.  Is all that really necessary 
> when you just want to put the image on your desktop?  It certainly seems 
> unnecessary to me.

It is unnecessary.  If you just want to put the image on your desktop, 
all you have to do is right-click, and choose "Use as desktop."  Problem 
solved, POV isn't even necessary.

-- 
Chambers

Post a reply to this message