# 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 ;>).
# 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.
# 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.
# 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.
# There is a difference between:
# 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.