tle. A CCD imaging device can produce 3-megapixel image at 24 bits per pixel. Consider sending these at a frame rate of 15 frames per second and you have a recipe for disaster. The image can be compressed and/or the frame rate can be slowed down. Interestingly, with fast-moving action (which looks better with faster frame rates) we become less sensitive to colour depth. Table 7.1 shows how we can exploit this. In this example, frame rate is increased but colour depth is reduced from 10 bits to 8 bits (and processor clock speed is doubled). Note also how frame rates can potentially increase with decreasing numbers of pixels. 6http://library.forum.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-D56F2920 1302-4D62-8B39-06C677EC2CE1.html. Device-Centric Software Table 7.1 Pixel resolution and frame rate Frame rates at 10 bits versus 8 bits per pixel output Example 10 bits (@ 16 MHz) 8 bits (@ 32 MHz) 1280 X 1024 1024 X 768 800 X 600 640 X 480 320 X 240 This gives us a wider range of opportunities for image scaling. The problem is to decide on proportionate user 'value' as quality increases or decreases. Table 7.2 shows as a further example the dynamic range of colour depth that we can choose to support. The M-PEG 4 core visual profile specified by 3GPP1 covers 4- to 12-bit colour depth. 24-bit is generally described as high colour depth and 32-bit colour depth is true colour. 32-bit is presently only used for high-resolution scanning applications. Similarly handset hardware determines (or should determine) downlink traffic. There is not much point in delivering CD quality audio to a standard handset with low-quality audio drivers. There is not much point in delivering a 24-bit colour depth image to a handset with a grey-scale display. There is not much point in delivering a 15 frame per second video stream to a display driver and display that can only handle 12 frames per second. Intriguingly, quality perceptions can also be quite subtle on the downlink. Smaller displays can provide the illusion of