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

William F Pokorny <ano### [at] anonymousorg> 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