Expanding the "standard 16" colours

Colour selection in RISC OS generally leaps between two extremes: A full-blown 24-bit colour mixer, and the “standard 16” colours derived from the original RISC OS 2 palette. A standard set of colours is very useful, as they’re easy to select and keep track of, but having just eight non-greyscale colours doesn’t quite do the job. (No pink, no purple, no brown, no clardic fug…)

Therefore I propose some kind of style guideline, which adds more “standard” colours, perhaps going up to 32 in total. This would massively expand versatility, while still being far more compact and convenient than a colour mixer. Obviously, using these colours would be up to individual developers, but it would be nice to have some kind of consistent theme that becomes just as familiar as the original.

So you haven’t heard about 256 colour modes? Or about using a palette to allocate the 16 standard colours to other colours? (Originally the palette was in hardware.)

Therefore I propose some kind of style guideline, which adds more “standard” colours, perhaps going up to 32 in total. This would massively expand versatility, while still being far more compact and convenient than a colour mixer. Obviously, using these colours would be up to individual developers, but it would be nice to have some kind of consistent theme that becomes just as familiar as the original.

Sounds like a good idea, but also sounds like it might be a difficult thing to get consensus around. Do you have any suggestion for a starting point? I guess that these 16 are the same as the wimp_COLOUR definitions in OSLib, and a very boring starting point might be to fill the gaps in those (in bold, note that the order below is not the same as they are defined):

WHITE
VERY_LIGHT_GREY
LIGHT_GREY
MID_LIGHT_GREY
MID_DARK_GREY
DARK_GREY
VERY_DARK_GREY
BLACK
LIGHT_BLUE
BLUE
DARK_BLUE
LIGHT YELLOW
YELLOW
DARK YELLOW
LIGHT_GREEN
GREEN
DARK_GREEN
LIGHT RED
RED
DARK RED
LIGHT CREAM
CREAM
DARK CREAM
LIGHT ORANGE
ORANGE
DARK ORANGE

That palette would be familiar, but is still notably missing cyan, magenta/purple (adding those in three nuances, I note that the number of colours would be 32). One design consideration could be, that the ROOL logo colours should be available in the palette… ;)

EDIT: A quick mock-up of an extended palette with three hues for each of the original colours, plus magenta and cyan (order for display purpose only):

Original palette for reference:

difficult thing to get consensus around

See this thread on extending ColourPicker: https://www.riscosopen.org/forum/forums/2/topics/13415

So you haven’t heard about 256 colour modes? Or about using a palette to allocate the 16 standard colours to other colours?

The thing is, Wimp_SetColour and its relatives are still stuck with an arbitrary 16 colours, and since RISC OS 3.50, haven’t even had a GUI for changing what those are. You need a third party tool to do it, or write some code.

I guess that these 16 are the same as the wimp_COLOUR definitions in OSLib, and a very boring starting point might be to fill the gaps in those

The problem here is that you’d need to do it in a way that didn’t break the Wimp and all of the applications out there, which will be slightly fun as there are things like foreground and background colours of icons squashed into four bits apiece of the icon flags. That’s why the jump to 24-bit: like so many things, the difficulty is pushed from the icon flags to the C command in the validation string. Windows are easier, as they have 8 bit fields for each of the colour values.

I guess what you could do is keep the bottom 16 colours the same, and add in extra ones for applications which wanted them. You could have up to 239 extra before the window blocks broke (255 has special meaning), but you would either need to limit icons to the existing 16 colours or 24-bit, or add another validation command with little benefit over the 24 bit option.

Old applications wouldn’t know about them, and probably wouldn’t ever offer them to their users as everyone was left to roll their own colour selection code by Acorn back in the day. You might also have to watch out for old applications which did somehow offer the colours to their users, and then tried to squash two 8-bit values into the icon flags.

ETA: But, yes, if a solution can be found which isn’t “we don’t care about old applications”, then more named colours would be good.

Perhaps it could be approached a different way, with something (the Wimp, ColourTrans?) taking the names and spitting out the 24-bit values? That way, apps can use consistent themes, but there’s no need to break the current “Wimp colours are always in the range 0-15” assumptions.

Why is no one proposing a 256 colour palette?
That’s one of the good old standby colour sets in many MDF’s

So you haven’t heard about 256 colour modes? Or about using a palette to allocate the 16 standard colours to other colours? (Originally the palette was in hardware.)

That’s not what I’m talking about. It’s not about display palettes, it’s about user interface.

Why is no one proposing a 256 colour palette?

In my opinion, a 256 colour picker is (for most purposes) verging towards the “bewildering choice” side. They can’t be simultaneously displayed in all but the largest of dialogue boxes (or the longest of menus) and even the cleverest of arrangements will see similar colours placed apart. Plus keeping track of the colours you’re using is a problem. (E.g. you want to set the text to that dark blue you used before, but you can’t remember which dark blue it was.)

I guess what you could do is keep the bottom 16 colours the same, and add in extra ones for applications which wanted them.

That’s my plan. Keep the original 16, and add an extra 16 to complement them.

Why is no one proposing a 256 colour palette?

What @Charlotte said.

That’s not what I’m talking about. It’s not about display palettes, it’s about user interface.

I, and possibly we, had realised that, but I was thinking that the colour picker being able to pick ALL the colours in one of the default low colour modes might be considered useful.
It might work out as a superset of the colours that Steve F highlights as rather useful for legacy apps/machines.

Therefore I propose some kind of style guideline, which adds more “standard” colours,

What is the actual use case for modifying the generic 16 colour palette? The only time I ever see that these days is when setting a colour in, say, Draw or the like where it is part of the colour picker as possible “shortcuts”.

perhaps going up to 32 in total.

The problem, I feel, is that no matter what colours you pick, they won’t be correct.

I, personally, feel that we should keep the standard 16 colours (they’ve been around for three decades, no point removing them now), and instead add a further eight options underneath. These eight options will reflect the last eight colours that the user set – making it easy to go back and forth between the colours that the user is actually using at that point in time.

I’ll leave it up to implementation whether or not it persists across reboots, but it should be platform specific, not app specific, so the colours in use can be shared (say, between Draw , ArtWorks, a DTP, and so on).

Speaking for myself, it would also be useful if ColourPicker output the value of the current colour choice in three-byte hex (like “#FFEEDC”) to the right of the HSV option icon. This would make it easier to reproduce that exact colour in HTML (than using BASIC to convert a percentage to 0-255 range and then hexifying it).

in one of the default low colour modes might be considered useful.

It’s only the legacy machines that are even capable of that. A number of contemporary machines are only capable of an indexed 256 colour palette, as will as 16 bit (RGB565 or the like) and full colour; with full colour being the default since there’s no longer any specific VRAM size restriction. As such, 16 colour modes (or less) simply don’t exist.

I don’t know how relevant this is nowadays, but I’ve always tried to use “Netsafe” or “Web Safe” colours, ones which corresponded to what NetScape could cope with in the olden days.

Could this be appropriate to inform our choices?

This reduces our 256 colours to 216 for starters.

Could our extra 16 be usefully chosen from amongst them, and would this be helpful in any way?

ones which corresponded to what NetScape could cope with in the olden days.

I believe that was largely informed by the capabilities of 256 colour VGA hardware (32 standard colours for Windows, and 216 “WebSafe”).

It might work out as a superset of the colours that Steve F highlights as rather useful for legacy apps/machines.

Who mentioned legacy? :)

As I said, the fact that there are 16 colours in the Wimp set is quite probably fairly closely related to the fact that the foreground and background colours of all icons are defined in terms of those 16 colours using two four-bit fields in the icon flags. If you want to escape that limitation of 16, you have to make the icon indirected, set the text flag and use the C validation command.

Expanding this from 16 (adding more values to wimp_colour in OSLib terms, since we’ve referenced that up-thread) will break everything, because there are no spare bits. You also can’t expand the icon block from the current 24 bytes, because it’s defined to be 24 bytes and applications can just allocate 24 bytes and know that’s it is going to be enough. That’s why the 24-bit colour change (and so many other add-ons to what icons can do) went down the validation command route¹.

Yes, we could go down the route of passing magic numbers to Wimp calls, or creating a new significant version number to pass to Wimp_Initialise, but that’s a lot of work.

I still think the better approach would be to move to 24-bit (which the system already supports, as noted above) and have some part of the system to convert “named colours” to their RGB values. This is effectively what Windows does, and it seems to work.

Another way to track recently used colours is to do just that in dialogue boxes. On other platforms, colour pickers usually have a row of “recent” colours which can be selected from.

¹ See also stealing a flag bit back from the ESG to implement right-to-left text in RISC OS 3.50, which went down well with developers.

Who mentioned legacy? :)

All of us, except the newbie – Hi there – cos we’re legacy. :)

See also stealing a flag bit back from the ESG to implement right-to-left text in RISC OS 3.50, which went down well with developers.

I can hear Nemo’s screams now. Much the same as others, but probably more venom.

A suggestion for an expanded colour picker. All the standard 16 are included, marked by dots.

Again, this is intended as a display of “standard” colours to complement the 24-bit HSV mixer, rather than anything remotely akin to a 5-bit per pixel colour mode.

It’s a bit pastelly, you do know blokes can only really see the primary colours? :)

It’s a bit pastelly

That’s kind of deliberate, as for many applications you want a range of off-whites that can be used for backgrounds on which text is legible (and likewise a range of dark colours that make for legible text).

It’s a bit pastelly,

Indeed it is. Should do well for watercolours. :)

you do know blokes can only really see the primary colours? :)

This the colour version of Alan Lancaster’s comments about “manly bass” isn’t it?

you do know blokes can only really see the primary colours? :)

Oh, brilliant. Another man trope I fail at.

You see red?
I don’t.

I might see red. Or maybe Cardinal [a bird] (not as stark as pillar box red, with a hint of blue). Or Carmine [a bug] (a lighter “blood red”, not far off ketchup really). Crimson? [a bird] Like cardinal but brighter. It would be a pretty vivid red, but there’s an unmistakable hint of blue in there. Fire engine red [guess…], actually, is a little more mute than Pillar Box red [exactly what it says on the tin, if you’re British ;-)]. There’s also Chili Red [a seed pod, allegedly edible], which leans more towards orange. Then there’s Ruby [a pretty lump of rock], which is not Magenta, but you’d be forgiven for mistaking it as so (magenta is off the scale eye aching, Ruby is the sort of magenta you would use in polite company). Scarlet [yet another bird] is full on red with a dash of green. But you’d wonder why fire trucks aren’t this colour. And sometimes mistaken for that pop group from the eighties, Vermilion (yet another bird), which is best described as an orange that think’s it is red. The pop group was Marillion, or maybe I should just say “Kayleigh”.

That’s just red, that’s not counting shades (like pink), and that’s barely scratching the surface.

There’s a long running gag about people who think Cerulean is Cyan. It isn’t.

Suffice to say, there must be something deficient in the lives of people who can only express their ideas of colours through the primaries.

And, just to mess with you, there’s a bird called the Vermilion Cardinal. Guess which colours it is. ;-)

@Charlotte:

A suggestion for an expanded colour picker. All the standard 16 are included, marked by dots.

Looks promising! Any other design considerations you can share?

@Rick:

Guess which colours it is.

Is it… red? ;) (Fellow twitcher..?)

A quotation from A Voyage to Arcturus:

The sense-impressions caused in Maskull by these two additional primary colours can only be vaguely hinted at by analogy. Just as blue is delicate and mysterious, yellow clear and unsubtle, and red sanguine and passionate, so he felt ulfire to be wild and painful, and jale dreamlike, feverish and voluptuous.

Please can we have jale, ulfire, and dolm maybe, in the extended colour picker?

I’d just settle for orange being a primary colour, then my gamut would be full.

Please can we have jale, ulfire, and dolm maybe, in the extended colour picker?

On balance, limiting the choice of colours to those within human comprehension is probably the most practical way of utilising available resources.

I think it would be best to have a (fairly minimal) semantic palette, where desktop colours are referenced by meanings rather than having hardcoded colour values. So a few examples would be like:

• Window Background
• Window Foreground
• Window Selection
• Button Background
• Button Foreground

etc.

That way, the actual colours don’t matter very much; they become part of a theme, and users can pick one that appeals to them. I don’t expect it would be very easy to change RISC OS and the apps to work like this though.

Some examples:

• https://www.w3.org/TR/css-color-4/#css-system-colors
• https://experience.sap.com/fiori-design-web/quartz-light-colors/

Fellow twitcher..?

Mom was the one who enjoyed watching the feathery fiends.
Me? I just enjoy having names for more colours than are present in the rainbow song.

limiting the choice of colours to those within human comprehension

Apparently this might depend upon gender. ;-)

Window Background
Window Foreground

What would be the use case for this? While you can specify window/icon colours in the Templates, by and large people use the defaults and the Wimp can do some things automatically (like pasting in a background pattern) or handling themes.
So, really, as long as the programmer hasn’t done something weird like yellow and blue icons, this sort of thing should be a WindowManager issue, not an application issue.

That way, the actual colours don’t matter very much; they become part of a theme, and users can pick one that appeals to them.

ColourPicker is used in Draw, Paint, DTP (etc) where you might want to set colours for a box that is being placed upon a page. Or the colour of the hair of the manga character you’re drawing (in Paint?!?).

I don’t understand how the desktop theme and window colours is particularly relevant to this. Yeah, the “deefault 16 colour palette” is something of an anacronism, and is mostly a left-over from the days when it was normal to have 16 colour modes.
My vote to leave it/augment it is not out of any fondness towards that particular set of colours, but simply because anything else is just as liable to be wrong for other people.
Shall we have the BBC/Teletext 8 colour palette? How about the CGA/ANSI 16 colour (eight light/eight dark) one? Or the Windows 3.1 one (same as CGA/ANSI but different order)? Or maybe the one from Arthur 1.20? Or the Apple Mac one? Or maybe something that tries to work out the best default colours for artists?

That’s why I think having a number of “last n colours” options would be best. The default palette can be used as a starting point, and it’ll then track the most recent colours picked. In that way, it should allow quick and easy access back to a previously used colour, so should hopefully offer the best of both worlds.