How many colors in YCbCr JPEG under common conditions 3x8bits?

85 Views Asked by At

Aproximayly 1/3 volume of a cube is at this picture from wikipedia . For example, If Y = 0 or Y = 1.0 (255 of 255), than Cb and Cr can be only exact 0 (only one discrete from 256).

enter image description here

So does YCbCr JPEG have approximately 2^(3x8)/3 = 5.6M colors?

Or approximately 60% x 2^(3x8)/3 = 10M colors from this https://stackoverflow.com/a/30105358/21548659 ?

Also coefficients KR+KG+KB=1 are used for converting YCbCr to RGB. Does each one dicrete of Cb or Cr change one of the R or G od B by one discrete? How many colors will remain after the transformation from 3x8bits YCbCr to 3x8bits RGB display (that is common conditions)?

2

There are 2 best solutions below

2
On

The YCbCR colorspace as used in most JPEG file formats allows for 2^24=16,777,216 different colors.

The RGB color space that most JPEG files are converted from/to allows the same number of different colors.

However, the colors that can be represented in the two different color spaces is different so the practicable number of colors that can be represented in JPEG is less.

I have not done the exercise of counting but the way to do it would be convert all the possible YCbCR colors to RGB and count the number of colors that have an RGB value less than zero or greater than 255.

Then convert all the possible RGB values to YCbCR and make the same count.

Subtract those two counts from 2^24.

0
On

Short Answer

In practice, the measured histogram discrepancy with a 4:2:2 jpg is ~1%, therefore one would expect about 16,609,443 colors—this is mainly due to factors other than YCbCr, such as the DCT compression.

Longer Answer

The above value based on compressing using 4:2:2, and 100% quality. DCT artifacts are certainly part of the discrepancies. The measurement was using a histogram of the pure RGB image and compared to the 4:2:2 jpg, using DIFFERENCE transfer mode.

Some of the loss is due to the DCT algorithm, and some due to the spatial subsampling. That considered, the total colors would be no less than 16,579,244 to 16,642,998, but the difference is at worst effectively dithered. I.e. we are splitting hairs here.

Using Bruce Lindbloom's "every possible color" image, an uncompressed RGB array of all possible colors, exported to a jpg at 100% quality out of GIMP at 4:2:2.

Then importing as a layer and setting it to difference transfer mode, to find any differences between the pure RGB and the 4:2:2 jpg.

For the following examples, I cropped to a small area of the full image.

100% Quality, 4:2:2

The original:

RGB16MillionCLIPorig

The 4:2:2 jpeg laid on top, using difference mode:

RGB16MillionCLIP422DIFF

A histogram of that result (16bpc was used):

enter image description here

Expanding that 1% range to full range, to show the nature of the differences:

RGB16MillionCLIP422DIFFexpanded

Discussion

In playing with this, including using 4:4:4 and 4:2:0 variants, it appears clear the main cause of the variations is the DCT compression, not so much the YCbCr. Perhaps it's useful to point out: we are never viewing YCbCr, we are always viewing RGB, thus the YCbCr is only the intermediate encoding for storage.

For every color stored in YCbCr it must be converted to a color in RGB. The only question then regards "round trips" in and out. I.e. for any given RGB color, mapped to a given YCbCr color, come back out to the exact same RGB color?

Here this is the difference with a jpeg that was exported five times consecutively:

RGB16Million422pass5DIFF

And expanded to show the bottom 1%:

RGB16Million422pass5DIFFexpanded

The vertical bars are due to the 4:2:2 subsampling. But otherwise, the discrepancy is essentially the same. This is consistent with the fact that after the first pass through DCT at 100% quality, subsequent passes at 100% quality have minimal effect.

50% Quality, 4:2:2

For reference, here is the difference using a 4:2:2 at 50% quality:

RGB16MillionCLIP422QUAL50DIFF

In this case the histogram of the difference indicates up to 25% discrepancy:

enter image description here

And expanded for detail:

RGB16MillionCLIP422QUAL50DIFFexpanded

Conclusion

We are always viewing RGB.
There is no reason to think that the round trip RGB->YCbCr->RGB results in lost colors per se, assuming an appropriate reverse transform, and working in floating point (if working in int, some rounding may result in some round trip errors).

However, the addition of DCT compression and chroma subsampling certainly does add errors, the degree of which are largely dependent on the quality settings. The errors introduced due to DCT and subsampling are greater than those due purely to the color space transform.