![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 2/26/23 12:32, Kenneth wrote:
> There is something about the REC 709 standard that has confused me for quite
> awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> standard for video capture and display, so I'm not sure that I understand how it
> relates to color -> grayscale conversion within your povr branch (as for
> height_field use.)
Sure I'm not the one to answer your questions in any definitive way, but...
Firstly, I focused on the color to greyscale / luminosity / height
conversion while looking at the standards for my supported povr
conversions. Further, I had a head start in that Christoph had dug some
into these already the some of the new conversions already existed in
the code for image input and output, if not the in code greyscale
conversion itself. He and others had talked about 709 being a better
color to grey for v3.8 defaults in the newsgroups.
---
That said. I think the difference being talked about in the 709 vs
'709-R' is likely the fact most LCD based displays cannot reach the
extremes for darkness and brightness and this is probably what the
'709-R' you see is about. This I think more true of darkness - lcd
displays simply fail for dark values because ultimately you need to turn
off each pixel for true black.
While I am NOT an expert at animation encoding tools, I do not think you
will see much if any real difference in what gets displayed between 709
and 709-R. The reality is when when code a black value of 0.0 in a still
image or animation frame, we mostly do NOT get a 0 pixel value, but
something brighter.
So... What I suspect is encoding to an animation with '709-R' will
compress better because fewer overall values are being represented. In
other words the 'R' is a compression which accepts the typical reality
of today's displays while pure 709 is optimistic that some few folks
have displays that can actually do something closer to the extremes.
On the bright side (of displays), I'm less sure 'R' is the reality as I
think some display can get quite bright (true too cheap ones can be
dim). Some newer LCD displays at least can occasionally go completely
dark by region, if not by pixel. There are fancy and pricey displays out
there too, but most don't have them.
So! All this mostly me guessing - there is probably wiki/web info out
there, but I didn't read up on anything on answering here.
If someone really knows better - feel free to jump in and correct as
need be.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> wrote:
> On 2/26/23 12:32, Kenneth wrote:
> > There is something about the REC 709 standard that has confused me for quite
> > awhile, in a general way. (I'm probably going off-topic here). AFAIU, it is a
> > standard for video capture and display, so I'm not sure that I understand
> > how it relates to color -> grayscale conversion within your povr branch (as
> > for height_field use.)
>
> Sure I'm not the one to answer your questions in any definitive way, but...
>
Your comments are actually quite helpful and informative, thanks!
I probably should have qualified my earlier statement about seeing different
animation results re: using 'plain' REC 709 vs. 709-R:
It seems to depend on which video app I use to play-back the finished video.
IIRC!
I have not done a definitive series of tests lately. Once I saw that 709-R
'looked' better and matched my POV-ray image render previews within POV-ray, I
stuck with it. This is yet another of those situations where I got side-tracked
from working on a scene, and didn't pursue the problem as far as I would have
liked to.
I could probably spend 23 1/2 hrs per day just doing detailed and pedantic tests
of one kind or another! (Lately, it seems that I am, ha.)
-----
BTW, I am *still* chasing-down that height_field 'mirror reversal' thing when
using functions. Just today, I discovered yet another little interesting
behavioral quirk. I will probably post it in the earlier/recent thread about
"functions to height_fields", as it seems more appropriate there.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |