Weird Lines in 8mm Captures

[jagabo]

By the way, the red out-of-gamut images was made with HighLightBadRGB():

https://forum.videohelp.com/threads/360935-Capturing-Correct-Chroma-and-Hue-Levels-Fro...e2#post2289672

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.

[GrouseHiker]

Regarding the Opti790 problem with running SeparateFields() twice... The script runs ok in AvsPmod. and MPC-HC, so I'm more convinced it is a VirtualDub. issue. Should I start a new thread on this issue?

That issue was reported as corrected here:

https://forum.videohelp.com/threads/396961-Weird-Lines-in-8mm-Captures/page4#post2582360

[GrouseHiker]

But not all combinations of YUV between those stated limits result in valid RGB colors. In fact, only about 25 percent are legal. If you look at the RGB cube inside the YUV cube you can see:


[Attachment 53291 - Click to enlarge]
https://software.intel.com/en-us/node/503873

The limits only correspond to the 8 corners of the YUV cube.

Thanks for that explanation... However that cube intersecting cube can look strange depend on how my brain orients the RGB cube. I had earlier searched for a Sketchup model of this, but didn't find one... would be nice to see this in actual 3D. Should be pretty easy to draw... I'll get back with that once I figure out the RGB coordinates of blue, red, magenta, cyan, and yellow!

[GrouseHiker]

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.

[jagabo]

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.

[GrouseHiker]

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)

[GrouseHiker]

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

What's the reality of moving into the "Forbidden" YUV white and black regions? We still perceive them as white and black?

[jagabo]

What's the reality of moving into the "Forbidden" YUV white and black regions? We still perceive them as white and black?

Yes. Unless the U and V channels are way off. For example, take a video with vivid colors and use ColorYUV(off_y=-256) to force all Y to zero. You'll still see colors in the more saturated areas.

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.