POV-Ray : Newsgroups : povray.object-collection : 3D Loop Server Time
25 Sep 2021 07:55:37 EDT (-0400)
  3D Loop (Message 11 to 13 of 13)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: 3D Loop
Date: 26 May 2015 11:40:57
Message: <55649409$1@news.povray.org>
Am 25.05.2015 um 08:49 schrieb Le_Forgeron:

> Le 24/05/2015 22:08, Lars Rohwedder a écrit :
[...]
>> That was _not_ my question. I asked when 16:9 will become the
>> _default_ in Povray so such scaling of the right vector becomes
>> unnecessary. oO
>>
>> Lars R.
>>
> Unnecessary for you... my screen are 1920x1200, I would need 16:10.
>
> Changing the default right vector (even to something like
> image_width:image_height ratio, assuming square pixel everywhere)
> would only have one sure effect: break every historical scenes.
> Without providing 100% satisfaction to all users. Better not move.

I totally agree - except when it comes to defaulting to square pixels, 
which /does/ make sense nowadays; after all, that's what any reasonable 
image handling software defaults to as well if the input image material 
provides no embedded resolution information.


> And guess what: 4K screens are coming... and there is at least 5
> different resolution under the name 4K, none with exactly the same ratio
> ..
>
> So far:
>
>   * 4096 x 2160 ( 256:135) [DCI native]
>   * 3840 x 2160 ( 16:9 ) [UHD-1]
>   * 5120 x 2160 ( 21:9 ) [UWT]
>   * 5120 x 3200 ( 16:10 ) [WHXGA]
>   * 4096 x 1716 ( 2.39: 1 ) [DCI cinemascope cropped]
>   * 3996 x 2160 ( 1.85: 1 ) [DCI flat cropped]

(Um... that looks more like 8K to me... or am I missing something?)

It might be worth noting that of all those aspect ratios, 16:10 is 
closest to the famous Golden Ratio (1.618...:1), which has been 
considered an aesthetically superior ratio for literally thousands of years.


Post a reply to this message

From: Le Forgeron
Subject: Re: 3D Loop
Date: 26 May 2015 11:53:57
Message: <55649715$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 26/05/2015 17:41, clipka a écrit :
> Am 25.05.2015 um 08:49 schrieb Le_Forgeron:
> 
>> Le 24/05/2015 22:08, Lars Rohwedder a écrit :
> [...]
>>> That was _not_ my question. I asked when 16:9 will become the 
>>> _default_ in Povray so such scaling of the right vector
>>> becomes unnecessary. oO
>>> 
>>> Lars R.
>>> 
>> Unnecessary for you... my screen are 1920x1200, I would need
>> 16:10.
>> 
>> Changing the default right vector (even to something like 
>> image_width:image_height ratio, assuming square pixel
>> everywhere) would only have one sure effect: break every
>> historical scenes. Without providing 100% satisfaction to all
>> users. Better not move.
> 
> I totally agree - except when it comes to defaulting to square
> pixels, which /does/ make sense nowadays; after all, that's what
> any reasonable image handling software defaults to as well if the
> input image material provides no embedded resolution information.
> 

Yep... until you want to make a DVD (none of NTSC and PAL have square
pixels...)

> 
>> And guess what: 4K screens are coming... and there is at least 5 
>> different resolution under the name 4K, none with exactly the
>> same ratio ..
>> 
>> So far:
>> 
>> * 4096 x 2160 ( 256:135) [DCI native] * 3840 x 2160 ( 16:9 )
>> [UHD-1] * 5120 x 2160 ( 21:9 ) [UWT] * 5120 x 3200 ( 16:10 )
>> [WHXGA] * 4096 x 1716 ( 2.39: 1 ) [DCI cinemascope cropped] *
>> 3996 x 2160 ( 1.85: 1 ) [DCI flat cropped]
> 
> (Um... that looks more like 8K to me... or am I missing
> something?)

4K is about the width.
To be compared to camera sensor which are sold by millions of pixels
(2 millions... 10 millions... 40 millions... none advertising
aspect-ratio): marketing is all about getting people confused...
especially after selling TV screen as 720i, 720p, 1080p... where it
was the height, not the width... a delight of confusion.

8K varies from 7680 to 10080 pixels for width.

> 
> It might be worth noting that of all those aspect ratios, 16:10 is 
> closest to the famous Golden Ratio (1.618...:1), which has been 
> considered an aesthetically superior ratio for literally thousands
> of years.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlVklxcACgkQhKAm8mTpkW1yBAQA1ROThtqNUg/83u6qzY0SXuA4
eTy8RFJSwiAKgJ78+TafHlXZ9286aMKMZy6iG7WLqy5SOyvH/fwlmkM1cCZ+t73y
K9EFe7K+8SXts9/qpJ5Fr/EAS290iD1B3ZJ+N05e/nDJwg5ot9eB5iMOxirmcdrI
RP95Rx6MLwgZauFVOOg=
=lWmQ
-----END PGP SIGNATURE-----


Post a reply to this message

From: clipka
Subject: Re: 3D Loop
Date: 26 May 2015 12:20:04
Message: <55649d34$1@news.povray.org>
Am 26.05.2015 um 17:53 schrieb Le_Forgeron:

>>> Changing the default right vector (even to something like
>>> image_width:image_height ratio, assuming square pixel
>>> everywhere) would only have one sure effect: break every
>>> historical scenes. Without providing 100% satisfaction to all
>>> users. Better not move.
>>
>> I totally agree - except when it comes to defaulting to square
>> pixels, which /does/ make sense nowadays; after all, that's what
>> any reasonable image handling software defaults to as well if the
>> input image material provides no embedded resolution information.
>>
>
> Yep... until you want to make a DVD (none of NTSC and PAL have square
> pixels...)

(Actually NTSC and PAL don't have any pixels at all; they just have 
contiguous scan lines with a specified maximum signal frequency. But I 
guess you're right about NTSC/PAL compatible DVD content. ;))

Even so, I'd expect that even contemporary professional or 
semi-professional video editing software will presume input images to 
have square pixels - unless explicitly told otherwise by the image 
header, the user, or the software administrator.

Also, when you export a PAL or NTSC DVD movie sequence as a series of 
images, I'd expect any sane video handling software to write them in a 
square-pixel format, even when additional resolution information is 
written to the image header. (Again, unless told otherwise of course)


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

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