Possible alternate colorspaces for video game palettes.

I was thinking about colorspaces today, and I came up with a decent idea for a color space that can easily be converted to low-bit rgb, that should be a little more visually uniform than rgb.

I think I'll call it Yab, just because the Y works like the Y in YUV and YIQ, and the A and B work sort've like the A and B in Lab. So here's my formula.

R = Y + 2a + b
G = Y - a
B = Y - 3b

Any advice to improve upon this. I'm thinking there should be a way to compensate for the not-so-predictable luminance value of highly saturated colors.

This doesn't really look all that much more useful than RGB?

Here's a simple cube, 0≤Y≤7, -4≤a,b≤3:Lots of out-of-gamut colors too.

No yellows, and lackluster reds and purples.

Maybe A/B range from 0 to 7, not -4 to 3?

Or try -7 to 7. BTW, why is everything so dark?

Sounds very similar to YCgCo, but not quite the same.

I never heard of that before, but it sounds awesome.

I made a 12-bit YCoCg color palette. It's cool how it ended up being exactly 1024 colors. That means if I make a 15-bit version, it will come out with 8192 colors.

I always wondered how having 6bit RGB with 2 extra bits to reduce the value of the color for every channel. Because your eyes are supposedly better at seeing shades of color than different colors or something like that, I wonder if it might even look better than 9bit RGB despite only being half the colors.

That's a form of RGBI, with 2 bits per channel. It's the componentwise sum of the Cartesian product of four 2-bit palettes:

Red: #000, #400, #800, #C00
Green: #000, #040, #080, #0C0
Blue: #000, #004, #008, #00C
Intensity: #000, #111, #222, #333

Fortunately, GIMP makes componentwise sums easy using the Addition blend mode.

May as well compare it against my colorspace:



RGB 3.3.3, but red and blue share the LSB (so it fits in 8-bit). I came up with it because I honestly hate how little resolution blue has in RGB 3.3.2, which wouldn't be much of an issue except because it seems new "retro" hardware insists on using that (argh!).

I thought I'd try seeing how Sik's palette looks:

I thought of a different kind of colorspace: 3-bits high-voltage, 3-bits low-voltage, 3-bits phase. The phase only covers half, because you can get the rest of the phases by inverting it which is done by switching the voltage. If high-voltage and low-voltage is same then the picture will be gray.

I assumed that Espozo meant something with a multiplier, not RGBI.

Here's the equivalent palette where I parse the last two bits as a all-channels multiplier that ranges from 1 to 4:


It's really lacking in pastels, though, so the parrot doesn't look so good:

Actually his description sounds more like reverse RGBI, where I substracts instead of adding (you could achieve that just by passing I through a NOT). But yeah it's not very clear honestly.

Yeah, I didn't mean multiplying. I meant what Sik is talking about. I'm not sure how different than would look than tepples's though.

That'd be HSL-ish, sort of like NES except including more desaturated midtones. It'd be simple to implement a composite output circuit for (assuming an 8*CB crystal), but I can't so easily show the parrot for this one because it has 8*8*8-8*7 = 456 colors, and GIMP won't quantize to palettes with more than 256 colors.

Sik's suggestion to subtract the intensity instead of adding it would be mathematically equivalent to the purely additive RGBI if defined as follows:

Red: #300, #700, #B00, #F00
Green (add): #030, #070, #0B0, #0F0
Blue (add): #003, #007, #00B, #00F
Intensity (subtract): #333, #222, #111, #000

Really the only difference is that the order of the colors has changed, but the available colors are pretty much the same. May as well just go with additive at that point and make everybody's lives easier.

Somebody should go and glue two EGAs together...

Something I remembered: I know some LCDs work by shifting hues instead of shifting luminance. What about a colorspace where you layer both kind of LCDs on top of each other? Would it have been a reliable way to get color on early handhelds without eating battery like hell? Biggest problem (aside from the obvious blurring) is that saturation would be always at max. Still, would be a fun experiment to think about.

So-called "Electronically Controlled Birefringence" Displays are achievable (scroll down to "COF LCD module"). They have a rather peculiar color palette, though.

There was a Pokemon-themed pedometer that used it. (video)

So wait, their range can be stretched to do more than just a hue shift? Because that actually seems more useful. (my original idea was to use that for hue and then another display on top that was monochrome for luminance)

Here's another idea: HSL 4.2.2

• When bits 7-4 are 0000, the color is grayscale and bits 3-0 are the luminance.
• Otherwise, bits 7-4 specify hue (in steps of 24º), bits 3-2 the saturation (25%,50%,75%,100%) and bits 1-0 the luminance (20%,40%,60%,80%).

EDIT: fixed my HSL algorithm and ditched the old image



Still leaves a lot to be desired.

I like the colors, but fading in this color space looks complicated, especially since grays are treated differently.

I think that fading is hell with most of the colorspaces mentioned here though =P Would make for a good default 256 colors palette though.

I'm not happy with how coarse luminance turns out to be, though =/

Why does the highest luminance level also lower saturation? Saturation increases perceptual brightness, so that seems counterproductive, not to mention redundant.

That's how HSL works, maybe you were thinking on HSV instead?

I was thinking purely in terms of getting the most usable colors out of the palette. Now that you mention it though, HSV is probably what I was suggesting.

OK giving a try to HSV (same format otherwise), assuming I got the calculation right (was expecting this to be harder):

So, in order to fade to black you'd alternate between decreasing V and increasing S, and to fade to white you'd alternate between decreasing S and increasing V?

Last time I tried making an 8-bit color space with a good luminance range I ended up with this quite arbitrary palette:



I found that the RGBI palette that tepples posted earlier could be rearranged to emphasize grayscales but still have all the same colors.



This would be the palette I would use if I was designing another Uzebox or something. Maybe replace the additions with XORs to simplify circuit design.

If the digital values are just converted linearly there's no greens at all:

If you normalize green so it's the same range (i.e. scale up from 0-15 up to R and B's 0-27), it's ... ok?


That produces an interesting set of colors:

Ahh sorry lidnariq, my mistake. I was implying 4 bit values and results with those modular additions, and I see that I accidentally swapped my red and blue in that pseudocode.

A small python 3 program that correctly generates it as a GIMP Palette is: