The PGPLOT graphics package, which is used by Kappa, draws images and line graphics using a set of ‘pens’. The number of pens available is limited to 256, even on modern 16- or 24-bit graphics devices which nominally have ‘millions’ of colours. On older 8-bit graphics devices, the number of available pens may be fewer than 256 if any other applications have ‘grabbed’ colours for their own use.
Each PGPLOT pen draws in a single colour, but you can choose what that colour will be for each pen. This allocation of colours to pens is called the PGPLOT ‘colour table’. Each pen has a corresponding integer index within the table. On 8-bit graphics devices you can allocate any arbitrary combination of red, green and blue to a pen (each colour is specified as an ‘intensity’ in the range zero to one). On 16- and 24-bit devices you can only allocate one of the ‘millions’ of colours known to the graphics device. For instance, on 16 bit devices it is common to allocate 5 bits each to the red and blue intensity and the remaining 6 bits to the green intensity. This means that red and blue can only be set accurate to 1 part in 32 on these devices, which may result in colours not being exactly as you want them.
On an 8-bit device, any changes thatyou make to the colour table are immediately reflected in the visual appearance of the display. For instance, if you set Pen 1 to red, then draw something using Pen 1, it will appear red on the screen. If you then change Pen 1 to blue, the previously drawn graphics will immediately change colour without you needing to re-draw them. This is not usually true for 16- and 24-bit devices. That is, changing pen colours will usually have no effect on previously drawn graphics. In order to see the effects of the changed pen colour, you will need to re-display the graphics.
In many image procesing and visualisation systems the full colour table is used to draw images. This has the disadvantage that if you want to annotate images with captions or axes, plot coloured borders about images, plot graphs etc, yet simultaneously display images with certain colour tables, there may be conflict of interests. For instance, a linear grey-scale colour table’s first few pens will be almost black. By default, these same pens, particularly Pen 1, are used by the graphics system for line graphics, thus any plots will be invisible. If you reset colour Pen 1 to white, the appearance of your image alters. Whenever you alter the colour table to enhance the look of your image, it will affect the line graphics.
To circumvent this dilemma, Kappa reserves a portion of the colour table, called the palette, that is unaffected by changes to the rest of the colour table. It is shown schematically below. The palette currently contains a fixed 16 pens. n is the total number of pens. In Kappa the remainder of the pens is called the colour table. It is easy to confuse this use of the term ‘colour table’, with the PGPLOT colour table described above. To sumarize again, in Kappa the ‘colour table’ is that part of the PGPLOT colour table that has not been reserved for annotation (i.e. the whole colour table minus the first 16 pens which form the annotation palette). The context should usually make it obvious which understanding of the phrase ‘colour table’ is being used.
A list of colours to be allocated to each pen in the colour table is called a lookup table. Lookup tables comprise a series of red, green and blue (RGB) intensities, each normalised to 1.0; they may be stored in NDFs—indeed some are provided with Kappa—or be coded within applications.
A lookup table may be transferred into the display’s colour table. However, the number of pens in the colour table is usually not the same as the number of colours in the lookup table and so a simple substitution is not possible. Therefore, Kappa squeezes or stretches the lookup table to make it fit in the available number of colour-table pens. Normally, linear interpolation between adjacent lookup-table entries defines the resultant colour, though you can select a nearest-neighbour algorithm. The latter is suited to lookup tables with sharp boundaries between contrasting colours, e.g. a series of coloured blocks, and the former to smoothly varying lookup tables where there are no obvious discontinuities, e.g. spectrum-like.
Let’s have a few examples.
LUTHEAT loads the standard ‘heat’ lookup table into the colour table using linear interpolation,
whilst LUTRAMPS loads the standard coloured ramps using the nearest neighbours in the lookup
table. LUTREAD reads the lookup table stored in the DATA_ARRAY of the NDF called pastel and
maps it on to the colour table via linear interpolation. In the fourth example the lookup table in NDF
sawtooth is mapped on to the colour table via a linear nearest-neighbour method. ex tells LUTABLE to
read an external file. In the final example LUTSAVE saves the current colour table into a lookup-table
NDF called pirated. LUTSAVE is quite useful as you can steal other people’s attractive colour tables
that they’ve carelessly left in the display’s memory! It does not matter should the display not have a
palette, since
will save the full set of pens (including the first 16) to the NDF.
LUTEDIT provides a complete graphical-user-interface which allows colour tables to be created or modified in many different ways.
You can make a text file of the RGB intensities and use TRANDAT to create the NDF , or manipulate
the colour table and then save it in a lookup-table NDF. If you choose the second option remember
that all RGB intensities must lie in the range 0.0–1.0, where 1.0 is the maximum intensity; and that
equal red, green, and blue intensities yields a shade of grey. So for example if you want a six equal
blocks of red, blue, yellow, pink, sienna and turquoise you could create the text file col6.dat with
contents
and then run TRANDAT to make the NDF called collut6.
There is an interactive task called LUTEDIT for creating and editing lookup tables. The LUTEDIT command fires up a complete graphical-user-interface. This includes its own help system via a "short help" window at the bottom of the interface which describes the control currently under the pointer, and also via the usual "Help" button at the right-hand end of the menu bar.
There are four commands for controlling the palette (Section 14), all beginning PAL (in addition, the colours in the current palette can be listed using GDSTATE). If you inherit the graphics device after a non-Kappa user or after a device reset, you will probably have to reset the palette. You can do this either by loading the default palette—black, white, the primary then secondary colours, and eight equally spaced grey levels—with the command PALDEF; or load a palette you’ve created yourself via PALREAD. You modify the palette by changing individual colours within it using PALENTRY. The colour specification can be a named colour (see Appendix F for a list), or RGB intensities. For example,
would make palette index 1 sky blue and index 14 a pale yellow. Once you have a palette you like, save it in an NDF with PALSAVE.
Palette entry 0 is the background colour. By choosing a palette colour equal to the background colour, features may be ‘erased’.
PGPLOT re-initializes the palette and colour table each time it is started up, wiping out the colours you had previously selected with such care! For this reason, Kappa keeps a copy of the ‘current’ palette and colour table in a special file. Each time a graphics application is run, the current colour table and palette are read back from this file, and used to reset the pen colours in the PGPLOT colour table before any drawing is performed. Some application change the colour table or palette; PALENTRY, LUTABLE, etc.. When such applications terminates, they write the modified colour table or palette back to the file so that it will be used by subsequent graphics applications.
Separate palettes and colour tables are maintained for each known graphics device, so
running LUTGREY on an xwindows device will have no effect on the colour table used for
PostScript devices (for instance). The palettes for all known devices are stored in a file called
kappa_palette.sdf located within your ADAM directory (usually $HOME/adam). The colour tables
for all known devices are stored in a file called kappa_lut.sdf located within the same
directory.