|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bryan Heit <bjh### [at] nospamucalgaryca> wrote:
>> As I said, it's whats in the documentation, but it doesn't seem to work
>> out that way.
>
> Rest assured that if it didn't work that way, I would have noticed.
> After all, I have written things like this:
>
> http://tag.povray.org/povQandT/languageQandT.html#aspectratio
>
>> Solved that issue. Image looks identical on the computer screen,
>> compared to the one rendered above, but does not get distorted when
>> exported to DVD.
>
> Which image format did you use? OTOH, I don't understand why that
> would make any difference.
I couldn't find my disks with my older material on it, but I did render
a few cubes to demonstrate the effect. As soon as I have time I'll put
them up somewhere.
Any how, I've been playing around with this and I think I know what it
going on. It appears to be a problem with how povray is writing (or not
writing) the aspect ratio to the BMP's header, plus how my video editing
software seems to handle BMPs.
If I render in PNG (or targa), rather than BMP, I don't have this
problem. I looked up the difference in how bmp vs. PNG store aspect
ratio, and they're different. I suspect that my video editing software
simply is not handling the BMP method of storing aspect ratio correctly.
Why entering the aspect ratio manually fixes this I don't know.
Bryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Heit <bjh### [at] nospamucalgaryca> wrote:
> Why entering the aspect ratio manually fixes this I don't know.
If you can make sure this is a problem with POV-Ray, then this is a
very valid bug report which should be made.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Heit <bjh### [at] NOSPAMucalgaryca> wrote:
>
> Any how, I've been playing around with this and I think I know what it
> going on. It appears to be a problem with how povray is writing (or not
> writing) the aspect ratio to the BMP's header, plus how my video editing
> software seems to handle BMPs.
>
> Bryan
As far as I know, BMPs don't have an 'aspect ratio' field on their headers.
Only image size in pixels.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Bryan Heit <bjh### [at] NOSPAMucalgaryca> wrote:
>> Any how, I've been playing around with this and I think I know what it
>> going on. It appears to be a problem with how povray is writing (or not
>> writing) the aspect ratio to the BMP's header, plus how my video editing
>> software seems to handle BMPs.
>>
>> Bryan
> As far as I know, BMPs don't have an 'aspect ratio' field on their headers.
> Only image size in pixels.
They don't have a specific aspect ratio entry per se. Rather, they have
4 "size" entries - 2 which are the x and y size in pixels, and 2 which
are the x and y size in units of measure (mm, inches, cm, or something).
You can calculate the aspect ratio from the second set of "size"
measures.
Unfortunately, I haven't found a good reader for the header, so I
haven't been able to determine exactly what's going on - there is a
difference if you use povray's default aspect ration compared to
assigning it yourself [as right x*(4/3)]. Assuming I counted the bytes
right, this difference is in the second set of size measures for the
image. If I had to guess, povray probably assigns integer values (i.e.
x = 4 units, y = 3 units) when you use the default aspect ratio, but
stores the decimal values (i.e. x = 1.33333 units, y = 1 unit) when you
enter the aspect ratio manually.
As far as I can tell the problem I was having was due entirely to the
program I was using for converting the bmp's to avi (VirtualDub). Using
other image formats (i.e. PNG) solved the problem, and updating to the
newest version of virtualdub also fixed the problem; regardless of how I
assigned the aspect ratio to the images.
Bryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Heit <bjh### [at] nospamucalgaryca> wrote:
> If I had to guess, povray probably assigns integer values (i.e.
> x = 4 units, y = 3 units) when you use the default aspect ratio, but
> stores the decimal values (i.e. x = 1.33333 units, y = 1 unit) when you
> enter the aspect ratio manually.
That can't be. POV-Ray calculates the result of "4/3" before it does
anything with that value.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bryan Heit <bjh### [at] nospamucalgaryca> wrote:
>> If I had to guess, povray probably assigns integer values (i.e.
>> x = 4 units, y = 3 units) when you use the default aspect ratio, but
>> stores the decimal values (i.e. x = 1.33333 units, y = 1 unit) when you
>> enter the aspect ratio manually.
>
> That can't be. POV-Ray calculates the result of "4/3" before it does
> anything with that value.
>
It was a guess on my part, but I think I wasn't clear in my description.
There is a difference in the bmp headers if you add "right x*(4/3)"
to the camera code vs the "default" header you get when you don't
declare "right". The difference appears to be in the part of the BMP
header which sets the physical size of the file. Without a proper
header reader I cannot tell exactly what is going on.
What I suspect is going on is that povray may enter the x&y size of the
image to be 4 and 3 when the right statement is not added to the camera
(BMP's don't store aspect ratios, but rather store the x and y size of
the picture in units of length [mm, cm, or something]). But I suspect
that when you enter the "right" code into the camera povray calculates
the 1.333, and enters that as the physical side (i.e. x=1.333, y=1).
Either should give the proper aspect ratio, but as I mentioned, the
older version of the software I was using did not read the default
povray aspect ratio properly.
The main thing here is that it was my software, not povray, making the
mistake. Long story short - if you're going to use virtualdub to
convert your bmp's to avi's, make sure you get a version newer then 1.1.
Bryan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Heit <bjh### [at] nospamucalgaryca> wrote:
> There is a difference in the bmp headers if you add "right x*(4/3)"
> to the camera code vs the "default" header you get when you don't
> declare "right".
If you can create a full report of this, it might be worth posting for
review.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|