What does this mean for you?

Until a few years ago, the best an astronomer could hope for was an 8-bit frame buffer which supported pseudocolor and most applications were written to work with this colour model. Unfortunately, an application that wants to change the colour table has to be aware of whether it is using pseudocolor or directcolor and supporting both in the same application is not trivial--different X lib calls are needed for setting the colour tables in the two models and the way that images are formatted is different. This means that there are still plenty of application in use that display pseudocolor on a directcolor or truecolor display. Most modern hardware supports both pseudocolor and directcolor with a 24 bit frame buffer and you are typically given the choice of either 8 bit pseudocolor or 24-bit directcolor (or 24-bit truecolor--more on this later). But why not 24-bit pseudocolor I hear you ask--the answer lies in the the amount of memory required for the colour tables. For 8-bit pseudo-colour you need (assuming 8 bits per colour) 768 bytes (3$\times$256); for 24-bit directcolor you need the same but for 24-bit pseudocolor you would need a little over 40 Mbytes! (3$\times$2$^{24}$). So, how is it that direct-colour can give you 16 million colours with less that a Mbyte of colour table while pseudocolor need more than 50 times this to give you the same number of colours? Where's the catch?

Consider what happens when you want to change the colour of something drawn on the screen. When using pseudocolor you change the colour table entry addressed by the pixel value used to draw the object--only things drawn with that pixel value change colour. However, with directcolor this is not true--if, for example, you change the red colour table entry for the selected pixel value not only do the things drawn with that pixel value change but anything drawn with a pixel value with the same value in the red component also changes--and there are 65 thousand pixel values that satisfy this condition. The end result is that if you want to be able to change the colours of things without effecting the colours of anything drawn with a different colour you find that you are back to only 256 colours--exactly what you get with 8-bit pseudocolor (and for 1 third of the video memory).

So, for a typical astronomical image display application which enables you to adjust the colour table interactively you are no better off using a 24-bit display than you are with an 8 bit one. This is not quite true because most applications have some fixed colours and you can potentially use up fewer colour table entries for the same number of fixed colours.

Running X server has a "default visual" (and hence colour model) but may support the creation of other windows with other colour models. However, not all applications are capable of requesting a visual type other than the default. An important exception is applications written in tcl/tk which has a -visual qualifier that enables you to select the visual type when you start the application. One undesirable consequence of running applications with different visual types on the same display is ``colour flashing'' where as the focus moves to one application the display of others is garbled. This effect is only absent on very high-end hardware.

Many X servers allow the default visual type to be specified when they are started (sometimes indirectly by specifying the frame buffer depth--e.g. 8 implies pseudocolor while 24 implies truecolor). The choice of truecolor rather then directcolor for the 24-bit mode may, at first, sight seem surprising. The reason is that with 8 bits per colour component in the frame buffer and 8 bits per colour in the colour table you can load the colour tables so that every possible intensity is available simultaneously and applications can draw in every one of the 16 million different colours simply by drawing with the right pixel value. Since the colour tables can't be changed, all applications are guaranteed to have the full palette available--with a directcolor model the available pallet may have been reduced by some other application allocating entries for its own exclusive use. Unless applications are going to change the colours of things after they have been drawn--and most don't (animation of button presses and the like are done by redrawing with a different pixel value)--you are better off with truecolor.

To find out what visual types an X server supports, run xdpyinfo (part of the X software) and don't assume that you will necessarily get the same set if you start the server with a different default.

None of the above applies to MS Windows or NT (or Macs)--they handle colour allocation in a quite different way and may well exploit the capabilities of your video adapter rather better--after all it was probably designed to work with Windows from the start.