'y' in YRGB?

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.

Now, that's funny: a color space joke!

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.

Yep, that is exactly right.

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

I think I said that and then got yelled at because they thought I was being condescending.

There are some fairly big-name colorists I know who are surprisingly untechnical. They worry only about how to take care of their clients and finish their shows effectively -- not so much how the math and science works under the hood. It's kind of like how a race car driver knows how to drive (very well), but probably doesn't know how to design or build an engine. I think it's two separate and distinct jobs. But it's always a good idea to have a basic grasp on what's going on in both directions.

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

I think I said that and then got yelled at because they thought I was being condescending.

I can see this is going to haunt me forever

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.

It means problem is with YUV->RGB conversion (so during source import), which makes perfect sense as this is the stage where you interpolate 4:2:2 to 4:4:4. Generated bars goes only through RGB->YUV during export.
It also means that when you work with RAW or 4:4:4 sources you won't have this issue (eg. when you export ProRes master).

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.

i would argue, that this issue is already visible in your initial export as a vertical line of one pixel width:



this kind of artifact doesn't have to be present at this particular position, but it looks like caused by a kind of image refinement resp. uncommon color subsample smoothing, which seems to be deliberately handled by resolve in this manner.

but color subsampling isn't the only cause for such troubles. if you utilize GPU accelerated image processing, it also happens quit often, that textures get placed 0.5 pixel shifted in the coordinate system because the notation, where the center of pixel is exactly located, looks a little bit different e.g. in OpenGL than in traditional pixel array processing. this may cause very similar looking issues in practice.

... It also means that when you work with RAW or 4:4:4 sources you won't have this issue (eg. when you export ProRes master).

Good to know, Andrew. I usually shoot in raw 3:1 and sometimes ProRes 444/XQ on the URSA Mini 4.6K. Unfortunately the BMPCC4K doesn’t offer any 12bit ProRes, so I can shoot in raw 3:1 and master in ProRes 444 from the originals as a best practice.

Raw is a pain in post, but I’ll continue to use it unless I desperately need media economy and the wider angle of view with in-camera downscaling from 4K to HD that is only available shooting ProRes.

Bryan, with these conclusive screenshots that clearly illustrate the results, I think your actions have redeemed your spoken word. Everyone here is trying to be helpful and respectful as best they can.


Sent from my iPhone using Tapatalk

Raw is a pain in post, but I’ll continue to use it unless I desperately need media economy and the wider angle of view with in-camera downscaling from 4K to HD that is only available shooting ProRes.

Cineform RAW shows that it doesn't have to be. It can be best of both worlds format- easy to preview, edit and offer best possible quality. It's just Cinema DNG which is painful.

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.

It means problem is with YUV->RGB conversion (so during source import), which makes perfect sense as this is the stage where you interpolate 4:2:2 to 4:4:4. Generated bars goes only through RGB->YUV during export.

That's what puzzled me though. The first export was, necessariliy, re-imported onto the timeline to generate the histogram. So if the problem is on import, you'd expect to see evidence of it there. Or else the degradation was just too weak at that point to be visible. Didn't really have time for further examination late last night (hence the hasty crop on the compiled histogram image). I was just alarmed at how blatant the cumulative degradation was and thought it justified immediate posting as clear visible evidence. We assume that BMD read these posts, but since there's been no feedback we are in the dark about their perspective and action on this. Just hope we see it fixed in the next update.

Another reason I didn't do any metric tests was because I wasn't certain what could serve as a valid reference. Probably not the first Uncomp. 10-bit 422 export as then it would be impossible to determine if some degradation was already occurring. Maybe export the Color Bars to Uncomp. 10-bit RGB (r210), convert (with FFMPEG) to 10-bit 422 (v210) and use that as an independent reference ? Tried that briefly but couldn't get the conversion command right.

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.

i would argue, that this issue is already visible in your initial export as a vertical line of one pixel width:



this kind of artifact doesn't have to be present at this particular position, but it looks like caused by a kind of image refinement resp. uncommon color subsample smoothing, which seems to be deliberately handled by resolve in this manner.

Not sure I fully understand, but you're suggesting then that the worsening 'chroma degradation' as perceived, could actually be the accumulated by-product of a deliberately applied chroma smoothing alogorithm ? If so, yikes !

Edit: Incidentally the uncompressed frame images I put up on Imgur were generated by loading the 10-bit 422 avi exports into VDub2 and copy/pasting (via clipboard) the source frame into Paint.net to save as a PNG image. I trust that was a valid method ?

Bryan, with these conclusive screenshots that clearly illustrate the results, I think your actions have redeemed your spoken word. Everyone here is trying to be helpful and respectful as best they can.

I do mean well.

But it's always a good idea to have a basic grasp on what's going on in both directions.

The 'is it luminance or luma ?' query is one that invariably crops-up at some point for other programs also, not just Resolve. And especially when the terms appear to be applied interchangeably on the color tools and scopes - sometimes throwing 'Value', 'Sum' and 'Luminosity' into the mix, just to confuse users further (don't go there !). Some of the linux editing programs, like KDenLive, fall foul of that. More often than not they will simply inherit the expression that came with the filter supplied upstream by MLT with little or no attempt at standardized terminology and definition.

Resolve, thankfully, is consistent (I think ?) in it's use of the term 'luminance' and 'Y', so I think it's best (less vexing anyway) to accept that that is what it 'represents' in the tools and on the scopes, however derived.

Not sure I fully understand, but you're suggesting then that the worsening 'chroma degradation' as perceived, could actually be the accumulated by-product of a deliberately applied chroma smoothing alogorithm ? If so, yikes!

sorry - i know, my postings are always ver confuse and hard to decipher, and it's indeed a very complicated topic, where i also have to refresh my memory and to look up in references sources, and not all my ad hoc presumptions prove to be true.

but back to the topic:

as Hendrik Prosa already mentioned color subsampling may indeed utilize some filtering tricks to overcome very unpleasant visual effects, which only appear, if a specific pattern resp. frequency dominates in some regions of your image. it's very similar to moire patterns. the mentioned filtering techniques help to reduce this issue, but they also entail always some side effects and make it in fact impossible to translate or verify the correctness of isolated pixels and their values by a simple formula between RGB and YCbCr in a precise manner.

more about this aspect and some helpful illustrations:
http://www.glennchan.info/articles/tech ... hroma1.htm
http://www.glennchan.info/articles/tech ... omata.html

another complication arises by the fact, that some color subsampling variants do not use the the same location for the Y and Cb,Cr information. in one of the poynton publications you'll find a nice illustration concerning this topic:



but as much as i like all the profound informations from charles poynton, they are unfortunately very often a little bit outdated. i'm therefore not sure, if more recent digital video standards and file formats still require this horizontal shift in 4:2:2 or changed to a sample position arrangement, like you'll find it in 4:2:0?

i personally really abhor all this insane mysteries of legacy broadcast tradition. wherever ever possible, i therefore choose more intuitive and convincing approaches. and in this particular case, the actual realization in 4:2:0 looks much more plausible and processing friendly to me.

Thanks for the clarification Martin. So if chroma 'filtering' of this nature does turn out to be the culprit, one would expect YUV 4:4:4 not be affected, which Andrew confirms is the case. That's consoling at least.

Sure wish BMD would give some feedback on this, even if only to confirm whether this is a bug or not and they are looking into it. Here we are playing at Sherlock Homes trying to piece together the puzzle, when the puzzle-makers are in the room.

i personally really abhor all this insane mysteries of legacy broadcast tradition. wherever ever possible, i therefore choose more intuitive and convincing approaches. and in this particular case, the actual realization in 4:2:0 looks much more plausible and processing friendly to me.

I agree, but I would want to go one step further: there is absolutely no reason at all to stay with this subsampling idiocy in the 21th century. Use YUV 444 and leave it up the codec to compress the UV more than the Y channels if it deems it perceptually appropriate.

Sure wish BMD would give some feedback on this, even if only to confirm whether this is a bug or not and they are looking into it.

I fully agree!

I agree, but I would want to go one step further: there is absolutely no reason at all to stay with this subsampling idiocy in the 21th century. Use YUV 444 and leave it up the codec to compress the UV more than the Y channels if it deems it perceptually appropriate.

as much as i agree with you on an emotional level, i still have to see the pragmatic consequences resp. practical needs.

4:4:4 resp. RGB isn't very compression friendly. the general idea behind all the YUV variants and color subsampling therefore still makes sense. i would even go as far and argue, that it is often more useful to work only with downscaled footage from relative cheap cameras [and software], even if it is indeed affected by very simple and insufficient color subsampling in original resolution, than looking for even worse affordable equipment offering 4:4:4 compromises and more or less outdated codecs.

and if you argue: "just leave it up to the codec", you still have to consider the constraint, that the codecs on both ends of the communication line should handle the processing (i.e. encoding and decoding) in exactly the same way to get satisfying results. but that's unfortunately not always the case...

Thanks for the clarification Martin. So if chroma 'filtering' of this nature does turn out to be the culprit, one would expect YUV 4:4:4 not be affected, which Andrew confirms is the case. That's consoling at least.

Probably comes as no surprise to confirm that Uncompressed 8-bit YUV 422 shows the same pattern of generational degradation.

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.

Well, I took the plunge and rolled back starting at version 14.3. I can confirm that this serious 'bug' (which it most definitely is) first appeared in 15 beta 1.

Well, I took the plunge and rolled back starting at version 14.3. I can confirm that this serious 'bug' (which it most definitely is) first appeared in 15 beta 1.

that's indeed an interesting finding!

Well I figured it was the only way to determine that this is indeed a new behaviour and justification for calling it a bug. Plus I'd just watched a documentary on Elon Musk which left me in a mood for serious 'risk taking' I did however take the precaution of making a full system back-up before rolling back.

You've probably seen that I saw fit to raise the issue in a separate thread:

http://forum.blackmagicdesign.com/viewt ... 63#p438034

Might I suggest that any further dialogue on the subject continues there ?

I agree, but I would want to go one step further: there is absolutely no reason at all to stay with this subsampling idiocy in the 21th century. Use YUV 444 and leave it up the codec to compress the UV more than the Y channels if it deems it perceptually appropriate.

as much as i agree with you on an emotional level, i still have to see the pragmatic consequences resp. practical needs.

4:4:4 resp. RGB isn't very compression friendly. the general idea behind all the YUV variants and color subsampling therefore still makes sense. i would even go as far and argue, that it is often more useful to work only with downscaled footage from relative cheap cameras [and software], even if it is indeed affected by very simple and insufficient color subsampling in original resolution, than looking for even worse affordable equipment offering 4:4:4 compromises and more or less outdated codecs.

and if you argue: "just leave it up to the codec", you still have to consider the constraint, that the codecs on both ends of the communication line should handle the processing (i.e. encoding and decoding) in exactly the same way to get satisfying results. but that's unfortunately not always the case...

I agree that for delivery codecs it may take some time to make things compatible with consumer devices, but not for camera and mezzanine codecs.

However, things are encouraging, raw is becoming more mainstream and completely avoids chroma subsampling nightmares. With the introduction of BM Raw, which can compress up to 1:12 we have another step in the direction of removing chroma subsampling completely.

In the digital age lot of headaches can be removed from the industry: progressive replacing interlaced, raw or YUV 444 replacing chroma subsampling and floating point capable CODECs replacing data and video levels etc.

Turing (and Pascal if I'm correct) based cards support YUV 444 10/12bit h265 decoding also. So chain is closing.

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.

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".

Hahaaaa! After painstakingly quoting 2 contributors, then instructing one to "drop it", how hilarious a hyperbole hypocritically hurled from heightened hypersensitivity!

Nice, thank-you for that

However, things are encouraging, raw is becoming more mainstream and completely avoids chroma subsampling nightmares.

Ironically, bayer grid sensor sampling (which is usually preserved in raw formats) can be seen as a form of chroma subsampling.

However, things are encouraging, raw is becoming more mainstream and completely avoids chroma subsampling nightmares.

Ironically, bayer grid sensor sampling (which is usually preserved in raw formats) can be seen as a form of chroma subsampling.

True, I gladly await the day we will have "normal" RGB sensors, so we can do away with the aspirin against all these de-bayering headaches.

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.

I believe I posted about this quite some time ago. But the problem is that transforming a Y'CbCr 4:2:2 or 4:2:0 signal to RGB requires some sort of upsampling algo and similarly a downsampling algo on export. BMD has never to my knowledge revealed what sort of algo that they use (bicubic? lanczos? nn? AA? etc). I even asked. To me this is the biggest unanswered question. I guess they consider it proprietary. Only under the most restrictive conditions can upsampling be lossless. There is a lot of jabber in this thread about round tripping btw Y'CbCr and RGB. Perhaps some facts are in order:

1. DR operates in RGB floating point and performs a lossy conversion (there is a caveat here with 4:4:4 Y'CbCr content, but I have never been able to test it).
2. Floating point means that DR preserves out-of-gamut values when ingesting Y'CbCr content. Of course, there is no way to display these values on an RGB display, but at least DR doesn't clip them internally, thereby leaving it to the colorist to apply their own clipping/soft knees as they see fit. This is a big selling point of DR and means the lossiness is primarily in the upsampling/downsampling which affects all images differently.
3. If one works with RGB image sequences then the DR pipeline is lossless (or really, really close).

So, based on these facts, I don't believe there is any "special sauce" about the DR RGB color science. Otherwise, the RGB pipeline would likely not be lossless. Rather it seems to all come down to how the color wheels behave.

my two cents anyway

Yes, but in all v15 there is simply a bug with red channel and this is the problem (which is not in v14.3 which Bryan verfied). Get some source file with some red edges, export to v210 over 5 generations. Then compare it against 1st generation (not even source). You will see what the problem is about.

Once it's fixed we can come back to testing YUV->RGB->YUV conversion quality.
In order to do it well you need very sharp scaler, so not Bicubic etc, but point (specially when you don't want to process image in any way and export back to 4:2:2) or sinc with many taps.

Note: out of gamut errors "disappear" after 1st generation, so you can easily remove them from equation.

In order to do it well you need very sharp scaler, so not Bicubic etc, but point (specially when you later keep same export resolution) or sinc with many taps.

I am a little bit confused why you would call point resize very sharp.

Point resize has advantages in that it is lossless (you can upscale with a point resize and then downscale without losing anything) but I would call it anything but sharp.

And this is exactly why it's "sharp" (has no ringing, no "smoothing"- it's pixel perfect) and what you need for chroma sampling for direct conversion.
This is exactly a reason why vapoursynth or avisynth allow you to specify different resizing kernels for Y and UV channels and using point for UV is recommended method for chroma scaling (for direct conversions).

And this is exactly why it's "sharp" (has no ringing, no "smoothing"- it's pixel perfect) and what you need for chroma sampling for direct conversion.
This is exactly a reason why vapoursynth or avisynth allow you to specify different resizing kernels for Y and UV channels and using point for UV is recommended method for chroma scaling (for direct conversions).

I see what you mean by sharp now!

And I agree that you should use point for UV.
However, it won't solve any color bleeding.

Yes, but in all v15 there is simply a bug with red channel and this is the problem (which is not in v14.3 which Bryan verfied)

Guys, I made a mistake - it is present in 14.3.

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=79163&p=439026#p439026

Really sorry, but I ran some further FFMPEG tests also:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=79163#p439082