'y' in YRGB?

It was really to satisfy myself that there were no biases in the FFMPEG SSIM and PSNR test system. When I have a moment, and I don't today, I'll have a look at cycling YUV -> RGB -> YUV with AVISynth+

That would be great!

I only work with Vapoursynth which has float conversion functions, I assume AviSynth has float conversions as well.

Well AVISynth+ supports..

http://avisynth.nl/index.php/Convert

And there's support for the z.lib resize libaries also. But I can't say I have experience in high bit-depth YUV <-> RGB inter-conversions with AVS+.

Andrew, I'm sure, is well clued up in this domain. Maybe others too - Micha? If someone would like to come-up a valid AVS+ script for testing with that sample Uncomp.10-bit 422 AVI clip, I'll be happy to run the tests and SSIM/PSNR analysis. Otherwise, it's something I'd have to research and get my head around.

I had a short lived foray into VapourSynth on linux. Windows side though I'm still more comfortable with AVISynth(+).

Which left me pondering whether the Y component in Resolve's colour tools does actually represent derived luma - that is to say, gamma-adjusted luminance. After further reading though, I wonder if 'Relative Luminance' more accurately describes what Y represents in this context ?

One thing you can ponder is that the Lift/Gamma/Gain controls and the RGB Mixer each have a "Lum Mix" or "Preserve Luminance" mode, which you can bypass (or turn down to 0). This yields different results by not compensating for the luminance with a specific hue balance adjustment. You can think of Y as the contrast signal, but I generally think of it as Luminance.

I think it's kind of a semantic argument in that wherever the Luma component comes from, you can adjust it separately from Chroma or you can adjust them both together. They each yield different effects. There are good reasons to use one method or the other, and sometimes just one specifically. The manual gets into some of this.

Good stuff there..


ResolveStudio 14.3...014 | MiniMonitor | DTV 10.9.7 | Win8.1 x64 | ROG G751JL, 2.8GHz Intel i7HQ, 24GB DDR4, 1TB HD, 500GB EVO 850, 2GB GTX965M | Mackie MCU Pro | Softube Console 1 Mkii | Shuttle Pro 2 | more...

I'm familiar with all of that. No need for the sarcasm and condescension.

your sarcasm and condescension detectors are way off...

I must concede and heartily assert that this instance of Marc's response serves as one of the marked (no pun) examples of Sir Weilage not coming off as though he's communicating from a lofty, elitist perch, and I wholly applaud him for the congenial choice of wording in his rather soberminded, and useful reply.
[Re]Pete

ResolveStudio 14.3...014 | MiniMonitor | DTV 10.9.7 | Win8.1 x64 | ROG G751JL, 2.8GHz Intel i7HQ, 24GB DDR4, 1TB HD, 500GB EVO 850, 2GB GTX965M | Mackie MCU Pro | Softube Console 1 Mkii | Shuttle Pro 2 | more...

RGB has all needed info, as Hendrik said, so this Resolve's Y is just just duplicated (calculated/made up) info to help better control "luminance" while working with RGB.

Hendrik, Andrew, Marc et al -- you Guys are amazing.

ResolveStudio 14.3...014 | MiniMonitor | DTV 10.9.7 | Win8.1 x64 | ROG G751JL, 2.8GHz Intel i7HQ, 24GB DDR4, 1TB HD, 500GB EVO 850, 2GB GTX965M | Mackie MCU Pro | Softube Console 1 Mkii | Shuttle Pro 2 | more...

Well AVISynth+ supports..

http://avisynth.nl/index.php/Convert

And there's support for the z.lib resize libaries also. But I can't say I have experience in high bit-depth YUV <-> RGB inter-conversions with AVS+.

Andrew, I'm sure, is well clued up in this domain. Maybe others too - Micha? If someone would like to come-up a valid AVS+ script for testing with that sample Uncomp.10-bit 422 AVI clip, I'll be happy to run the tests and SSIM/PSNR analysis. Otherwise, it's something I'd have to research and get my head around.

I had a short lived foray into VapourSynth on linux. Windows side though I'm still more comfortable with AVISynth(+).

I'll do it when I have time but with vapoursynth. I done some test with avs old days and with (if I remember well) 8 taps sinc scaler I had 80dB+ after 1st gen, but on all channels.
I'll also test with Scratch as it also goes over RGB and uses GPU.

RGB has all needed info

Scene-related, camera original / defined as "True."

This would also be correct if the tristimulus could be processed as a single-string value with no power-related inferences. If that was correct, you could make linear mathematical operations as *color corrections* and expect straight-line outcomes, but that is not what is observed.

As commented on elsewhere, proportional response in human vision is logarithmic (just like hearing) and this is compounded by the technical constraints of presentation technology. This is why we have to keep re-evaluating values of gamma for Y' weighting when using a color-difference distribution scheme.

In whole numbers, the backwards-compatible black & white RS-170 value of luminance is written-in-stone as roughly 70/20/10 Green, Red, Blue. These were empirically derived (CIE1931) and recently re-checked. The human eyeball detects green as higher intensity, while Blue is a significant source of noise in electrical transducers and longitudinal aberration in lens optics. Happily it is typically also interpreted as "darker", so we don't really need it to be as significant as a total contributor to overall luminance.

When referred to as a "string" value, while it is theoretically correct that any color can be defined with three components - because we need to know how bright it is, what hue it is and how intense that hue is -- HSL -- GRB -- YCbCr -- YUV -- YIQ -- whatever you want to use, these are (as Micha starts to illustrate) computed values. But they also have vector relationships. They are not simple numerical string values, like hexadecimal HTML code, they are matrix derivations. Where most practitioners lose the plot is that as colorists we are presented with a control panel that seems to behave linearly, but what is going on under the keys is a completely different set of operations hiding a ridiculously complex algorithm.

While people see and hear logarithmically, we don't think that way. It's not about numeracy and basic intellect, it's just that intuitively we think 1 + 1 should equal "2", but in Nature, it's "10". Not just binary, but in the case of audio for example, things actually have to be 10x louder numerically in order for us to hear them as "twice" as loud. That's just how it is.

These are power functions expressed as matrices in three dimensions. When you get into color cubes, adjusted for gamma (display referenced) you can see that linearly adjusting Red, Green and Blue with linear coefficients is not going to cut it. Pushing your RGB circles "this much" "that way" only gives you an expected result because it is compensating for the power function in the background

Finally, YRGB is a daVinci invention -- small-d daVinci, not BlackMagic Resolve, although it has come to be that. The Classic, Renaissance, 8:8:8, 2K, etc., et al., were the first constant-luminance correctors
that allowed operators to run amok with RGB controls without upsetting the brightness/contrast impression of an image but enabled tint and gray-scale adjustments with no apparent penalties.

That is the advantage of Y-only. It's how I learned in 1994 and haven't seen enough counter-argument to convince me to change that approach.

jPo, CSI

Impressive instruction and commentary, JP, Mika and others contributing here.

ResolveStudio 14.3...014 | MiniMonitor | DTV 10.9.7 | Win8.1 x64 | ROG G751JL, 2.8GHz Intel i7HQ, 24GB DDR4, 1TB HD, 500GB EVO 850, 2GB GTX965M | Mackie MCU Pro | Softube Console 1 Mkii | Shuttle Pro 2 | more...

I'm familiar with all of that. No need for the sarcasm and condescension.

your sarcasm and condescension detectors are way off...

I must concede and heartily assert that this instance of Marc's response serves as one of the marked (no pun) examples of Sir Weilage not coming off as though he's communicating from a lofty, elitist perch, and I wholly applaud him for the congenial choice of wording in his rather soberminded, and useful reply.
[Re]Pete

Good grief. I was the recipient and I think I should be free to express how it came across at the time. Marc came back to clarify no sarcasm or condescension intended which is fine by me. The matter is closed. By all means commend him for the wisdom imparted, but please spare me the condemnation. Now can we move on please.

I'll do it when I have time but with vapoursynth. I done some test with avs old days and with (if I remember well) 8 taps sinc scaler I had 80dB+ after 1st gen, but on all channels.
I'll also test with Scratch as it also goes over RGB and uses GPU.

Great. Just wondering where the above test findings leave us though. Is this something that should be formally flagged for BMD's attention as suggestive of a chroma sampling bug or left as an incidental observation to 'make of what one will' ?

I'm sure they read it

There are some "torture test" test patterns out there that will break all kinds of signal processing situations.

Good old colour bars will do it, you don't even need anything much fancier. NTSC broadcast bars with the blueish I/Q patches that used to fill the 100% white split-field quadrant cannot be reproduced in RGB.

Bear in mind that RGB and color-difference formats Y'CbCr, YUV, YIQ and so on can carry values that are invalid plus sub-sampled with respect to other formats, which can poison-pill any test. One contributor here wrote about:

If luminance is zero, chroma values don't mean anything anymore,

which is correct in the sense that the image won't be understood by an observer -- but the color information doesn't go away, either. And some systems can support negative values, which RGB certainly cannot.

https://www.pcmag.com/encyclopedia/term/55165/yuv

The reason we have color-difference is bandwidth. Television broadcast channel allocations were set up in the VHF band to accommodate roughly 5 or 6 MHz plus guard-band (Standard Def NTSC and PAL) which was phased out in favour of digital broadcast and no longer exists. However, a full-bandwidth RGB broadcast would have required about 3 or 4 times the bandwidth for each channel, so the ingenious solution was to matrix the RGB as Luminance and color-difference. NTSC has a wacky relationship, YIQ, (Luminance, In-phase, Quadrature) while PAL (Perfection At Last) used YUV. In both cases Y luminance has the same component structure. IQ and UV are derived differently, but the winner (as adopted by Component Analog Systems such as BetaCam and MII, and all subsequent tape formats) was YUV, because the color-difference components are a simple mathematical relationship between Luminance and the Red and Blue channels, R minus Y (R-Y) and B minus Y (B-Y). The true genius of the component chroma system is that chromatic detail is not as important in human vision as greyscale. So both NTSC and PAL filtered and bandwidth-limited chroma bandwidth accordingly -- by as much as two-thirds. In NTSC particularly, In-phase (roughly Red/Cyan) was limited to 1.5 MHz, and Q (Magenta/Green) to 0.5 MHz. Suppressed-subcarrier interleaved modulation allowed three channels of picture information plus audio to go into the space of one. This is to a certain extent how we can get away with 4:2:2 (and 4:2:0) sampling where the arbitrarily nominal factor of "4" describes full bandwidth and "2" describes a discrete sample size of half that frequency. The original daVinci used 8:8:8 to define an over-sampling strategy of twice the normal rate. This is related to a fundamental sampling frequency principle known as the Nyquist Criterion. Over-simplified it states that any harmonically related signal, sampled at twice its highest resident frequency component, can be perfectly re-constituted. Sampled systems become susceptible to cross-talk and other forms of interference if the Nyquist threshold is violated.

You also get degradation in format conversions if the values generated in one system don't exist or cannot be computed in others. For example, you can have negative values in YUV, but you can't in RGB.

jPo, CSI

Round tripping degradation in Resolve sounds like 422>444>422 up- and downsampling related problem, as Andrew suggested. But I'm not sure there is much to do about it without adding either some smartness to image processing pipeline that detects resampling and switches algorithms to ones that are 100% invertible (impulse should do it) or allowing user to manually select chroma up- and downsampling filters.

@bryan
could you please post a pair of lossless compressed frames from the first and last generation of your test, which are significant affected by this issue.

i would really like to analyze the difference. i'm not sure, if it is really a color subsampling related issue?
the unequal distribution of the errors in your histograms would prompt a few other explanations as well.

jPo, thanks for the clarity of post #60 among others here. Much of this thread reads like a skit from Monty Python to someone who is woefully uninformed, so I appreciate how intelligible your posts are.


Sent from my iPhone using Tapatalk

@bryan
could you please post a pair of lossless compressed frames from the first and last generation of your test, which are significant affected by this issue.

Not sure if by 'first' you mean the original source or first generation re-encode, but here they are:

Original Uncomp. 10-bit 422 AVI:


First gen re-encode:


Tenth gen re-encode:


These are the same frame represented in the scope shots I posted above.

Once opened in Imgur, click on the (+) cursor to view at original res and right click to Copy or Save As.

This is all super interesting but as a beginner I can't really understand anything beyond 'y is luminance minus chroma, but even this is confusing, as this to me suggests y just changed the brightness of everything in the image, which would surely include R, G, and B equally, the same as the wheel below primaries bars. Ok, I think I get that it weights them differently, but why? These answers seem to tell me that resolve weights R, G, and B differently anyway to match human vision / compensate, so that even when you adjust them equally they are not 'purely' equal...Any fools' guide would be appreciated!

@marcusfrewinridley - sorry the thread veered off into a debate/discourse on YUV vs RGB, but something significant came out of it along the way. Hope you got the answer(s) you were looking for ?

vapoursynth numbers are way better. Using 16bit int (not even float math) and lanczos3 resize for Y and point resize for UV:
1st gen - PSNR y:100.59 u:97.15 v:110.67
10th gen- PSNR y:87.22 u:97.08 v:110.67

Strange that Y has biggest lost and v actually stays the same, but this is probably due to use of point resize on chroma (which is suggested method by devs).

Using lanczos3 on all channels gives different behaviour:
1st gen- PSNR y:105.09 u:72.44 v:74.58
10th gen- PSNR y:99.61 u:71.69 v:73.23

Regardless of used method those numbers are miles better than Resolve and more what I would expect. All can be treated as "lossless" in real world usage.

Using simple Bilinear resize:
1st gen- PSNR y:106.64 u:61.87 v:64.41
10th gen- PSNR y:100.53 u:59.80 v:60.02

shows much worse values for chroma. No idea what Resolve does as results are really poor.

Hello,

Is it really surprising how the reds are 'shifted' and not the other colors?
(enlarge the image and point what I have surrounded)

Are you sure of your protocol?

compare.jpg

No surprise- reds are always "most visible". They are destroyed! Ask BM as it's Resolve doing it. It simply broke chroma.

No surprise- reds are always "most visible". They are destroyed! Ask BM as it's Resolve doing it. It simply broke chroma.

OK

Not too much time now but as soon as possible I would do a test with MSU Video Quality Measurement Tool (it's not only FFMPEG)

@marcusfrewinridley - sorry the thread veered off into a debate/discourse on YUV vs RGB, but something significant came out of it along the way. Hope you got the answer(s) you were looking for ?

No I didn't! That's why I posted again lol. How can I just find out what y means for a layman??

thanks bryan for the images!

if you look at this psychedelic artwork -- i.e. the difference between the original source an the 10th generation --, everything becomes immediately obvious:



there is definitive some horizontal pixel resp. color plane misalignment involved!

unavoidable rounding issues and YUV->RGB conversion errors should only effect deviations and color artifacts at a steady position close to contours, but the error should never grow resp. affect other pixels beside the color subsampled pixel pair...

No surprise- reds are always "most visible". They are destroyed! Ask BM as it's Resolve doing it. It simply broke chroma.

OK

Not too much time now but as soon as possible I would do a test with MSU Video Quality Measurement Tool (it's not only FFMPEG)

What for? You don't even need any tool- just look at those grabs.
I can guarantee you ffmpeg's PSNR or SSIM filers are fine. Those pictures speak itself!

thanks bryan for the images!

if you look at this psychedelic artwork -- i.e. the difference between the original source an the 10th generation --, everything becomes immediately obvious:



there is definitive some horizontal pixel resp. color plane misalignment involved!

unavoidable rounding issues and YUV->RGB conversion errors should only effect deviations and color artifacts at a steady position close to contours, but the error should never grow resp. affect other pixels beside the color subsampled pixel pair...

Maybe it's related to chroma positioning and after each conversion it gets shifted to one side more and more.

Maybe it's related to chroma positioning and after each conversion it gets shifted to one side more and more.

yes, for instance a misalignment of the subsample raster in the import or export routines could explain this behavior.

How can I just find out what y means for a layman??

Y means luminance, that is apparent brightness proportional to linear light (actual light levels in filmed scene to put it simply). Apparent brightness here means that it is weighted according to human vision where green appears brighter than red, which appears brighter than blue. Appears is the key here, the radiant power of them can be the same, but green for humans seems brighter than other saturated colors.
Y' means luma, this is almost the same as luminance, but calculated from gamma-corrected, not linear RGB values and due to this, does not have linear relation to light levels in (filmed) scene.

unavoidable rounding issues and YUV->RGB conversion errors should only effect deviations and color artifacts at a steady position close to contours, but the error should never grow resp. affect other pixels beside the color subsampled pixel pair...

If Resolve uses bilinear filtering for resampling, multiple rounds will cause bleed that extends further and further with each iteration. Impulse/point filter is immune to this, but produces ugly (or rather not as beautiful as one might wish) images for other purposes.

No surprise- reds are always "most visible". They are destroyed! Ask BM as it's Resolve doing it. It simply broke chroma.

OK

Not too much time now but as soon as possible I would do a test with MSU Video Quality Measurement Tool (it's not only FFMPEG)

What for? You don't even need any tool- just look at those grabs.
I can guarantee you ffmpeg's PSNR or SSIM filers are fine. Those pictures speak itself!

Andrew,

I venture to question such a skid difference in 'only' reds. I remembered that green is the most sensitive : but (?).

We did not specify enough the comparison protocol: that's why I want (ASAP) to also do this test which seems a little crude. We'll see.

There is nothing to avoid.

What is worse I tried ProRes and it seems to affecting it also. There is bigger quality drop due to this buggy YUV->RGB->YUV conversion than due to ProRes next generation compression itself. This is clearly not right.
It's not even whole YUV<->RGB conversion etc- there seems to be some serious bug.
Just export ProRes, import it back and compare against source. Chroma is shifted. It's easily visible after single generation at 2x zoom. Maybe it's only in latest Resolve build.

Andrew,

I venture to question such a skid difference in 'only' reds. I remembered that green is the most sensitive : but (?).

We did not specify enough the comparison protocol: that's why I want (ASAP) to also do this test which seems a little crude. We'll see.

There is nothing to avoid.

I don't understand. What you see had nothing to do with ffmpeg- it's all Resolve processing
ffmpeg's bug in PSNR etc. could give you wrong value, but this has nothing to do what you see on the actual frame grab and those look shockingly bad.

Yep- all (I tested all intermediate codecs) 4:2:2 exports have broken output. There is bug on red channel up to level that I would simply not use Resolve for any 4:2:2 export atm. It's seriously broken. This is current 15.0.0.86 version on Mac and most likely PC as well.

How can I just find out what y means for a layman??

Y means luminance, that is apparent brightness proportional to linear light (actual light levels in filmed scene to put it simply). Apparent brightness here means that it is weighted according to human vision where green appears brighter than red, which appears brighter than blue. Appears is the key here, the radiant power of them can be the same, but green for humans seems brighter than other saturated colors.
Y' means luma, this is almost the same as luminance, but calculated from gamma-corrected, not linear RGB values and due to this, does not have linear relation to light levels in (filmed) scene.

OK so which one is the 'y' in the colour sliders? Y or Y' ? What does 'weighted according to human vision mean' in terms of how it operates? Does it increase less green than red and less red than blue when increasing Y? What does gamma-corrected mean?

What does the slider actually do? I know it is different to the wheel that adjusts R, G, and B brightness equally, but in what way?

This Avisynth filter might be helpful in determining what is going on:



https://forum.doom9.org/showthread.php?p=1849850

OK so which one is the 'y' in the colour sliders? Y or Y' ?

https://poynton.ca/PDFs/coloureq.pdf

"Make it look nice anyway."

jPo, CSI

Not too much time now but as soon as possible I would do a test with MSU Video Quality Measurement Tool (it's not only FFMPEG)

You must have the Pro version then ? The free version is limited to 8bit and SD.

if you look at this psychedelic artwork -- i.e. the difference between the original source an the 10th generation --, everything becomes immediately obvious:



there is definitive some horizontal pixel resp. color plane misalignment involved!

What tool did you use there Martin ? I seem to recall a scripted (MaskTools-based) function that someone put up on the Doom9 forum that generates an amplified difference map.

There's also this (SSIM based) quality assessment tool that includes a per-pixel 'quality map' for 'deep analysis'. Haven't tried it myself:

https://ece.uwaterloo.ca/~z70wang/research/ssimplus/

But really what more can these tools tell us ? Clearly there is a problem and it's down to BMD to identify the cause and rectify it.

We did not specify enough the comparison protocol: that's why I want (ASAP) to also do this test which seems a little crude.

What was lacking in my description of the test protocol? Only thing I didn't post was the FFMPEG command line used for the PSNR and SSIM metrics, which is standard:

Code: Select all

ffmpeg -i  {Path}:/Test.avi -i  {Path}:/Reference.avi -lavfi "ssim="stats_file=stats_ssim.log";[0:v][1:v]"psnr="stats_psnr.log" -f null -

'Reference.avi' being the source Uncomp.10-bit 422.avi clip
'Test.avi' being the re-encoded Uncomp.10-bit 422.avi clip

The frame count was preserved in the re-encodes - there was no 'frame offset' that could bias the metric comparisons.

In what way was the test 'crude' ?

Yep- all (I tested all intermediate codecs) 4:2:2 exports have broken output. There is bug on red channel up to level that I would simply not use Resolve for any 4:2:2 export atm. It's seriously broken. This is current 15.0.0.86 version on Mac and most likely PC as well.

Same goes for transcoding 4:2:2 for import. Sure hope BMD have read this and are on it.
Put me right off, it has

jPo, thanks for the clarity of post #60 among others here. Much of this thread reads like a skit from Monty Python to someone who is woefully uninformed, so I appreciate how intelligible your posts are.

But I came here for an argument!

BTW, one person who has written a great deal about Color Theory in general (not necessarily about YRGB specifically) is Charles Poynton, whose books and essays on color are valuable for anybody who wants to know the "why" behind color science and the inner workings of color-correction programs like Resolve:

https://poynton.ca/Poynton-color.html

His book on Digital Video and signal processing is pretty much the standard textbook on the subject, but be warned there's a ton of math and graphs:

https://www.amazon.com/Digital-Video-HD ... 977&sr=1-1

There is also another book (one I haven't read) by Michael Tooms called Color Reproduction in Electronic Imaging Systems, but that's about 736 pages long and fairly involved...

https://www.amazon.com/Colour-Reproduct ... 7P8A43GZ1P

What tool did you use there Martin?

it's a very simple task witch can be realized in many ways, but i used the free Natron in this particular case, because i was interesed, if the issue could be reverted by shifting individual R,G,B or U,V planes in case of the difference between the source clip and the first generation result ...



in general i would see Natron as one of the rare open source solutions, which are actually able to handle
demanding video processing tasks in a state of the art manner, and not just imitate boring vintage stuff..

There's also this (SSIM based) quality assessment tool that includes a per-pixel 'quality map' for 'deep analysis'...

this kind of tools for analyzing general quality metrics are very useful, if you have to compare compression related image quality decline etc., but in a case like this, you really should look, what's going on on the individual pixel level.

in such a case it's much more useful to utilize your eyes, powerful and flexible compositing tools and as a last resort python numpy+OpenCV to analyze and play around mathematically with the actual values...

But really what more can these tools tell us ? Clearly there is a problem and it's down to BMD to identify the cause and rectify it.

one interesting aspct, which we could perhaps examines as well, is the question, if the issue happens already on import or during exporting clips? in the first case, the image within resolve should from begin on look like your first generation result, which already shows significant differences...

But I came here for an argument!

BTW, one person who has written a great deal about Color Theory in general (not necessarily about YRGB specifically) is Charles Poynton, whose books and essays on color are valuable for anybody who wants to know the "why" behind color science and the inner workings of color-correction programs like Resolve:

https://poynton.ca/Poynton-color.html

His book on Digital Video and signal processing is pretty much the standard textbook on the subject...

Marc, thanks for the links. I’ve saved them all. The first is a good jumping off point. You and jPo among others have been very helpful over the last five years or so with your near infinite knowledge and, most importantly, generosity and patience.


Sent from my iPhone using Tapatalk

Resolve 15.01.003 same problem- not fixed. Be warned.

OK so which one is the 'y' in the colour sliders? Y or Y' ?

https://poynton.ca/PDFs/coloureq.pdf

"Make it look nice anyway."

jPo, CSI

Can't get the link to work

OK so which one is the 'y' in the colour sliders? Y or Y' ?

My guess (anyone with expertise in Resolve manual can argue) is that it is in most cases neither. Because I very much doubt that RGB channel weighting is changed when timeline colorspace changes, it is Y' (luma) only when timeline is rec709 and actually has rec709 stuff on it. But as I don't know what weights are actually used, this is all just guesswork anyway.

What does 'weighted according to human vision mean' in terms of how it operates? Does it increase less green than red and less red than blue when increasing Y? What does gamma-corrected mean?
What does the slider actually do? I know it is different to the wheel that adjusts R, G, and B brightness equally, but in what way?

Weighting means that Y and Y' are formed by adding R, G and B channels in different proportions according to measured apparent brightness (measures by tests, people literally staring at color patches in controlled environment).
I'm not a colorist so if I write absolute bollocks, someone can hopefully correct me. But afaik changing Y slider changes Y value of luma-chroma derivate so that luma is changed but chroma is not. It results in saturation change because relative contribution of luma value to RGB values changes (inverse transform equation for Y'CbCr>RGB here illustrates this) and this leads to relative convergence or divergence of RGB values, thus also saturation change.

your sarcasm and condescension detectors are way off...

I must concede and heartily assert that this instance of Marc's response serves as one of the marked (no pun) examples of Sir Weilage not coming off as though he's communicating from a lofty, elitist perch, and I wholly applaud him for the congenial choice of wording in his rather soberminded, and useful reply.
[Re]Pete

Good grief. I was the recipient and I think I should be free to express how it came across at the time. Marc came back to clarify no sarcasm or condescension intended which is fine by me. The matter is closed. By all means commend him for the wisdom imparted, but please spare me the condemnation. Now can we move on please.

[quote="Andrew Kolakowski wrote:I'll do it when I have time but with vapoursynth. I done some test with avs old days and with (if I remember well) 8 taps sinc scaler I had 80dB+ after 1st gen, but on all channels.
I'll also test with Scratch as it also goes over RGB and uses GPU.

Great. Just wondering where the above test findings leave us though. Is this something that should be formally flagged for BMD's attention as suggestive of a chroma sampling bug or left as an incidental observation to 'make of what one will' ?[/quote]In retrospect, it's nearly hilarious that a reader might "isogete" the text of anyone's reply above, and come up with the outlandish, untenable and unsupported notion that "condemnation" (sic!) was hurled at any one reader or contributor here.

This gross misunderstanding of "author's intent" illustrated in a couple of acerbic replies above, point to the need for schools and parents to do a better job at teaching kids (and adult peers as well) the increasingly decaying art and science of interpretation.

#AbsolutelyAmazing.
[Re]Pete

ResolveStudio 14.3...014 | MiniMonitor | DTV 10.9.7 | Win8.1 x64 | ROG G751JL, 2.8GHz Intel i7HQ, 24GB DDR4, 1TB HD, 500GB EVO 850, 2GB GTX965M | Mackie MCU Pro | Softube Console 1 Mkii | Shuttle Pro 2 | more...

It's now a matter of serious bug, not debate about quality of YUV<->RGB conversion. I assume this bug has been introduced recently- maybe somewhere in v15 beta stage (b7 on PC has it).
I would not export any final 4:2:2 YUV based master out of current Resolve.

In retrospect, it's nearly hilarious that a reader might "isogete" the text of anyone's reply above, and come up with the outlandish, untenable and unsupported notion that "condemnation" (sic!) was hurled at any one reader or contributor here.

This gross misunderstanding of "author's intent" illustrated in a couple of acerbic replies above, point to the need for schools and parents to do a better job at teaching kids (and adult peers as well) the increasingly decaying art and science of interpretation.

The notion of 'hurled condemnation' was never implied. But the very fact that you insist on requoting (and again now) a remark I made to Marc way back at beginning of thread speaks for itself. Even Marc makes light of it:

But I came here for an argument!

In short, just drop it eh? An arguably more valuable lesson for life (art form, if you will) is knowing when to "leave well enough alone".

It's now a matter of serious bug, not debate about quality of YUV<->RGB conversion. I assume this bug has been introduced recently- maybe somewhere in v15 beta stage (b7 on PC has it).

I suspect so too. I'm pretty sure when I did tests a while back to (re)assess the 'quality efficiency' of the available 'intermediate' 10-bit 422 formats, this was not an issue i.e. Uncompressed > Resolve > Uncompressed was lossless. Can't recall what version I was using at the time though. Might have been when the VBR DNxHR encoding option was added. I have archived copies of prior versions (most beta's included) going back to 12.5, but I'm not inclined to go through them.

It's now a matter of serious bug, not debate about quality of YUV<->RGB conversion.

Good to know my pedantry sometimes leads to actually useful things like uncovering bugs!

I could give you many examples which prove this

Can't get the link to work

Clicking it here takes me to the pdf, but then it disappears... reducing the on-screen scaling makes it re-appear. Strano.

Anyway as Marc also refers, just request a Google search with a string like Poynton colorspace Y' and you will get it. Charles goes a bit John-Cleese when people start tossing around the Y-Prime like its a household item. The "Digital Video and HDTV Algorithms and Interfaces" ISBN-13: 978-1-55860-792-7 is not also referred to as the "Gamma Sutra" for nothing.

As far as individuals cooking up their own methodologies -- it's generally better to consult the literature first.

Not saying that penicillin, for example, was something that an officially-sponsored research program was responsible for. Most good things have been discovered by accident. And some by people who actually knew what they were doing. One of those approaches is something you can take to a bank.

jPo, CSI

Most good things have been discovered by accident. And some by people who actually knew what they were doing.

Let's say "chance favours the prepared mind".

OK so which one is the 'y' in the colour sliders? Y or Y' ?

My guess (anyone with expertise in Resolve manual can argue) is that it is in most cases neither. Because I very much doubt that RGB channel weighting is changed when timeline colorspace changes, it is Y' (luma) only when timeline is rec709 and actually has rec709 stuff on it. But as I don't know what weights are actually used, this is all just guesswork anyway.

What does 'weighted according to human vision mean' in terms of how it operates? Does it increase less green than red and less red than blue when increasing Y? What does gamma-corrected mean?
What does the slider actually do? I know it is different to the wheel that adjusts R, G, and B brightness equally, but in what way?

Weighting means that Y and Y' are formed by adding R, G and B channels in different proportions according to measured apparent brightness (measures by tests, people literally staring at color patches in controlled environment).
I'm not a colorist so if I write absolute bollocks, someone can hopefully correct me. But afaik changing Y slider changes Y value of luma-chroma derivate so that luma is changed but chroma is not. It results in saturation change because relative contribution of luma value to RGB values changes (inverse transform equation for Y'CbCr>RGB here illustrates this) and this leads to relative convergence or divergence of RGB values, thus also saturation change.

So does that mean the difference in effect between the Y slider and the horizontal wheel is that the wheel does not change saturation but the Y slider does? I remember a video showing that the wheel could oversaturate reds and in such an instance you should use the Y slider, which would suggest the opposite of the above, no?

So does that mean the difference in effect between the Y slider and the horizontal wheel is that the wheel does not change saturation but the Y slider does? I remember a video showing that the wheel could over saturate reds and in such an instance you should use the Y slider, which would suggest the opposite of the above, no?

Horizontal wheel operates on all 3 colour channels (RGB) simultaneously and maintains the relationship between the channels so as to avoid any unwanted hue shifts.

Y slider operates on a derived luminance math that adjusts the perceived brightness or luminance (not technical brightness which is the black level) while leaving the saturation untouched (not exactly but close enough).

For those that need more explanation, use colour bars and scopes to see what is going on. It's quite obvious and using bars will quickly show how the relationship between these two controls works.

For practical purposes understanding the math behind the controls is not really necessary to achieve a good looking and technically correct image.

JPo has pretty much summed it up earlier in this thread.

The link from Marc worked fine on my iPhone.


Sent from my iPhone using Tapatalk

Good old colour bars will do it, you don't even need anything much fancier.

Repeated the above Uncomp. 10-bit 422 AVI 'generation' tests using the EBU Colour Bars as source.

1. EBU Color Bar Generator > Timeline > Compound Clip
2. Exported to Uncomp. 10-bit YUV 422 AVI (Full Data Levels)
3. Re-imported the export (Full Data levels) and encoded to Uncomp. 10-bit YUV 422. AVI again.
4. Repeated the cycle up to 10 re-encodes.

Brought the clips onto timeline (Full Data Levels) and took screen grabs of the Histograms.
Couldn't be bothered running SSIM/PSNR metric tests. The images and Histogram profiles were evidence enough.



Edit: Ooops, I see I cropped-off the blue channel on that last (10th) generation re-encode histogram. I redo it when I have a moment.

Interesting that the initial Uncomp.10-bit 422 export didn't show degradation when brought back onto the timeline. The degradation started with the first re-encode of that export.

Uncompressed frame grabs:

Initial Uncomp. 10-bit 422 AVI export:



Tenth Generation Re-encode:



As before, after opening in Imgur, click (+) cursor to enlarge to original res. Right click to Copy or Save.