LWN: Comments on "Video4Linux2 part 5a: colors and formats"

Video4Linux2 part 5a: colors and formats

marcolwn — Fri, 08 Jul 2022 13:56:28 +0000

some links are broken, here are the internet archive links:

Colorspaces
https://web.archive.org/web/20120505053358/http://v4l2spe...

YUV Formats
https://web.archive.org/web/20120505061759/http://v4l2spe...

a little more information about JPEG
https://web.archive.org/web/20120505053919/http://v4l2spe...

Reserved Format Identifiers
https://web.archive.org/web/20120505060756/http://v4l2spe...

Field Order
https://web.archive.org/web/20120503220250/http://v4l2spe...

Video4Linux2 part 5a: colors and formats

jimparis — Fri, 02 Nov 2007 21:15:59 +0000

I believe the BA81 pattern is incorrect (the greens should be staggered, in a checkerboard
pattern).

Video4Linux2 part 5a: colors and formats

miku — Fri, 07 Sep 2007 11:04:46 +0000

Various links to v4l2 spec seems to be broken.

__u32 pixelformat:

roelofs — Wed, 31 Jan 2007 04:06:59 +0000

the fourcc code describing the image format

...stored in little-endian format (not native!), in case anyone else was wondering.

Greg

RGB332 doesn't look right

roelofs — Tue, 30 Jan 2007 22:14:50 +0000

That was a color problem from before I figured out which colors I really wanted to use.

Everybody's a critic, I know, but... I think it might work better to stick with a single shade for each channel and use a bullet or mid-dot or something to mark the most significant bit. (Are these made out of mini-tables? That was my assumption, but I haven't looked at the source yet.) I find the pale blue and pale green to be much more similar to each other than to the "regular" blue and green, to the point that the very first case (light blue, dark blue, light green, ...) looks more like a single bit on a pale background than a two-bit grouping followed by a three-bit one.

To put it another way, the grouping of same-color bits is more important information than which individual bit is most significant, but the extreme paleness of the MSBs makes them the most visually striking part of the diagrams. (IMHO. :-) )

Thanks,
Greg

color spaces, whee!

roelofs — Tue, 30 Jan 2007 22:03:31 +0000

This colorspace also covers the set of YUV and YCbCr representations. This representation derives from the need for early color television signals to be displayable on monochrome TV sets.

Well, that's one (techno-historical) way to look at it... But perhaps more accurately, it derives from the physiology of the human eye, which basically has YUV- or YCbCr-like sensors in it. The fact that YUV/YCbCr better lend themselves to certain compression tricks (even lossless ones, which is still sort of amazing to me) plays a role, too.

Conversion between YUV and RGB is not entirely straightforward, however; there are several formulas to choose from.

Heck, conversion between RGB and RGB isn't entirely straightforward, either. Aside from "gamma" (~brightness/contrast), which most of us are vaguely aware of, there are a whole host of other, interlinked concepts involved: chromaticity, white point, color temperature, gamut, surround (ambient background lighting), rendering intent, ... In addition, there are separate exponential transfer functions (~"gamma") for cameras, monitors, display cards (LUTs!), etc.; you need to know details about both the source and the destination devices, and often there are files in between. It's a complicated mess, and it's really easy to get some (or all) of it wrong. :-/

Greg

RGB332 doesn't look right

corbet — Tue, 30 Jan 2007 21:38:37 +0000

Hmph. That was a color problem from before I figured out which colors I really wanted to use. The bit wasn't gone, just hiding. Fixed.

RGB332 doesn't look right

roelofs — Tue, 30 Jan 2007 21:22:38 +0000

A red bit got away from me - they can be awfully slippery sometimes.

You lost another one: RGB0. (Damned bits... This sort of thing never used to happen when the MCP was in control.)

Greg

RGB332 doesn't look right

corbet — Sat, 27 Jan 2007 00:43:19 +0000

A red bit got away from me - they can be awfully slippery sometimes. I found another one and stuck it in.

RGB332 doesn't look right

tbird20d — Sat, 27 Jan 2007 00:29:17 +0000

In your diagram for the RGB332 format, there should be two colors with 3 bits of information, and there are only 2 (for a total of 7 used bits instead of 8 bits). I think this is an error.

Video4Linux2 part 5a: colors and formats

jwb — Thu, 25 Jan 2007 04:34:32 +0000

This excellent article reminds me of another excellent article, The Pixel Rosetta Stone: Packings and Colorspaces which is part of a much larger work, The Lurker's Guide to Video, which has been around for eons but remains somewhat obscure.