[Akronymus]

> (2 bits per color? how is that possible).

this is probably a rhetorical question, but lemme answer anyways: By packing the colour channels into a single byte. So, for example, you'd have RRGGBBAA within a single byte, for each pixel. Giving you 64 possible colours, with 4 steps of alpha.

Or if you don't need to have alpha, you could pack it even further down to RRGGBB in a byte, which leaves 2 bits left over for the next pixel. Via that, you can pack four pixels worth of colour data into 3 bytes: RRGGBBRR|GGBBRRGG|BBRRGGBB (italics for delineting pixels, vertical bars for delineting bytes)

The latter is a tradeoff between compression and a more complex accessing pattern.

A bit of a tangent, some system used RRRGGGBB for colours, because the eyes are the least sensitive to differentiating the amount of blue, so that's another way to use up a full byte per pixel.

https://en.wikipedia.org/wiki/Color_depth

[ventana]

So, first of all, of course, a rhetorical question. Modern interns will probably assume at least 4 bytes per pixel (R, G, B, and A).

But the original post actually talks about CGA [1] with just four colors. Encoding a color needs two bits then, so each byte encodes four pixels.

[1]: https://en.wikipedia.org/wiki/Color_Graphics_Adapter

[Akronymus]

Oh right. Guess the " (2 bits per color? how is that possible)" is what threw me off there, because I read it as 2 bits per colour channel, rather than cga colour. Of course, "indexed" colours can get away with much fewer bits.

[consp]

A modern example of odd color schemes is 18bit color which is still often used in small cheaper displays (666/18bit vs 565/16bit) keeping the maximum color space available for all colors on these displays. If you are lucky you only have 16bit bus available and also need to do 3:2 packing, but that allows you to use 24bit in code and ramming the bytes in sequence over the 16bit bus without any modification (since they ignore the extra two bits per color).