'y' in YRGB?

What does the Y control actually represent? I can't find info on his anywhere, except for the difference between adjusting it and adjusting R, G, and B all together. What does it actually adjust? Even the manual seems to assume I already know when telling me the difference. I found somewhere someone saying it is luminance, but luminance of what? I used to think it was luminance of R, G, and B all together, but if it is difference to this then what it is?

(Also why is this text-box spellchecking 'luminance'? It thinks 'luminescence' is the only correct word?)

Y indicates Luminance vs RGB for color.

It represents the lightness of the image minus chroma. It's a weighted sum of RGB components where green is factored more than red, and red is factored more than blue. If you decrease Y gain to minimum you will still be able to see chroma of the image.

It's a finer point whether this is luma (Y') or luminance (Y). I am not sure. But it's not all that relevant to the end user.

(Also why is this text-box spellchecking 'luminance'? It thinks 'luminescence' is the only correct word?)

Evidently it doesn't like colour science either

It represents the lightness of the image minus chroma. It's a weighted sum of RGB components where green is factored more than red, and red is factored more than blue. If you decrease Y gain to minimum you will still be able to see chroma of the image.

It's a finer point whether this is luma (Y') or luminance (Y). I am not sure. But it's not all that relevant to the end user.

https://en.wikipedia.org/wiki/Chroma_subsampling

Quote:

"....the term luminance and the symbol Y are often used erroneously to refer to luma, which is denoted with the symbol Y'. Note that the luma (Y') of video engineering deviates from the luminance (Y) of color science (as defined by CIE). Luma is formed as the weighted sum of gamma-corrected (tristimulus) RGB components. Luminance is formed as a weighed sum of linear (tristimulus) RGB components."

Which left me pondering whether the Y component in Resolve's YRGB colour tools does actually represent derived Luma. After further reading though, I wonder if 'Relative Luminance' more accurately describes what Y represents in this context ?

https://en.wikipedia.org/wiki/Relative_luminance

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.

I'm familiar with all of that. No need for the sarcasm and condescension. Semantics or not, like the OP, I was just trying to gain a better understanding of what 'Y' means in the context of Resolve's YRGB colour science, the colour tools and scope representations. My thinking that it maybe refers to 'Relative Luminance' rests on an assumption that there must surely be normalization of gamma-adjusted luminance computations. That's all.

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

your sarcasm and condescension detectors are way off...

All this fuss would clear if manual stated what is the exact formula for calculating the Y value from RGB, how it is normalized, and from which state in image pipeline are the RGB values pulled from (should be timeline colorspace). Based on this info one can tell if it is luma, luminance, lightness (lightness as a term is not the same as luminance) or some random arbitrary unit. But as timeline colorspace can be anything and I doubt these coeficcients change, it is in most cases just an arbitrary weighting, not technically luminance.

YRGB is a proprietary colour space invented by Da Vinci Systems, so you won't find much if any technical details about it on Wikipedia. You can think of it as a hybrid between YUV and RGB, where you get the advantages of being able to control luminance and colour (chroma) separately, with the intuitiveness of working with RGB as opposed to the deeply unintuitive G-B and G-R (anyone who's tried to colour correct with Avisynth will know the pain).

I wouldn't call it a color space, it contains duplicate information and Y component is totally irrelevant for describing the actual color value, RGB does it just fine.

What is going on is basically something like this:
Lets say Resolve uses equation Y' = 0.2126R' + 0.7152G' + 0.0722B' (rec709 luma coefficients).
User is presented with four sliders YRGB with weight values for each where value 1.0 represents default, or unchanged state (the numbers on slider UI are irrelevant, it could be 0-1, 0-100 or whatever)
Now, when user pulls the slider of Y to value 0.5, we get new RGB values by multiplying them all with this weight. And when changing any of the RGB sliders, that component is weighted by slider value.
If we want to preserve luminance when changing RGB values, the Y slider gives us the luminance target relative to original, and modified RGB components are all linearly scaled with single solved scalar so that used luminance equation hits that target.

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.

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.

Y is always calculated/made up. YUV is a "made up" imaginary colour space that facilitates data compression/deduplication. RGB duplicates luminance information across the R, G and B channels, and it is exactly that redundant extra data which gets consolidated into a single channel (Y) in YUV. So in terms of redundancy, RGB is more redundant than YUV. YRGB is more redundant still. But its purpose is not to be compact, its purpose is to make colour transformations intuitive.

So in terms of redundancy, RGB is more redundant than YUV. YRGB is more redundant still. But its purpose is not to be compact, its purpose is to make colour transformations intuitive.

RGB compresses badly (because Y is bound into all RGB), so all heavily compressed formats are YUV based. RGBY is another level and "heavily" made up.

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

your sarcasm and condescension detectors are way off...

Surely "In my opinion, your sarcasm and condescension detectors are way off...."

Interesting discussion that followed though guys.

Y is always calculated/made up. YUV is a "made up" imaginary colour space that facilitates data compression/deduplication. RGB duplicates luminance information across the R, G and B channels, and it is exactly that redundant extra data which gets consolidated into a single channel (Y) in YUV. So in terms of redundancy, RGB is more redundant than YUV. YRGB is more redundant still. But its purpose is not to be compact, its purpose is to make colour transformations intuitive.

RGB doesn't duplicate anything. Every combination of RGB code values expresses a unique color. Not all YUV combinations express unique colors, so for the same granularity (bit depth per channel) you lose information with YUV representation. The redundancy here is is purely perceptual, YUV allows discarding stuff that is less relevant for human vision, it has nothing to do with data redundancy. Y is directly deductible from RGB components, thus it is redundant in YRGB system. Which again doesn't mean that it isn't useful, just as saturation-hue-luminance system has no real radiometric meaning but is still useful as a base for controls.

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.
Y is always calculated/made up. YUV is a "made up" imaginary colour space that facilitates data compression/deduplication...

Resolve is not one of them, but there are, or have been systems that processed and stored values in Y'CbCr. This color model is often misnamed as YUV. Strictly speaking, YUV is in analog domain, but that's somewhat irrelevant, we're talking about the same thing.

Y'CbCr can be very real and tangible based on the implementation. Historically there have been two, perhaps more, advantages of Y'CbCr. This is the legacy color model from analog TV. Y'CbCr has a wider gamut than RGB. There are legal values in Y'CbCr that can not be mathematically expressed in RGB.

Regarding what the "Y" parameter control in Resolve really controls, aside from curiosity, does it really matter all that much? We know how the control feels. It's like driving a car. You have a feel for when the RPM is high enough to shift up to the next gear. What happens under the hood is not all that relevant to the driver.

Y'CbCr can be very real and tangible based on the implementation. Historically there have been two, perhaps more, advantages of Y'CbCr. This is the legacy color model from analog TV. Y'CbCr has a wider gamut than RGB. There are legal values in Y'CbCr that can not be mathematically expressed in RGB.

Which presents itself as "gamut error" and can bee a real pain during deliveries to broadcast.

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

Yes, but RGB is all what you need from source data side. You store it in file and done. There is no need to store RGBY as Y is calculated from RGB, so it's pointless. In Resolve it's also calculated. It's not like Resolve reads it from source file in case of RGB based sources. Maybe it's also re-calculated in case of YUV based sources. It's just a slider in Resolve for user to have easier control- it has no "actual" meaning, like RGB itself. It's more like a math and user doesn't really need to understand it.

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

A very cool explanation JPOwens, thank you!

RGB duplicates luminance information across the R, G and B channels, and it is exactly that redundant extra data which gets consolidated into a single channel (Y) in YUV. So in terms of redundancy, RGB is more redundant than YUV.

YUV representations certainly open up more perceptual compression opportunities, either by using a lower UV resolution or bitrate in comparison to the Y channel but I just can't see how one can argue that RGB information has more redundancy than YUV.

YUV is good for compression because Y is separated (independent) from UV and this allows for easy\independent "manipulation" on luma and chroma parts.

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

Not really- if anything defines as true (for humans) is how eye sees the scene. Camera original is massive simulation of it. Its far from "truth".

I just can't see how one can argue that RGB information has more redundancy than YUV.

It's quite simple. If YUV describes a larger colour space than RGB within the same amount of data, and it can (assuming full range and ignoring floating point rounding errors) be transformed back to RGB without loss, that means RGB contains redundant data.

If YUV describes a larger colour space than RGB within the same amount of data, and it can ....

Why do you assume RGB is limited?
XYZ was actually derived from RGB values, that's pretty darn large!

Are you not by accident comparing the sRGB color space with the old, larger, NTSC color space?

It's quite simple. If YUV describes a larger colour space than RGB within the same amount of data, and it can (assuming full range and ignoring floating point rounding errors) be transformed back to RGB without loss, that means RGB contains redundant data.

It doesn't. RGB is a color model, it has no bounds., at least when talking about real, not imaginary colors. You get color space size only if you set certain primaries and white point and even then nothing prevents one from expressing components in negative values (using floats or signed ints) which effectively allows describing wider gamut even when dealing with sRGB for example. Only if values are clipped to zero, one sets actual bounds to gamut. And as I wrote before, within the same amount of data luma-chroma model has combinations that don't express a distinct color, thus it contains less useful data. If luminance is zero, chroma values don't mean anything anymore, whatever they are, they still express the same color. Just as with HSL model, if saturation is zero, hue has no meaning. There is no meaningful way to derive different RGB triplets from YUV or YCbCr combinations where Y is zero but others are not.

I'm talking purely about information preservation. If RGB data survives the transformation of RGB->YUV->RGB, whereas YUV data does not survive the transformation of YUV->RGB->YUV (values that are illegal in RGB space), then RGB is a smaller data space as far as information preservation is concerned. It doesn't matter whether those illegal values are imaginary, useless, whatever, but the RGB space has been compressed into a smaller data space. Luminance has been decoupled from the R, G and B channels and the resulting U and V channels are bigger than they need to be to fully describe every RGB triplet. This results in better compression. Take an uncompressed RGB bitmap, and zip it up at max compression. Then take an uncompressed YUV bitmap describing the same image, and zip that up at max compression, and it will be substantially smaller. It's not a fully lossless process, because of the aforementioned floating point rounding errors (you're going 8 bit integer -> double precision floating point -> int8 -> double -> int8), but for the purposes of proving that RGB is more redundant than YUV, it's still valid.

Yes, this is known problem with YUV->RGB->YUV conversion.
I done recently test with 10 times conversion: v210 to v210 in Resolve (which goes through RGB of course) and it finished with fairly very poor end result. Quality difference was visible by naked eye at 2x zoom or even 1:1 if you looked closely. PSNR was <50dB, so not very good at all when we think that we were converting uncompressed to uncompressed

Yes, this is known problem with YUV->RGB->YUV conversion.

It should not in theory be a problem if the intermediate RGB is un-clamped float. If the RGB is not manipulated in any way (and certainly not clamped 0-1) then it should be possible to invert to a bit identical Y'CbCr image.

Here is a demonstration using Colour Science for Python, for those interested:

Code: Select all

>>> YCbCr = (np.random.rand(10, 3)*255).astype('uint8')
>>> YCbCr
array([[123, 117, 165],
       [ 53,  13, 148],
       [ 53, 251,  86],
       [ 16,  29,  53],
       [ 73, 149,  80],
       [252,  20, 105],
       [ 58, 250, 192],
       [253,  96, 145],
       [ 67, 199, 166],
       [236, 166,  20]], dtype=uint8)
>>> RGB = colour.YCbCr_to_RGB(YCbCr, in_int=True, in_bits=8)
>>> RGB
array([[ 0.74870769,  0.42045934,  0.39746126],
       [ 0.30955691,  0.22332391, -0.78370201],
       [-0.12632523,  0.15386198,  1.18787299],
       [-0.52727679,  0.23952868, -0.82010893],
       [-0.07718317,  0.34302467,  0.43423647],
       [ 0.91592736,  1.21600896,  0.18296129],
       [ 0.64172368, -0.0439938 ,  1.20242011],
       [ 1.20170785,  1.0734251 ,  0.81710607],
       [ 0.50003028,  0.09408767,  0.82103564],
       [ 0.24528764,  1.19849076,  1.3193555 ]])
>>> colour.RGB_to_YCbCr(RGB, out_int=True, out_bits=8)
array([[123, 117, 165],
       [ 53,  13, 148],
       [ 53, 251,  86],
       [ 16,  29,  53],
       [ 73, 149,  80],
       [252,  20, 105],
       [ 58, 250, 192],
       [253,  96, 145],
       [ 67, 199, 166],
       [236, 166,  20]])
>>> colour.RGB_to_YCbCr(RGB, out_int=True, out_bits=8) == YCbCr
array([[ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True],
       [ True,  True,  True]], dtype=bool)

However, while Resolve can represent the out of gamut Y'CbCr colours internally using RGB floats, I believe it does clamp 0-1 when rendering.

I'm talking purely about information preservation. If RGB data survives the transformation of RGB->YUV->RGB, whereas YUV data does not survive the transformation of YUV->RGB->YUV (values that are illegal in RGB space), then RGB is a smaller data space as far as information preservation is concerned. It doesn't matter whether those illegal values are imaginary, useless, whatever, but the RGB space has been compressed into a smaller data space. Luminance has been decoupled from the R, G and B channels and the resulting U and V channels are bigger than they need to be to fully describe every RGB triplet.

RGB color spaces do not clip anything by itself here, clipping is purely storage and spec related, not inherently related to RGB or its data space size (what is data space anyway?). I can preserve whatever values produced by YUV>RGB conversion either by using floats or signed ints. Just as I can destruct the data in RGB>YUV>RGB conversion by not using enough precision. By doing all math on 8bit precision, data clearly does not survive RGB->YUV->RGB conversion. And by using full floats, data survives YUV->RGB->YUV conversions pretty nicely.

The term illegal has meaning when talking about reference to some specification, no-one calls values above 1.0 (or below 0.0) illegal in exr files, just as a linearized log file does not produce illegal values in Resolve.

All image data originates in RGB space (lets leave synthetic stuff out) and ends up in RGB on display device, so whether YUV/YPbPr/YCbCr has legal values that produce illegal values in some RGB color space is in my opinion irrelevant for color manipulations. Luminance-chrominance representations are useful for storage and transport but for describing color they have no additional value over RGB.

I keep getting contradicting answers for this problem. Some devs say it's never lossless regardless of precision, others opposite. It's math so there is only 1 correct answer

When we focus on Resolve then its YUV->RGB-YUV conversion is far from lossless, so question is why? Resolve operates in 32bit float. Where does this massive quality loss is coming from?
Out of gamut problem would show only on 1st generation (I'm almost sure source had no this issue anyway), yet in my test every next conversion yield worse and worse result. After 10 conversions it was quite bad. I remember doing the same test with avisynth and results were much better (1st conversion gave 80dB+ PSNR compared to 60dB+ in Resolve).
It has to be related to chroma processing. Resolve does something "bad/not optimised" with 4:2:2 chroma (there were few problems related to chroma subsampling in Resolve including SDI preview). It should be looked into.

It has to be related to chroma processing.

Right - and presumably in your 'round tripping' metric tests that was reflected in the differential Y, U and V channel PSNR scores ?

However, while Resolve can represent the out of gamut Y'CbCr colours internally using RGB floats, I believe it does clamp 0-1 when rendering.

Haven't tested it myself (at full Data levels, that is), but does the 'Retain sub-black and super-white data' option not impact that, to some degree at least? Or does that only have relevance for transcoding/rendering at Video levels ?

However, while Resolve can represent the out of gamut Y'CbCr colours internally using RGB floats, I believe it does clamp 0-1 when rendering.

Resolve does not clamp when it outputs EXR float.

Haven't tested it myself (at full Data levels, that is), but does the 'Retain sub-black and super-white data' option not impact that, to some degree at least? Or does that only have relevance for transcoding/rendering at Video levels ?

It is only relevant for video levels.

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!

Right - and presumably in your 'round tripping' metric tests that was reflected in the differential Y, U and V channel PSNR scores ?

It was affecting all channels, but U was way worse than others.

Resolve does not clamp when it outputs EXR float.

True, but not really relevant when discussing round tripping back to a Y'CbCr format. In that case, I believe that the RGB image data is clipped to 0-1.

Of course Y'CbCr image data should not normally contain values significantly outside the RGB unit cube, so clamping those is not normally problematic. You might find that applying a full to legal scale in DCTL, and then writing to the Y'CbCr format as 'data' would give enough leeway to preserve all normal overshoots. I don't know though. I haven't tested.

I keep getting contradicting answers for this problem. Some devs say it's never lossless regardless of precision, others opposite. It's math so there is only 1 correct answer

But my Python example proves it is possible to round trip Y'CbCr > RGB > Y'CbCr losslessly. I also ran the test again with 1000 random 10-bit Y'CbCr triples. Still lossless!

Code: Select all

>>> YCbCr = (np.random.rand(1000, 3)*1023).astype(int)
>>> RGB = colour.YCbCr_to_RGB(YCbCr, in_int=True, in_bits=10)
>>> np.all(colour.RGB_to_YCbCr(RGB, out_int=True, out_bits=10)==YCbCr)
True

Right - and presumably in your 'round tripping' metric tests that was reflected in the differential Y, U and V channel PSNR scores ?

It was affecting all channels, but U was way worse than others.

That was my observation also when I did some 'round tripping' metric tests a while back. Main interest there though was the pass-through 'quality efficiency' of visually lossless 10-bit 422 formats (Cineform, DNxHR) and with Uncompressed 10-bit 422 as reference. SSIM was the metric. Didn't retain the data, but I recall Cineform (Filmscan 2) came out of that rather well. The primary 'quality hit' was, as you'd expected, on first transcode, but subsequently luma was barely affected, as gauged by the relative SSIM scores. Mind you, only ran a couple of cycles.

Still, interesting that the U chroma is more affected than V.

Still, interesting that the U chroma is more affected than V.

Since the blue component has a much lower weighting in the luma calculation, I guess it makes sense that Cb is more vulnerable to artefacts.

I keep getting contradicting answers for this problem. Some devs say it's never lossless regardless of precision, others opposite. It's math so there is only 1 correct answer

But my Python example proves it is possible to round trip Y'CbCr > RGB > Y'CbCr losslessly. I also ran the test again with 1000 random 10-bit Y'CbCr triples. Still lossless!

Of course that proves that Y'CbCr -> RGB -> Y'CbCr can be lossless, but that is not taking account of conversion between 4:4:4 and 4:2:2. 4:4:4 -> 4:2:2 -> 4:4:4 will never be lossless. The other way round potentially could be.

You start with v210 (10bit YUV 4:2:2) and export back to v210. Do it 10 times and you have massive quality loss in Resolve. Why?
We are not talking 4:4:4->4:2:2->4:4:4 as this obviously never will be lossless.

You start with v210 (10bit YUV 4:2:2) and export back to v210. Do it 10 times and you have massive quality loss in Resolve. Why?

Just done that....

Source: Uncompressed 10-bit 422 (v210), 1080/23.976p, AVI, 3 sec duration.
Export: The same
SSIM & PSNR measured with FFMPEG

First Pass through Resolve 15
SSIM: Y=1.0000, U=0.9953, V=0.9923, All=0.9969
PSNR: Y=84.8636, U=50.9661, V=48.5642, Average=52.6102

10th Pass through Resolve 15
SSIM: Y=0.9999, U=0.8970, V=0.8598, All=0.9372
PSNR: Y=63.2824, U=37.2214, V=35.7723, Average=39.4380

Actually, in this series the greater 'quality' loss was seen in the V chroma channel.

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

No sarcasm or condescension intended. I'm just telling it like it is. People have debated the whole YRGB thing for years and years and years, so this is not a new conversation.

Me personally, I care more about how the controls respond, what it takes to get a desired look, and how to solve problems quickly -- what the process is actually called takes a backseat to all that. No doubt the manual could go into the signal processing in more detail, though bear in mind they're pushing 2632 pages as it is. (I would actually like to see the manual split up into an "Operating Manual" and a "Reference Manual," where the latter would delve more into theory and signal processing, while the former would be more about how to perform certain functions.)

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.

I agree 100% with Joe's analysis here, but I would point out that the 1980s Dubner color corrector did actually provide the ability to do separate YRGB corrections and you could (say) add red without simultaneously subtracting Green & Blue. But the Dubner was an unusual device and fell by the wayside pretty quickly once daVinci (small D) arrived a few years later. (The Corporate Communications "System XL" also could do similar functions, but it was even more rare than Dubner.)

It has to be related to chroma processing. Resolve does something "bad/not optimised" with 4:2:2 chroma (there were few problems related to chroma subsampling in Resolve including SDI preview). It should be looked into.

What is the specific flaw you're seeing? As far as I know, Resolve internally is processing everything in 8:8:8 32-bit RGB float, so it shouldn't affect 4:2:2 at all. If you can see something, it should be measurable and visible on a scope. There are some "torture test" test patterns out there that will break all kinds of signal processing situations.

Problem is Resolve's poor YUV->YUV conversion, which internally goes through RGB. Those numbers are really low.
If you take 10bit uncompressed 4:2:2 file and export it 10 times you will see degradation by eye (not even measuring PSNR). I'm not sure if you understand the we exporting back to 10bit uncompressed format and whole quality degradation is purely due to Resolve's poor 4:2:2 handling. It should not be there (according to some people, eg. Nuke test) or should be way lower. It's not a big deal for every day work, but in the same time it's some fundamental flaw in Resolve internals.
10 generations will case you worse quality loss than eg. ProResHQ itself and we are not touching compression- we are exporting uncompressed

Resolve can't match apps which work internally in YUV (there you can have 100000 generation and quality will be 100% the same), but those PSNR numbers are simply to low. Resolve keeps interpolating 4:2:2 to 4:4:4, then dropping back to 4:2:2 on export, but because it does it badly there is quality loss, which adds really quickly. It's probably done on GPU with simple resizing algorithm and this is the problem. When you look at actual footage chroma gets messy and soft (looses shape and spreads into surrounding pixels) compared to source.

10th Pass through Resolve 15
SSIM: Y=0.9999, U=0.8970, V=0.8598, All=0.9372
PSNR: Y=63.2824, U=37.2214, V=35.7723, Average=39.4380

The mid to high 30s is pretty shocking.
I would put an engineer on it right away!

You start with v210 (10bit YUV 4:2:2) and export back to v210. Do it 10 times and you have massive quality loss in Resolve. Why?

Just done that....

Source: Uncompressed 10-bit 422 (v210), 1080/23.976p, AVI, 3 sec duration.
Export: The same
SSIM & PSNR measured with FFMPEG

First Pass through Resolve 15
SSIM: Y=1.0000, U=0.9953, V=0.9923, All=0.9969
PSNR: Y=84.8636, U=50.9661, V=48.5642, Average=52.6102

10th Pass through Resolve 15
SSIM: Y=0.9999, U=0.8970, V=0.8598, All=0.9372
PSNR: Y=63.2824, U=37.2214, V=35.7723, Average=39.4380

Actually, in this series the greater 'quality' loss was seen in the V chroma channel.

Your numbers are crazy low (mine lowest was around 45dB) and probably because your footage was "very colorful". Main wasn't that colorful at all. U or V degradation will depend on which channel carries more chroma information. More busy one will show bigger degradation. You can see that Y also looses precision, but it's still at acceptable loss level.
35dB PSNR is on level of compressed h264! We have same loss exporting uncompressed as we have exporting fairly heavily compressed h264. Serious issue.

It was a colorful clip - not much motion though, just some pedestrians crossing the road:



But there's more to it. The above series of pass-through tests was performed with the data level at (default) Auto, which for YUV.avi files defaults to Video levels. So I ran the tests again with the input (Clip Attributes) and delivery data levels set at Full.

First Pass through Resolve 15
SSIM: Y=1.0000, U=0.9953, V=0.9923, All=0.9969 (Same values as at Video levels)
PSNR: Y=106.6627, U=50.9216, V=48.5447, Average=52.5827

10th Pass through Resolve 15
SSIM: Y=0.9999, U=0.8838, V=0.8513, All=0.9338
PSNR: Y=72.7275, U=36.5085, V=35.3901, Average=38.9227

Just for easy comparison, here are the results obtained at Video levels again:

First Pass through Resolve 15
SSIM: Y=1.0000, U=0.9953, V=0.9923, All=0.9969
PSNR: Y=84.8636, U=50.9661, V=48.5642, Average=52.6102

10th Pass through Resolve 15
SSIM: Y=0.9999, U=0.8970, V=0.8598, All=0.9372
PSNR: Y=63.2824, U=37.2214, V=35.7723, Average=39.4380

Actually the SSIM scores for the first pass render at Full data levels were exactly the same as those at Video levels. The Luma (Y) PSNR scores however were notably higher at Data levels. Otherwise there was not that much difference in the PSNR and SSIM scores for the U and V channels. But again that same overall trend with significant loss in (metric) chroma quality after 10 pass-through cycles.

Not only that. I ran another series of tests, this time serially re-encoding to Uncompressed 10-bit 422 AVI using Resolve's (Media Management) transcode function. The data level interpretation at each round of re-encoding (10 cycles) was again set to 'Full' to avoid any possibility of compression or clipping - something that only applies to the AVI transcode formats (Uncompressed, Cineform, Grass Valley HQX). The Quicktime (MOV) 10-bit 422 transcode formats behave differently - setting the source clip data interpretation to Full compresses the source luma (proportionately) from Full (0-1023) to Limited/Video (64-940) range. And setting to Video levels clamps/clips to 64-940 range - hence the value of the 'Retain sub-black and super-white data' option to preserve any outside values that would otherwise be clipped. Transcoding to 10-bit YUV 422 in AVI format at Full data levels avoids all that.

When I ran the SSIM and PSNR metric tests on the transcodes, lo and behold, the results were EXACTLY the same as those of the 'pass-through' tests. Not surprising perhaps, but of concern just the same.

What is the specific flaw you're seeing? As far as I know, Resolve internally is processing everything in 8:8:8 32-bit RGB float, so it shouldn't affect 4:2:2 at all. If you can see something, it should be measurable and visible on a scope.

Yes, clues are visible on the scopes. Here are the Parade and Histogram profiles obtained when the source, first and tenth 'generation' encode clips were brought into the timeline.

First at Full data levels:



And then at Video levels:



'Spot the difference'. Most obvious, that downshift in the Blue channel histogram. Doesn't bode well does it.

Just to emphasize the point. Same source Uncompressed 10-bit 422 (v210) AVI file serially re-encoded 20 times with VirtualDub2. VDub2 sends decode v210 directly to the compressor.

SSIM: Y=1.0000, U=1.0000, V=1.0000, All=1.0000
PSNR: Y=inf, U=inf, V=inf, Average=inf

Completely lossless, as it should be.

Just to emphasize the point. Same source Uncompressed 10-bit 422 (v210) AVI file serially re-encoded 20 times with VirtualDub2. VDub2 sends decode v210 directly to the compressor.

SSIM: Y=1.0000, U=1.0000, V=1.0000, All=1.0000
PSNR: Y=inf, U=inf, V=inf, Average=inf

Completely lossless, as it should be.

But that is like comparing apples to pears unless you converted the source from YUV -> RGB - YUV using full processing and a conversion to RGB filter.

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+