Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th January 2021, 21:20   #1  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 412
Confounded by YUV<->RGB Conversaion

What the devil is going on here...



I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?
wswartzendruber is offline   Reply With Quote
Old 17th January 2021, 22:23   #2  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
I would follow the original ITU-R BT.601-7 and ITU-R BT.709-6 specification rather than one of its many interpretations. Perhaps it helps to clarify your questions.
There are some doubts and questions about this article in its 'talk' page by the way .....

Last edited by Sharc; 18th January 2021 at 16:13.
Sharc is offline   Reply With Quote
Old 17th January 2021, 23:28   #3  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 412
I would like to convert from linear, full-range YCbCr to linear, full-range RGB....and back.
wswartzendruber is offline   Reply With Quote
Old 17th January 2021, 23:50   #4  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
You may find the answer here:
http://poynton.ca/notes/colour_and_g....html#RTFToC18
see also para. 7. .... 12.

https://web.archive.org/web/20120403...onversion.html
http://poynton.ca/notes/colour_and_gamma/GammaFAQ.html

Last edited by Sharc; 18th January 2021 at 15:41.
Sharc is offline   Reply With Quote
Old 18th January 2021, 16:42   #5  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 2,309
Have you checked if you can use my avs plugin here for doing what you want ? (Maybe also check zimg).
I've also added a pdf document to try to explain the linear/non-linear part in my plugin.
__________________
My github.
jpsdr is offline   Reply With Quote
Old 25th March 2021, 10:28   #6  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
Quote:
Originally Posted by wswartzendruber View Post
What the devil is going on here...



I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?
Perhaps the answer is given here:
http://poynton.ca/papers/SMPTE_98_YYZ_Luma/index.html
Quote:
Since 1953, we have been using the wrong block diagram for color video! The principles of color science dictate that we mix linear RGB to make true luminance, denoted Y. This is known as the Principle of Constant Luminance. But in video we depart from that principle, and implement an engineering approximation: We mix nonlinear ("gamma corrected") R'G'B' to make what I call luma, denoted Y'. (Many video engineers carelessly call this luminance.) To form luma, we use the theoretical coefficients of color science, but we use them in the wrong block diagram: We apply gamma correction before the mixing, instead of after. This alteration in the block diagram is more or less inconsequential in practice, though the departure from theory is apparent in the dark band seen between the green and magenta color bars of the standard video test pattern.
Sharc is offline   Reply With Quote
Old 26th March 2021, 03:26   #7  |  Link
wswartzendruber
hlg-tools Maintainer
 
wswartzendruber's Avatar
 
Join Date: Feb 2008
Posts: 412
I ended up assuming that the HOWTO on Wikipedia was irrational. I wrote my own method for RGB->YCbCr using strictly linear light. From that, I then refined an inverse of YCbCr->RGB.

https://github.com/wswartzendruber/p...mod/src/rgb.rs

Note that my bt1886_oetf function there should really be bt1886_ieotf.
wswartzendruber is offline   Reply With Quote
Old 12th September 2021, 21:42   #8  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Quote:
Originally Posted by Sharc View Post
Perhaps the answer is given here:
http://poynton.ca/papers/SMPTE_98_YYZ_Luma/index.html
we have been using the wrong block diagram for color video!
With unlimited precision (and zero noise) it looks it no matter where to put TF-domain compression device - before linear matrix or after. The RGB linear data channels are also not pure natural datasource but the integration of natural scene spectrum via pass-band filters.
The bad things happens when processing of different outputs of YUV matrix performed in different frequency bands paths (like sub-sampled chroma to 4:2:2 or 2:0 or 1:1 etc). To completely reverse operations the equal data channels required.

It is shadows from the poor old days when frequency spectrum and bitspeeds where very limited and engineers designed lots of compression stages to moving pictures data - interlace, gamma, chroma subsampling and mpeg. But not all of compression stages are fully-reversible. From modern systems interlace is mostly killed and I think the chroma subsampling need to be killed too. Though it makes less visible distortions in compare with interlace scan and mostly at the
transients of very saturated colours that is rare at natural scenes.
DTL is offline   Reply With Quote
Old 24th September 2021, 18:10   #9  |  Link
Balling
Registered User
 
Join Date: Feb 2020
Posts: 539
Quote:
Originally Posted by wswartzendruber View Post
What the devil is going on here...



I took that from Wikipedia. The article it's from specifically states that Y is linear light and that Y' is gamma-corrected, perceptual light. It also states specifically that RGB is linear light.

So how in blue blazes do you get a gamma-corrected Y' value for output when taking linear-light values in as input...using nothing but multiplication?
I added those there. There is no evidence those were ever used by ATSC. Ever. And there is talk page info there. https://en.wikipedia.org/wiki/Talk:Y...scaled_BT.709?

Those are using analog Y'U'V', NOT Y'Cb'Cr'!! Nobody needs it no longer. This is just for historical info. The BT.709 /BT.2020 matricies and inverses are in YCbCr article (also added by me).

As for how. This is just a typo, though linear RGB were also in use in russian SECAM IV, but then you get linear YUV. Fixed.

About linear RGB is also just a typo, long since removed.

Last edited by Balling; 24th September 2021 at 18:41.
Balling is offline   Reply With Quote
Old 25th September 2021, 00:15   #10  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
'the dark band seen between the green and magenta color bars of the standard video test pattern'

The old and current ITU motion pictures imaging systems do have build-in bugs for colour imaging but they are expected to be rarely seen because of:
1. Natural imaging rarely have saturated colours.
2. If ever saturated colours happens - they much more rare close to each and form high saturated colour transient.
So colour bars test pattern is sort of never-happen in reality image. Just sad bug for colour imaging systems of old days and todays.

Unfortunately the designers of synthetic images are not knows these limitations so typical broadcast 4:2:0 TV are highly loaded with top-saturated advertisements and clips and shows and displays these bugs.
DTL is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.