scott wrote:
>> If YOU specify a resolution with non-square pixels,
> 
> Sure, but at the moment you don't, POV just assumes you want non-square 
> pixels, which IMO is wrong most of the time.

?

How can you possibly mean that you don't specify the ratio?

Just about everyone specifies the exact image dimensions to use. 
Additionally, every scene has a specific aspect ratio (either explicit 
or implied).  If the ratio doesn't match, the only rational response by 
POV is to assume that the user input is correct, and that non-square 
pixels are desired.

-- 
Chambers

Post a reply to this message

>> Sure, but at the moment you don't, POV just assumes you want non-square 
>> pixels, which IMO is wrong most of the time.
>
> ?
>
> How can you possibly mean that you don't specify the ratio?

I specify an image aspect ratio, nowhere have I specifically said I want 
non-square pixels.  IMO you should specifically have to say you want 
non-square pixels, because it's not a common requirement.

> Just about everyone specifies the exact image dimensions to use.

Agreed.

> Additionally, every scene has a specific aspect ratio (either explicit or 
> implied).  If the ratio doesn't match,

SO you still expect me to trawl through all the scene files, looking for the 
camera block that is actually the active one, then calculate what image 
dimensions I should tell POV I want, just to get an image with square 
pixels?  That doesn't sound too ideal to me, *especially* when most of the 
time you do want square pixels.

Post a reply to this message

scott wrote:
> SO you still expect me to trawl through all the scene files, looking for 
> the camera block that is actually the active one, then calculate what 
> image dimensions I should tell POV I want, just to get an image with 
> square pixels?  That doesn't sound too ideal to me, *especially* when 
> most of the time you do want square pixels.

So you're saying that your major objection is that you don't want to 
look through the source code, right?

-- 
Chambers

Post a reply to this message

>> SO you still expect me to trawl through all the scene files, looking for 
>> the camera block that is actually the active one, then calculate what 
>> image dimensions I should tell POV I want, just to get an image with 
>> square pixels?  That doesn't sound too ideal to me, *especially* when 
>> most of the time you do want square pixels.
>
> So you're saying that your major objection is that you don't want to look 
> through the source code, right?

And then do a calculation to figure out what to tell POV, yes.  I've used 
enough 2D and 3D programs, and none works like this, it's completely 
counter-intuitive.  All programs I've seen automatically assume you are 
working with square pixels unless you specifically check or uncheck a 
certain option, IMO it should be the same for POV.

Post a reply to this message

scott wrote:
>> So you're saying that your major objection is that you don't want to 
>> look through the source code, right?
> 
> And then do a calculation to figure out what to tell POV, yes.

Fair enough.

Arguing that POV should be like other programs doesn't really convince 
me of anything, though, since POV distinctly *isn't* like other programs.

Anyway, back to the subject at hand.

POV has two sets of input: the scene itself (the scene file and any 
include files) in SDL, and INI options (given either in actual .ini 
files or on the command line).

Currently, the idea is that everything concerning the picture be 
contained within the scene, whereas everything concerning the output 
image be contained within the INI options.  The picture, including 
objects, textures, and even the camera, can not be modified from the INI 
options.

Currently, POV views the camera as part of the scene.  That's just how 
it works.

Now, what do you want to accomplish?

If you want to resize the image without changing the aspect ratio, then 
we have several options.
1) When the user specifies only one dimension, let POV compute the other 
assuming square pixels.
2) When POV parses the final camera block, display the image aspect 
ratio as part of the text output.
3) If the image aspect ratio does not match the camera aspect ratio, 
give a warning (but continue in case non-square pixels are desired).

If, on the other hand, you want to resize the image, and *change* the 
aspect ratio, I'd recommend that you actually read the scene files 
(because you need to know about the scene, what is present, and where it 
is placed).

-- 
Chambers

Post a reply to this message

> If, on the other hand, you want to resize the image, and *change* the 
> aspect ratio, I'd recommend that you actually read the scene files 
> (because you need to know about the scene, what is present, and where it 
> is placed).

I don't know about you, but I find it really hard to visualise what a scene 
will look like by just reading the scene files!  It's much easier to just 
look at a rendered version (either pre-rendered or I will render a quick 
preview myself).

Why not just have a flag/setting:

What should POV do if the requested image aspect does not match the scene 
aspect ratio?
[ ] Adjust image dimensions for letterbox result
[ ] Adjust image dimensions for zoomed/cropped result
[ ] Adjust camera horizontal FOV to match
[ ] Adjust camera vertical FOV to match
[ ] Render non-square pixels

Post a reply to this message

scott wrote:
> Why not just have a flag/setting:
> 
> What should POV do if the requested image aspect does not match the 
> scene aspect ratio?
> [ ] Adjust image dimensions for letterbox result
> [ ] Adjust image dimensions for zoomed/cropped result
> [ ] Adjust camera horizontal FOV to match
> [ ] Adjust camera vertical FOV to match
> [ ] Render non-square pixels

Actually, that's a pretty good idea.

-- 
Chambers

Post a reply to this message

gregjohn wrote:
> 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 don't see what the difficulty is. It's as simple as this:

camera
{
	location	<0,0,-4>
	direction	<0,0,+4>	// reciprocal of location
	up		y
	right		x*image_width/image_height
}

// polygon centered on the origin with sides of length 1
polygon
{
	4, <-1/2,-1/2>, <-1/2,+1/2>, <+1/2,+1/2>, <+1/2,-1/2>
	pigment {color Red}	
}

The trick here is to not use the angle and look_at keywords. In this 
case, they're more trouble than they're worth. Also, if you omit the 
image_width/image_height stuff, then it fills the viewport *exactly*, 
regardless of the aspect ratio.

-Mike

Post a reply to this message

SharkD schrieb:
> gregjohn wrote:
>> 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 don't see what the difficulty is. It's as simple as this:
> 
> ...
> 
> The trick here is to not use the angle and look_at keywords. In this 
> case, they're more trouble than they're worth. Also, if you omit the 
> image_width/image_height stuff, then it fills the viewport *exactly*, 
> regardless of the aspect ratio.

What you're doing is designing camera parameters so that a certain 
"friendly" box fills the entire screen.

The OP's challenge, however, was quite different: From a given arbitrary 
(potentially "unfriendly") camera perspective, compute parameters for a 
box to fill the screen (possibly to overlay a border, signature or 
whatever onto the image).

Post a reply to this message

"clipka" <ano### [at] anonymousorg> wrote in message 
news:4a80d86e$1@news.povray.org...
> SharkD schrieb:
>> gregjohn wrote:
>>> 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 don't see what the difficulty is. It's as simple as this:
>>
>> ...
>>
>> The trick here is to not use the angle and look_at keywords. In this 
>> case, they're more trouble than they're worth. Also, if you omit the 
>> image_width/image_height stuff, then it fills the viewport *exactly*, 
>> regardless of the aspect ratio.
>
> What you're doing is designing camera parameters so that a certain 
> "friendly" box fills the entire screen.
>
> The OP's challenge, however, was quite different: From a given arbitrary 
> (potentially "unfriendly") camera perspective, compute parameters for a 
> box to fill the screen (possibly to overlay a border, signature or 
> whatever onto the image).

isn't that exactly why screen.inc was made?

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message