POV-Ray : Newsgroups : povray.pov4.discussion.general : New camera, or new camera docs illustrations. Server Time
8 Dec 2024 07:21:27 EST (-0500)
  New camera, or new camera docs illustrations. (Message 64 to 73 of 73)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Chambers
Subject: Re: New camera, or new camera docs illustrations.
Date: 28 Jun 2009 03:27:18
Message: <4a471b56$1@news.povray.org>
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

From: scott
Subject: Re: New camera, or new camera docs illustrations.
Date: 29 Jun 2009 06:11:36
Message: <4a489358@news.povray.org>
>> 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

From: Chambers
Subject: Re: New camera, or new camera docs illustrations.
Date: 30 Jun 2009 03:15:57
Message: <4a49bbad$1@news.povray.org>
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

From: scott
Subject: Re: New camera, or new camera docs illustrations.
Date: 30 Jun 2009 05:46:34
Message: <4a49defa@news.povray.org>
>> 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

From: Chambers
Subject: Re: New camera, or new camera docs illustrations.
Date: 30 Jun 2009 21:52:01
Message: <4a4ac141$1@news.povray.org>
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

From: scott
Subject: Re: New camera, or new camera docs illustrations.
Date: 1 Jul 2009 05:49:09
Message: <4a4b3115@news.povray.org>
> 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

From: Chambers
Subject: Re: New camera, or new camera docs illustrations.
Date: 1 Jul 2009 23:18:57
Message: <4a4c2721@news.povray.org>
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

From: SharkD
Subject: Re: New camera, or new camera docs illustrations.
Date: 10 Aug 2009 17:04:15
Message: <4a808b4f@news.povray.org>
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

From: clipka
Subject: Re: New camera, or new camera docs illustrations.
Date: 10 Aug 2009 22:33:18
Message: <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).


Post a reply to this message

From: Zeger Knaepen
Subject: Re: New camera, or new camera docs illustrations.
Date: 11 Aug 2009 04:29:22
Message: <4a812be2$1@news.povray.org>
"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

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.