By the way, the red out-of-gamut images was made with HighLightBadRGB():
It's not perfectly accurate (it delivers a few false positives and false negatives at the edges of the RGB cube) but good enough for quick test.
+ Reply to Thread
Results 121 to 128 of 128
These forumlas from https://en.wikipedia.org/wiki/YCbCr:
[Attachment 53295 - Click to enlarge]
Produce these numbers:
[Attachment 53296 - Click to enlarge]
I will plot this in Sketchup later.
This seems to show all the RGB ranges are captured within the YCbCr cube except the Red and Blue corners of the cube with values between 235 and 240. Green appears to be fully captured. However, it's pretty obvious the YCbCr cube has additional color possibilities. I believe that is what you were saying.
Yes, those equations conform to the rec.601 standard (note that high def video usually uses the rec.709 standard, which is a slightly different rotation). They are the same as the equations at the Intel.com page I linked to (aside from rounding). As you can see the max extents of Y are 16 and 235. And for U and V, 16 and 240. But those correspond to the furthest extents of the RGB cube, the corners. Many of the YUV coordinates that fall between those extents do not fall within the RGB cube. For example, at black, Y=16, the only valid U and V values are 128. A U/V value like 127 or 129 is slightly outside the RGB cube. A value like 240 or 16 is way outside the cube.
Indeed, the YUV space is not very intuitive. But there are some simple properties that you can exploit for things like white balance. I'll write about that later when I have time.
Last edited by jagabo; 13th May 2020 at 12:21.
For some reason, I was thinking we were losing color when converting from RGB to YCbCr, but I guess not. As you explained, the 235 ceiling is luma, not chroma.
[Attachment 53297 - Click to enlarge]
The RGB cuboid is just touching the YCbCr limits at Red, Blue, Black, and White... almost touching at Yellow and Cyan.
[Attachment 53298 - Click to enlarge]
I guess the standard was designed to match the RGB outputs of the cameras... However, in working with the videos, we seem to have the increased output range of 0-255.
The Sketchup file is available in the 3D Warehouse (https://3dwarehouse.sketchup.com/search/?q=grousehiker)
Last edited by GrouseHiker; 13th May 2020 at 17:24. Reason: Linked SketchUp file
A long time ago I would sometimes see gross errors where a pixel that should have been black "wrapped around" to white. Or a pixel that should have been white wrapped around to black. This is because of the way computers handle integer math. When you subtract 1 from an 8 bit unsigned integer 0 you get 255. Conversely, when you add 1 to 255 you get 0. If you add 2 you get 1, adding 3 gives you 2, etc. Most software now checks for these integer underflows and overflows.