Hacker News Reader

Comment by thesz | Hacker News Reader

The vast majority of time F-15 flies at subsonic speed. Converting it to propeller-driven design will save a lot of fuel and production and maintenance costs.

YUV format is lossy. The one that is twice as bandwidth-efficient as RGB records four times less color difference than full bandwidth YUV or RGB. Add to that that RGB often used with alpha channel and for half the bandwidth you will get twice the artifacts.

The subsampling scheme that is half of RGB is called 4:1:1: https://en.wikipedia.org/wiki/Chroma_subsampling#4:1:1

It is not broadcast quality. 4:2:0 is also not good for today's standards.

View on HN

You've missed the point. He isn't advocating for everyone to suddenly use JPEG where they wouldn't before. He's advocating that, since there are so many JPEGs already in use, the architecture for displaying them should avoid unnecessarily converting them into RGB 32bit, and instead display them without conversion in a YUV 420 format, to align with the internal encoding of JPEGs which is YUV 420.

Essentially, rendering JPEGs directly as a GPU texture (since GPUs can already natively use 420 encodings for textures). His point is that this would improve performance, very slightly improve quality, and reduce power usage as there's no colour space conversion.

Mathematically Y'CbCr is a lossless conversion of RGB. Practically there are some losses, though, especially if you use video-range.

4:1:1 is half of RGB but I've never seen anyone ever use it. Pretty much everything in use today (at the consumer level) uses 4:2:0. It's good enough for today's standards (AV1 Main profile only supports 4:0:0 and 4:2:0).

What’s 4:1:1? What people call 4:2:0 is actually 4 pixels of Y and 1 each of Cb and Cr.

Wikipedia has a decent article with visuals: https://en.wikipedia.org/wiki/Chroma_subsampling#Sampling_sy...

The difference between 4:1:1 and 4:2:0 is that in 4:1:1 the chroma covers a 1x4 line of pixels whereas in 4:2:0 the chroma covers a 2x2 square of pixels.

TIL. Thanks!

This is correct, with one subtlety.

YUV to RGB conversion (and vice-versa) requires use of conversion coefficients (BT.470, BT.709, etc): https://en.wikipedia.org/wiki/YUV

Different apps/algorithms can choose their own coefficients, so you get a slightly different RGB colors. If you converted RGB back to YUV with a different set of coefficients, you would get a different result.

JPEG specifies the matrix, I think it's the same as BT.470. It's fairly easy to guess the intent even if the metadata is missing (which, well, it usually is) - just have to know if the source is a video or not and then if it's HD or not.

>Mathematically Y'CbCr is a lossless conversion of RGB.

Assuming infinite precision, sure.

Interestingly however, there's a closely related color space called YCoCg, that actually does achieve lossless coversion to/from RGB (this lossless variant is often referred to as YCoCg-R, the R stands for "reversible"): https://en.wikipedia.org/wiki/YCoCg#The_lifting-based_YCoCg-...

Reply on news.ycombinator.com