Why do most graphical things (e.g. games, windowing systems) operate at 32-bit colour? I've had a theory that colour can never actually go over 24 bit:

There are three colours in RGB - Red, Green, and Blue.
Each colour can be in the region 0 to 255. This makes 8 bits per colour.

Three colours * 8 bits each = 24.

Can anybody enlighten me on why 32 bit is used?

Because some windowing systems do translucency (alpha), games use translucency (alpha) all the time.

You can not do translucency without some form of alpha value, the A in RGBA/BGRA/ARGB/ABRG.

Oh yeah, you're probably right

Another thing is that 32bit is 2^5 and optimizing HW for such numbers is probably easier.

Also I think 32bit for (frame) buffer will be obsolete in a few years. Already most new games use FP16 per channel, in 3-4y FP32 might not be out of question. Thouhh I'm not sure if >=FP16 will be used in regular textures loaded from disk or not, probably not very soon.

Word alignment.

If gfx cards had used a HSV colour space we could have gotten away with 16-bit colour modes and textures (i.e. H=4, S=4, V=8). That would have given us a good speed boost for free.

Actually, that mode you mentioned is awful, compared for example to 16-bit RGB. Here is a utility (attached) that can convert any bitmap readable by allegro to look like it was in one of those formats (it'll still be 24-bit, but it'll use only the colours from the RGB16 or HSV16 colour spaces). We'd need less granularity for the hue part, that's for sure. Just test it on any photo or anything.

In other words, I don't think HSV 16-bit would really be better that RGB 16-bit.

EDIT: I tweaked with it a little. The program now supports HSV448 HSV547 and HSV646, but even the last one is much worse than RGB565 (you can see some blocks). Download the second attachment.

As gnolam said, gfx cards like aligned data. Also extra 8 bits can be used for one additional channel, which can be used to store alpha channel, gloss map, height map or any other single-channel data. This additional channel on the screen can be useful, too, especially during multipass rendering to achieve complex effects on old hardware (eg. per-pixel normalmapped lightning on GeForce 2).

It can. High dynamic range images often use 16 bits per color component giving 48 bits total, sometimes even using 16-bit floating-point numbers. This extra brightness allows to change scene exposure without losing quality. "Overflows" are usually converted to glowing areas during image post-processing, giving everything nicer look, especially on shiny and reflective objects.

You can assume constant alpha or get alpha from different texture.

32-bit framebuffer and texture formats won't be obsolete too soon, as 64-bit or wider pixel formats take considerably more bandwidth, which reduces fill rate. I agree that FP16 for textures won't be used too widely (except for skies) as 8-bit channels are doing well enough and reflectiveness (diffuse or specular) doesn't vary that much over the material to really need FP16 color formats.

Slow blending, texture filtering and pixel shaders would compensate this speed boost, probably making everything even slower.

Matrox G400 does, but it optionally combines the H&S from each 2 pixels to produce 8 bits each, which it uses for high quality TV output

Everything except fade_to_grey()

Hmm. ok. I'll take your word for it. I just remember reading that Jpeg and other image compression routines tend to compress the colourspace normally, so I didn't think the effect would be as noticable as RGB555.

Seems to me that 16 bits is 16 bits, that allows 65536 shades of anything, period. And none of you tried to program the SVGA modes with 24 bit color? You had to write a short int, then a char for some pixels, or a char followed by a short int for the other pixels. That all goes away with 32 bit or 16 bit, not to mention making sure you didn't run off the end of the 64k segment with 24 bit color.

Is that not "some form of alpha value"?

I don't follow, what exactly do you mean? 16 bit color is 565 (RGB) thats 5 bits red, 6 bits green, and 5 bits blue. Or sometimes 5551, 5 red, 5 blue, 5 green, 1 alpha. It's not "shades" its specific colors.

I think he means, regardless of what colorspace you use, 16-bits will never get you more than 65,536 colors. The different colorspaces will only determine which colors you get.

Though I'd think HSV would be a bad choice if you want a wide range of colors. You'll actually get fewer colors with HSV than RGB. 0,0,255 and 32,0,255 produce different colors in RGB, but in HSV they'd give you the same color. Since there's no saturation, the hue is completely ignored. same goes for 143,136,0 and 53,222,0.. in RGB those are two different colors, but in HSV, since there's no light (assuming V is the luminance), the hue and saturation are completely ignored. Any two different values for an RGB triplette will produce different results, but any two different values for an HSV triplette may not.

Ah yes, I was thinking of something like this which I found several years ago:
http://r0k.us/graphics/png16.html

This kind of thing really appeals to the amiga loving part of my mind!

As I understand it, sampling chrominance less frequently than luminance is also the way that all DVDs and even most commercial video editing formats work? And doesn't the Gamecube use a 16bit luminance/chrominance split framebuffer?

Yes, but it's not in RGBA, ARGB, BGRA or ABGR.

Modes like D3DFMT_G8R8_G8B8 will. In this case, each pair of pixels shares two channels and only one channel varies between them (green in this case). It still uses 16 bits per pixel, but gives you entire 24-bit color space (somewhat restricted, but still).

AFAIK V isn't luminance, but value. HSL has luminance and uses slightly different conversion methods.

The A in those are also "some form of alpha value".

That's right, it's because the human eye has less spatial resolution in chrominance than in luminance. Even analogue television takes advantage of this by squeezing the colour signal on to the higher bandwidth traditional monochrome (luminence only) signal.