Colour Requirements/Functional specification
Author	Lane Roberts	
Contributors	Simon Chisholm, Martin Tasker, Jeremy Wakefield	
Date	8th December 1997	
Revision	1	
Distribution	Symbian Ltd.	
File	\\Sentinel-main\src_era\bitgdi\dspec\ColourSpec.doc	
Contents
Colour Requirements/Functional specification	
Contents	
Document history	
Glossary	
Introduction	
Requirements	
Functional spec	
Timescale estimates	
Omissions	
Discussion	

Document history
Date	Revision Version	Description	
8/12/97	1	First version of document	
10/12/97	1.1	Removed CONE references as no work should be necessary	
9/4/03	1.2	24 bpp unpacked video mode added – EColor16MU	
Glossary
BITGDI	The screen and bitmap specific graphics drawing component	
BMCONV	Program for converting bitmaps between Symbian and Windows formats	
CRT	Cathode Ray Tube - TV style computer monitor	
Ecolor16	Symbian display mode using a 4 bit index into a colour palette	
Ecolor256	Symbian display mode using an 8 bit index into a colour palette	
Ecolor64K	Symbian display mode using 16 bits to represent an RGB value (5,6,5)	
Ecolor16M	Symbian display mode using 24 bits to exactly represent an RGB value (8,8,8)	
Ecolor16MU	Symbian display mode using 24 bits to exactly represent an RGB value (8,8,8). 32 memory bits are occupied.	
Egray256	Symbian display mode using 8 bits to represent a grey value (0-black, 255-white)	
EIKON	Policy-dependent graphical controls component	
FBSERV	Font and Bitmap server - handles loading and storing bitmaps and fonts	
FORM	Text formatting component	
Gamma correction	A scheme to compensate for a display’s non-linear voltage to intensity ratio	
GDI	The common abstract graphics classes component	
High-colour	Common display mode using 15/16 bits to represent an RGB value (5,5,5/5,6,5)	
LCD	Liquid Crystal Display - Laptop style computer monitor	
Netscape	A popular Web browser	
NextStep	A Unix-based operating system	
RGB	Three byte value specifying components of a colour (Red, Green & Blue)	
TRgb	Symbian class representing an RGB value	
True-colour	Common display mode using 24 bits to represent an RGB value (8,8,8)	
WSERV	Window server - handles multiple application UI events	
Introduction
The aim of this project is to provide EPOC32 support for colour display devices.  This requires work at a number of levels - from supporting colour bitmaps through to “colouring” the built-in applications.  Whilst most interfaces support the notion of a full-colour “RGB” value, currently there is no code for displaying anything other than four and sixteen shades of grey (including black & white).  This project aims to implement colour support in such a way as to be transparent to applications and EPOC32 components not directly involved in the project.
Requirements
The primary requirement is to allow the user to specify the use of a particular colour, as described by a TRgb, and have that colour rendered on a machine’s display device as closely as possible to the colour specified.

A related requirement is to allow arrays of colours to be stored as bitmaps and displayed at a later date in the same manner.  It should also be possible to import colour bitmaps from a PC.

The policy-dependent layer of EPOC32 - EIKON - should use colour in its display of controls and allow the user to change those colours, storing the user’s current “palette” of control colours.
Functional spec
Required functionality categorised by component:

GDI - Provision of TRgb functions for handling EColor256, EColor64, EColor16M and EColor16MU display mode colours, based on fixed palettes, is desirable.

BMCONV - Allow conversion between windows bitmaps and Symbian bitmaps in any of the available display modes and back again (the framework for this is already in place).

FBSERV - Extend support for loading, saving and reading from bitmaps to include EColor16 and EColor256 modes.

BITGDI - Support for drawing to bitmaps (class CFbsBitmapDevice) in EColor16 and EColor256 modes.  Support for drawing to screen (class CFbsScreenDevice) in EColor16 and EColor256 modes in the appropriate platform format (hardware-dependent screen device drivers).  EColor16 mode should use an EGA palette consisting of the three primary colours and the three secondary colours in full and half brightness along with four shades of grey (including black & white).

WSERV - Allow clients to use CFbsScreenDevice objects of the appropriate mode for the hardware present.

FORM - Support for colour usage in FORM classes.  (This shouldn’t require any extra work.)

EIKON - Allow applications and users control over the colours used for drawing UI elements.

Applications - Support for colour usage generally.
Timescale estimates
Timescales estimated by component:

GDI		- ½ week

BMCONV	- ½ week

FBSERV	- 1½ weeks

BITGDI	- 3 weeks

WSERV	- 4 weeks

FORM		- ½ week

EIKON		- 4 weeks

Applications	- Beyond the scope of this project

Total		- 14 weeks
Omissions
Variable palettes.  Commonly supported colour schemes offer variable palettes for 16 and 256 colour modes.  This enables (at least for 256 colour systems) applications to approach a more realistic display of images imported from high- or true-colour systems.  This functionality is unnecessary at this time.

Gamma correction.  Given that our primary targets are hand-held devices with LCD, gamma correction would seem to be overkill as far as this project is concerned.  It is really only appropriate for WYSIWYG CRTs and high-end laptop LCD displays.

Dithering.  There are many dithering schemes possible that can give some improvement on the colours available.  They operate on a per-pixel basis and can slow drawing code down dramatically.  As such they are not considered appropriate for this project.
Discussion
Schemes for colour implementation

Both 16 and 256 colour modes use a hardware palette.  The main choice to be made for the low-level is whether this palette is fixed or variable.  To retain acceptable clarity of display EIKON would require a number of colours to be guaranteed present.  This could be accomplished in one of two ways.  Reserve a fraction of the palette entries for the system, or have the whole palette fixed.

The first choice gives the user more power to display imported pictures more accurately because they can find the n (where n is the number of non-system palette entries) most common colours in their picture and set the palette appropriately.  This is generally of use to picture viewer programs, although some interesting effects can be produced by animating the palette (of interest to games programmers and the like).
The second choice simplifies the low-level colour support design and reduces the development time of such a system.  Given the minuscule size of a 16 colour palette it would seem more appropriate to simply use the EGA colour palette anyway.  This consists of the three primary and three secondary colours at full and half brightness along with black, white and light & dark grey.

As for 256 colours, the Netscape Web browser uses the “Netscape colour cube” [http://the-light.com/colclick.html] on 256 colour systems to give a generally acceptable default palette with a good distribution of colours that will make most pictures recognisable, if not photo quality.  This consists of all combinations of component values increasing in steps of 51 from 0 to 255.  This gives a 6x6x6 colour cube, i.e. 216 colours.  The remaining spaces could be filled with more grey shades or possibly more green/lighter colours as the eye is more sensitive to these shades.  To experience this with Netscape or Internet Explorer, set your PC display mode to 256 colours and surf the web.  The 40 extra colours could be composed of 10 extra greys to make a total of 16 grey-shades (including black & white) and 10 extra each of the three primaries.  This scheme works well because it uses the values 0x11, 0x22, 0x44, 0x55, 0x77, 0x88, 0xaa, 0xbb, 0xdd and 0x33 which complement the 6x6x6 values of 0x00, 0x33, 0x66, 0x99, 0xcc, 0xff.  Furthermore, if the palette is arranged properly then inverting a colour simply requires the inverting of its palette index.  This is achieved by centring the colours in the palette.  An example layout might be:

Colour range	Colours in range	
Extra Grey 1 (0x11, 0x11, 0x11), …, Extra Grey 5 (0x77, 0x77, 0x77),	5	
Extra Red 1 (0x11,0,0), …, Extra Red 5 (0x77,0,0),	5	
Extra Green 1 (0,0x11,0), …, Extra Green 5 (0,0x77,0),	5	
Extra Blue 1 (0,0,0x11), …, Extra Blue 5 (0,0,0x77),	5	
Netscape Colour Cube colour 0, …, Netscape Colour Cube colour 215	216	
Extra Blue 6 (0,0,0x88), …, Extra Blue 10 (0,0,0xee),	5	
Extra Green 6 (0,0x88,0), …, Extra Green 10 (0,0xee,0),	5	
Extra Red 6 (0x88,0,0), …, Extra Red 10 (0xee,0,0),	5	
Extra Grey 6 (0x88,0x88,0x88), …, Extra Grey 10 (0xee,0xee,0xee),	5	
Total	256	

Mapping an RGB value that exists in the palette to its colour palette index

With small palette sizes based on an algorithmic distribution such as the EColor16 and EColor256 palettes suggested above, it is possible to identify an RGB value as actually being in the palette.  Identifying component values characteristic of entries in the palette is very quick and of constant order with respect to palette size.  An example of this would be looking for RGB entries that have components that are all multiples of 0x33, identifying it as a member of the Netscape Colour Cube.

Mapping an arbitrary RGB value to a colour palette index

The use of a palette in a system where the user has the ability to request any 24 bit RGB value requires a palette mapping scheme.  This matches the requested RGB to the nearest available one in the palette.  One way to achieve this is to use a scheme such as the Colour Manager on Apple computers [http://devworld.apple.com/ngs/lpp/adrpub/docs/dev/techsupport/insidemac/AdvancedColor/AdvancedColor-393.html].

Create an inverse look-up table by generating a table of all 9, 12 or 15 bit RGB values and calculate all the palette indexes for them.  Then an RGB gets its components (R, G & B) truncated to 3, 4 or 5 bits and concatenated to form the table index and the matching palette index is used for that colour.  3 = poor resolution (too poor), 4 = okay resolution (probably acceptable), 5 = good resolution (perhaps too much).  3 bits for each component (9 bit RGB values) needs an inverse look-up table of 512 bytes.  4 bits for each component (12 bit RGB values) needs a table of 4 Kbytes.  5 bits for each component (15 bit RGB values) needs a table of 32 Kbytes.

E.g. for a 12 bit RGB inverse palette index lookup table
Blue	Green	Red	Palette index	
0x0	0x0	0x0	I0	
…	…	…	I1… I14	
0x0	0x0	0xf	I15	
0x0	0x1	0x0	I16	
…	…	…	I17… I254	
0x0	0xf	0xf	I255	
0x1	0x0	0x0	I256	
…	…	…	I257… I4094	
0xf	0xf	0xf	I4095	

In this case the 4096 palette indexes are not all unique and map onto the actual 256 colours in the palette.  This technique may “hide” colours that are close together (differ only in the least significant four bits of each component) but have exact matches in the palette.  However, the lookup time is O(1), not O(n) where n is the size of the palette, and the resolving power is equal to a palette of 4096 colours.  For exact matching of the user-defined RGB value UrUgUb the minimum value of Abs(Ur-Pr) + Abs(Ug-Pg) + Abs(Ub-Pb) would have to be calculated for all palette entries PrPgPb.  It could be argued that the Abs() should be replaced by squaring the differences.  This would then give more weight to palette entries that are closer across the three RGB components rather than ones that differ by more but only in one component.

E.g. User RGB = (250,250,250) (very light grey).  Closest palette entries are (255,255,255) (white) and (250,250,235) (very light yellow).  The first scheme could not differentiate between white and light yellow, whereas the second would choose white, which would seem the more appropriate choice.
However, squaring values would be much more costly than taking their absolute values, making this choice most undesirable.

Future EColor256 support

A possible problem with a fixed-palette 256 colour mode is that there may be a requirement for a variable-palette scheme in the future.  As most of the colour handling is internal this difference is only an issue where the details are exposed to the user.  There are functions defined in BITGDI:  CFbsDevice::PaletteAttributes(TBool& aModifiable,TInt& aNumEntries) & CFbsDevice::GetPalette() that could signify the presence of the “EPOC32 EColor256 default palette” by saying that it is not modifiable and returning NULL from GetPalette(), and telling the truth when the “EPOC32 EColor256 variable palette” is implemented.

EIKON level colour support

Colour usage in controls might be implemented in EIKON through a control enabling the selection of particular colours for individual controls.  Perhaps a file could contain defaults for a particular platform, stored in ROM.  Then if a user wants to change the colour of a control the EIKON server would store the changed options.  Resetting a control to its default colour would delete that entry from the EIKON array of changed options.  Controls could then call an EIKON function, providing an enum entry, requesting their default colour.  The array would be scanned and if no entry was found the ROM file would be scanned for the default.  The control itself could have black & white defaults built in for the worst case of not finding an entry for it in the ROM file.  This would support any cases whereby the control had been added at a later stage or it didn’t need colour support.  The enum values can easily be extended in future versions to accommodate new controls.

Gamma correction

Gamma correction is explained at http://www.cgsd.com/papers/gamma_intro.html.  An interesting site for checking gamma correction and hardware & software colour accuracy is http://colorcom.com/~colorcom/comput.html.  This site places dithered black & white rectangles next to grey rectangles and asks the user to step back 6 feet and decide which pair looks uniform.  This then gives an estimate of the gamma correction of the display used. Gamma correction won’t be addressed by this project as it is judged to be not important enough.  Also this site http://www.halted.com/online/cybermax.htm suggests that gamma correction for an LCD screen is more complicated than for a CRT, using a transfer-function more complicated than the traditional L = V ^ g, where L is light intensity, V is input voltage and g is the gamma value.  Gamma correction for a CRT basically involves raising the input values to the power of -g, thus cancelling out the gamma characteristics of the display device.  Gamma correction for an LCD would appear to be rather more complicated…

Other platforms

The web site http://members.aol.com/pdcchrisd/wce/wce20scrn.htm has some interesting screen shots, although they must have been taken as bitmaps from a PC emulation.