Handling Colours

# Original WBench and Intuition was based on pen-based gfx, that is the colours were identified by pen rather than by their colour value (hue or whatever.) e.g. pen 5. There was a 'palette' or colour lookup table to translate from pens to colour vaues.

# A great feature of the Amiga (which must *not* be compromised) is that these CLTs could be changed *very* fast.

# One problem with this approach is that icons and background WB pix, which were based drawn in one colour came up different colours when the user had a different palette in operation. Sometimes this looked foul - though soemtimes interesting ;>).

Colour-based Gfx

# For a lot of arty work we need to identify colours by colour value rather than by pen number. Now there is a fashion for arty WBench/Windoze screens (for how long, I wonder, will it remain a fashion?) it is important that the colours seen on WB are those intended by the original artist, not the user. Similarly, for Web pix.

# As I understand it, MUI was an attempt to handle this problem, in that it tries to match the colours of the original incoming pix or icons to the palette it has available, finds for each pixel what colour it was, finds the pen with the nearest colour and writes the pixel in that pen and, if necessary, making small adjustments to the palette being used. (Am I correct?) I understand ClassAct is similar.

# Of course, WB3 already does this to some extent for WBPatterns, in translating their pens to lie in the range 4..(max-4).

# Therefore the issue that needs to be addressed in taking the Amiga forward is to offer, as part of the OS, well-designed routines (libraries) for colour-value handling. (e.g. colourvalue.library).

# In my view, this could and should go way beyond what MUI etc. offers. Not just colour matching and finding the right pens, but having routines to combine and mix colours, and all kinds of things that paint packages do with colour.

# Also, it seems to me that WB3's idea of mapping into certain restricted ranges of pens is important. Widen the concept a bit and it gives the idea of, in any given palette, ranges of pens for certain *purposes*. This seems to me to be a useful concept - the mini-palette for a given purpose - that should be given explicit OS support in future. More on that another time.

# But what it means is that the Amiga should not just take MUI/ClassAct on board as a standard, but - in the tradition of all good Amiga development - rethink its basics, and provide something two jumps ahead of even MUI.

HAM Mode

# Note that the Amiga's HAM mode is, and always has been, an attempt Šat colour-based gfx. In that sense, it is an important technical Šfeatures, though maybe now overtaken by 24-bit gfx.

# In HAM, the numeric values we give to pixels are not those of pen Šnumbers but of actual colour values (or, rather, components thereof).

# While it might be that, with 24bit gfx, the days of HAM are Šlimited, I believe it is still of importance for this reason.

# Part of its importance is that it gave explicit recognition to Šcolour-based gfx in the *hardware*. And, at the same time, attempted Što address directly the issue of compression in a way that (unlike ŠRLE) allowed direct, fast access to individual pixels.

# I believe that HAM should be expanded.

Need for Control

# One final issue: Control. MUI/ClassAct/WBPattern etc. Š'intelligently' alter the palette to yield the colours needed. But I Šsometimes find that a nuisance.

# For instance, in playing MUD game its text comes across as ANSI Šcolours, and I find that the various pens used are at the mercy of Šthis 'intelligence', resulting in almost unreadable low-contrast text.

# In some cases (not all of them frivolous like MUD playing) there is Ša need for the user to be able to control pen colour values directly.

Pen-based Gfx

# It is still important, however, to retain pen-based gfx. Because not all situations need, nor even want, colour- Šbased gfx.

# There is a difference between:

photographic images, and
diagrams.

Photo images are direct analogues of the real world and so the actual Šcolours are important. Hence they demand colour-based gfx. Diagrams are symbolic, and what is important is the Šdifferentiation of colours and visual forms to convey meaning clearly. ŠThus the actual colours used do not matter so much, and pen-based Šgfx is usually more appropriate.

# The fact that pen-based gfx is technically less Šdemanding of hardware technology, and thus came earlier in the history Šof computers, does not make it any less advanced. Nor does it make Šthe later colour-based gfx any more advanced. They are Šdifferent, and each hs advantages over the other for different Špurposes.

# Therefore both should be well supported in the future Amiga.