Color basis for all video compression algorithms?

[jland]

I was once told, by a very informed person, that all video compression algorithms use gray as their base color. The gray color was supposed to be equivalent to Benjamin Moore's paint chip #1628. The point was that presenting a codec with this color meant that the codec didn't need to "work" to compress/decompress it.

I'm interested in getting thoughts about this, and whether or not this holds true for MPEG4?

(This same gentleman also indicated that the Benjamin Moore color "Autumn Sky" was the worst color to present to a codec (via camera) because it would cause a camera's iris to make minute adjustments - causing the whole "scene" to change and needing a complete retransmission of all the data in that scene.)

[cribbinsb]

This is not really true. In algorithms like H.261/H.263 the "DC component", or average colour, for each intra block is transmitted with the same number of bits (8) no matter what it is - so no colour is more difficult. More modern standards like MPEG4 and H.264 predict intra blocks from the colours of surrounding blocks in the same frame but again no level is particularly "special" or easier to send.

It is true that generally the darker the scene the worse the compression will look. This is not really due to the compression algorithm but due to the way the way the eye works - look up "luminance masking" on google if interested.

I don't believe the thing about "Autumn sky" either. However it is true that it is bad for the codec if the whole scene changes at once. Typically you can see this when the auto-exposure of the camera changes causing the brightness of the whole scene to change. Deltas need to be transmitted for every block to change the brightness which can cause visible artifacts.

[Yukikaze]

I was once told, by a very informed person, that all video compression algorithms use gray as their base color.

He could perhaps be referring to the fact that the mpeg like compression algorithms break a color image down into three components: luminance(greyscale) and two color difference components, as opposed to using RGB three component video for instance, where all components contain color information.

cribbinsb is exactly right about the DC component being the same for all blocks in a reference picture, so in the initial transmission you can get any base color at the same cost(the DC coefficient has to be transmitted in H.261 and H.263, not sure about H.264 there may be some kind of prediction taking place there).

However, once you start adding detail to the image(by transmitting additional coefficients), a greyscale source will only cause significant changes in the luminance component of the video, while a color source will cause changes in all three components. This can result in a greyscale source looking marginally "better"(except for the fact that it doesn't have color :) ) than a color source as all bits can be used to encode changes in one component rather than three.

Either way, if your camera is directed at any stable image, regardless of color or complexity, once the video has stabilized the transmitted data will amount to:

- skipped block indicators
- periodic intra blocks as required by the standards

This is the only "non-work" situation in a video codec system. Where the encoder believes it has coded the picture perfectly and therefore doesn't need to send any changes. The standards do not specify any initial zero state for a decoder, so the initial image, no matter how simple or lacking in color, has to be transmitted by the encoder as an initial reference picture.