List of the Old Skool palettes

[Mathias]

Where's the definitive source for all the old primitive palettes - C64, Amiga, NES, etc?

I want to experiment with them. Please advise. My best bet is just a stinkin' wiki page - http://en.wikipedia.org/wiki/List_of_palettes

[Ai]

That wiki page is actually pretty accurate and comprehensive, though of course you should look up 'C64', 'NES', etc to get the exact technical restrictions..

There is no definitive palette for C64.

c64 palettes here:
http://www.wayofthepixel.net/pixelation/index.php?topic=1618.msg27230;topicseen#msg27230

C64, CPC, ORIC palettes here:
http://www.wayofthepixel.net/pixelation/index.php?topic=3225.0

NES here:
http://www.wayofthepixel.net/pixelation/index.php?topic=5852.0

anything else, use the search bar!

[happymonster]

When you get to the 16bit consoles/computers they tended to have a palette of 512, 4096 or more colours. So really it's the 8-bit ones which are more manageable.

[Ai]

Yes, that's listed on the wiki page.

CPC == 3 levels of RGB (3**3 == 27 colors), 16 or 4 or 2 onscreen (according to screen mode)
EGA16 == 2 levels of RGB (off/on), plus one intensity bit which adds 7f7f7f to the color == 16 colors, of which 16 can be displayed onscreen
(not necessarily in the same order or quantity. palette cycling and fading  was possible)
EGA64 == 4 levels of RGB (4**3 == 64 colors), 16 onscreen normally.
Genesis / Megadrive == 8 levels of RGB (8**3 == 512 colors), max 62 onscreen [1]
Amiga ECS == 16 levels of RGB (16**3 == 4096 colors),  2/4/8/16/32, or 64   [2]
CPC+ == 16 levels of RGB (16**3 == 4096 colors), 16/4/2 onscreen (more possible, using hardware sprites); Slightly different from Amiga ECS master palette in that the green channel uses a mildly altered intensity curve vs the blue and red channels.
SNES == 32 levels of RGB (32**3 == 32768 colors), 256 colors / scanline plus simple hardware compositing [3]
MCGA / VGA == 64 levels of RGB (64**3 == 262144 colors), 256 or 16 onscreen
Amiga AGA == 256 levels of RGB, 2/4/8/16/32/64/128/256 colors onscreen.

Onscreen color limits are per-scanline. Which doesn't necessarily mean that you could change the palette every scanline to vastly increase the total amount of displayed colors. Usually you could manage to change the palette at least twice per refresh, though.
Some games (like Switchblade on the CPC) implemented vertical text gradients by changing one palette entry every scanline.
On some systems, like PC's, this trick is very difficult to do reliably because there is no fixed hardware.

Most color systems described here tend to have a direct relation to standard sRGB. I think CPC has slightly different intensity curve than sRGB, though.

My software 'PixLab' supports quantizing accurately to these colorspaces, and I can easily provide lookup-tables for this (it's surprisingly tricky to do correctly). I could provide palettes, however: 4096-entry palettes? not practical. IMO 256 is about the limit of managability, like happymonster says.


[1] two 16-color palettes for background tiles, and 2 15-color palettes for sprites ( the 16th entry represents transparency)
[2] any hex color #RGB is a color from the Amiga master palette, and any hex color #RRGGBB where the two R,G,B digits match.
64-color mode was EHB 'extra half-brite' mode, where you could not choose the extra colors, the extra bitplane just specified 'halve the intensity of the color of this pixel' where a bit was set. If you pick a 32-color palette, then copy it and apply Levels 0..128 to the copy, you
will have a result that may be right (documentation on this is not clear; it just says 'halve intensity' -- is the resultant intensity quantized to the 16**3 limits of Amiga OCS or not?)
Details about HAM modes intentionally omitted.

[3] any hex color #RRGGBB where the second R,G,B digits are one of (0,8) is a color from the SNES master palette.
This means that #f8f8f8 is the closest to white you can come.

EDIT: Updated according to saimo's post about AGA and my info about Genesis, SNES.
EDIT2: Updated according to saimo's later post.
EDIT3: added CPC+ info

[Mathias]

Yes Ai, I'm familiar with the search bar. I could google keywords I hope would lead me to the correct information or I can come to the experts, who may choose to advise me or completely ignore my posts. I appreciate the help thus far.

After investigating the links given and reading up on the matter, it seems that these old systems are capable of many more colors than I thought  -BUT-  are only allowed to display a certain amount simultaneously, for instance - the whole 8x8 block restriction thing.


Yet, does this image really depict ALL possible colors for the Commodore64?
http://upload.wikimedia.org/wikipedia/commons/e/ef/Screen_color_test_Commodore64_Multicolor.png

[Ai]

What has google to do with anything? I meant the search bar here.

C64 has a master palette of 16 colors, of which 16 may be displayed simultaneously. So yes, that image does display roughly all the possible colors. There were various tricks that could give the impression of more colors, but that's all really; there were just 16 colors.
(As I said before, the exact definition of those colors is not known because AFAIK it was fairly dependent on the display you were using, the exact color that a particular palette entry rendered as.)
http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm

SMS has 32 from master palette of 512, IIRC
per : http://en.wikipedia.org/wiki/Sega_Master_System#Technical_specifications
apparently it actually has 16 for sprites, 16 for bg, which is taken from an overall palette of 64 (this 64-color palette doesn't appear to be easy to find; I'll guess it's rather like the EGA64 palette, since it has 2 bits each for R,G,B; it might have a different gamma from EGA64.)

[ptoing]

Indeed, the C64 only has 16 possible colours, they can all be on screen at the same time, but it depends on the gfxmode how many can be in a character (8x8) pixel block.

There are 2 main modes, Char and Bitmap - and two submodes kinda, hires (or singlecolor) and multicolor.

- In Hires Bitmap you have the full resolution of 320x200 with any 2 colours per 8x8.

- In Mcol Bitmap you have a reduced horizontal resolution of 160x200 with doublewide pixels, so a character has 4x8 widepixels instead of 8x8 singlepixels.
  In this mode one colour is fixed for the whole image, this is called the background color and it can be any of the 16. Then in each character block you can  use an additional 3 colours.

In Charmode you can mix hires and mcol chars, but the restrictions are much more severe.

The background colour is fixed, hires chars can have that bgcolour and one additional colour (if they are mixed with mcol chars the additional colour can only be colour 0-7, if you only use hires chars any colour can be set for the additional ones.) Mcol chars have 2 fixed colours for all chars and then one additional colour per char selected from colours 0-7 on top of the global background colour.

The top palette is the C64 one with the correct colourorder. Bottom one is the VIC20 palette, tho that one is much more inaccurate.




In the above image you can see the order regarding brightness and the lumapairs (there are 7 pairs where 2 colours share the same lightness value, on a monochrome monitor you can only see 9 distinct colours in total. If colours of the same luma are alternated in horizontal lines you get a new colour. This only works on PAL systems tho and not on NTSC ones. This is due to how the PAL signal is encoded. It also depends which colour is on odd and which on even lines. So technically each lumapair can yield 2 additional pure colours.

So in the end you have 16 original colours + 14 colours from the lumapairs. There are some less pure colours of the 2 lumapairs which have a smaller gap in brightness than the others (light blue / grey, green / light red). Mixing between those 2 pairs yields OK results but the colours are not totally pure, stripes can be seen.

There are more things that can be done on the C64 graphically involving advanced hackmodes, so I wont go into that.
Mcol and Hires Bitmap modes are good fun if you wanna think a bit more about where to place pixels.

[Ai]

correct SNES info is now posted at
http://www.wayofthepixel.net/pixelation/index.php?topic=7368.msg87616#msg87616

In short, for each channel of (R,G,B), two-digit hex codes ending in 0 or 8 are snes colors.
f8 is the maximum value.
Thus, SNES' 15bit RGB colorspace is markedly different from the standard PC 15bit hicolor, which includes the full range 0..255.

Genesis/Megadrive info:
The same 'no hot colors' scaling applies for Genesis as it does for SNES. Thus, these are the possible intensities in hex:

00 20 40 60 80 a0 c0 e0

Simple, yes ?
These 8 intensities combine into 512 colors, 8*8*8, of course.

[saimo]

MCGA / VGA / AGA? == 64 levels of RGB (64**3 == 262144 colors)

AGA palette was 24-bit, so you could write:
AGA == 256 levels of RGB (256**3 == 16777216 colors)
The 262144 figure relates to Amiga's HAM8 mode - but that's a different story.

saimo

[Ai]

Thanks saimo, I fixed that.

I feel suspicious about Ptoing's white in that C64 diagram, because as far as I know,  sRGB white (#ffffff) is a color that would damage old CRT TVs such as the ones that C64s would usually display using. You can see that later systems like SNES still took care to avoid hot colors.

It *is* within the YCbCr gamut, which is the digital equivalent of the YPbPr system used by the C64, it just seems like such a color could not have actually been used
I'd suggest a color more like #e6e6e6 instead of that fierce white.

[saimo]

Thanks saimo, I fixed that.

You're welcome
Here's some more information... but be warned: when talking about video capabilities of Amigas, it is impossibile not to run into troubles because their chipsets are entirely programmable, so that what they can do is not easily summarized.

Amiga ECS == 16 levels of RGB (16**3 == 4096 colors), 4096 onscreen in HAM mode, 32 or 64 in other modes. [2]

Let's start with the easy stuff.
OCS/ECS Amigas can handle any number of bitplanes from 1 up to 5*, meaning that the number of colors in "normal" modes can be 2, 4, 8, 16 or 32.

*Depending on the resolution: at higher resolutions, because of bandwidth limitations, the maximum number of bitplanes is reduced.
Moreover, As you also mention, a 6th bitplane can be used in EHB mode, for a total of 64 colors.

Amiga AGA == 256 levels of RGB, with > 262144 onscreen in HAM mode, 256 or 128 onscreen in other modes. [4]

The same goes for AGA Amigas, with the difference that they have 2 extra bitplanes - so, also screens with 128 or 256 freely-defineable colors are possible (of course, the 64 colors EHB mode is still available for backwards compatibility).

Moreover, on all Amigas the color registers values can be dinamically changed by the Copper chip (which can write a color value more or less every 4 LORES pixels horizontally), so that the actual number of colors displayed can be much greater than those given by the number of bitplanes.

Finally, there are the dual-playfield modes, which overlap two separate screens (odd bitplanes are used for one playfield and even bitplanes for the other) at the cost of a reduction of the maximum number of colors (on AGA, the limit is a playfield of 16 colors overlapped by a playfield of 15 colors + transparency).

For a better idea of what we are talking about, have a look at this picture:

Here we see an ECS chipset working in dual playfield mode (so, it's 8 colors for the background playfield and 7 colors + transparency for the foreground playfield), with the Copper altering the palette* on a rasterline basis: the end result is that the color count (in this particular screenshot) reaches 171. Edit: I forgot to mention that there are also the colors of the sprites - main character and HUD -, which are given by color registers 16-31 (unused by the playfields).

*For the curious ones: instructed by the CPU, it is also moving the clouds, applying a line-by-line parallax effect on the background planes, applying a sinusoidal wave effect on the bottom of the foreground playfield and scrolling both playfields.

64-color mode was EHB 'extra half-brite' mode, where you could not choose the extra colors, the extra bitplane just specified 'halve the intensity of the color of this pixel' where a bit was set. If you pick a 32-color palette, then copy it and apply Levels 0..128 to the copy, you will have a result that may be right (documentation on this is not clear; it just says 'halve intensity' -- is the resultant intensity quantized to the 16**3 limits of Amiga OCS or not?)

This is hard to say, indeed.
The Amiga Hardware Reference Manual says:

The color register output selected by the first five bitplanes is shifted to half-intensity by the sixth bitplane.

The phrasing (and especially the fact that the word "output" is used instead of "value") suggests that the halving is "real".
However, the Amiga ROM Kernal Manual says:

If you draw using a color number from 32 to 63, then the color displayed will be half the intensity value of the corresponding color register from 0 to 31. For example, if color register 0 is set to 0xFFF (white), then color number 32 would be half this value or 0x777 (grey).

which suggests that halving is limited to the palette generator capabilities as you suspected.

So, which to choose? I personally would go for the option #1, because:
 - when it comes to hardware, the Amiga Hardware Reference Manual is likely to be more reliable than the Amiga ROM Kernal Manual;
 - Amigas' engineers were too clever to go for option #2 when the other solution was so easy
 - emulators (at least the version of UAE I used for testing) use halved intensity (I assume that the programmers did their research/testing).

I must admit that in my life I had never asked myself such question

[4] the actual number of onscreen colors possible is between 262144 and 414720
(see http://en.wikipedia.org/wiki/Amiga_Hold-and-Modify)

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.). As said at the beginning, Amigas' video circuitry is entirely programmable, so that countless resolutions/modes/frequencies are possible. For example, there is the DDFSTRT (Display Data Fetch STaRT) register which allowed the programmer to tell the chipset at which position of the raster beam to actually start drawing - and this was also refined in the ECS chipset with the addition of the DIWSTRT (DIsplay Window STaRT) register. And that's just the beginning. Moreover, HAM modes are so tricky that it makes little sense to just give rough numbers.
If I were you, I would just specify figures of "normal" modes.

saimo

[Helm]

saimo, thank you for that informative post! 

[saimo]

saimo, thank you for that informative post! 

My pleasure (really)
(For your curiosity, since I enriched it right after posting, you may want to re-read it not to miss some additional information.)

saimo

[Ai]

Here's some more information... but be warned: when talking about video capabilities of Amigas, it is impossibile not to run into troubles because their chipsets are entirely programmable, so that what they can do is not easily summarized.

Yes, I aimed to summarize just the abilities a pixel artist would use (which IMO doesn't include copper effects*). Another reason for omitting the palette-changing-during-redraw trick is that this is a pretty standard technique, available on at least CPC,  C64, SMS, GameGear, Genesis,
Amiga. Though the Amiga is the only one with an actual processor synced to the monitor so the changes can be very numerous and exact
(kind of overkill -- being able to change palette every 4 pixels, when your total palette may be 8 times that size, heh)

* of course, now that I've said this, I remember a CPC pic of mine that does use midscreen palette changing.

Amiga ECS == 16 levels of RGB (16**3 == 4096 colors), 4096 onscreen in HAM mode, 32 or 64 in other modes. [2]

Let's start with the easy stuff.
OCS/ECS Amigas can handle any number of bitplanes from 1 up to 5*, meaning that the number of colors in "normal" modes can be 2, 4, 8, 16 or 32.

Fixed (or will be by the time you read this)

Finally, there are the dual-playfield modes, which overlap two separate screens (odd bitplanes are used for one playfield and even bitplanes for the other) at the cost of a reduction of the maximum number of colors (on AGA, the limit is a playfield of 16 colors overlapped by a playfield of 15 colors + transparency).

For a better idea of what we are talking about, have a look at this picture:

Here we see an ECS chipset working in dual playfield mode (so, it's 8 colors for the background playfield and 7 colors + transparency for the foreground playfield), with the Copper altering the palette* on a rasterline basis: the end result is that the color count (in this particular screenshot) reaches 171. Edit: I forgot to mention that there are also the colors of the sprites - main character and HUD -, which are given by color registers 16-31 (unused by the playfields).

What I want to know, is, how is this relevant to an artist? Does it amount to any technical limitation or advantage, or is it a thing which is strictly useful only in-game?

64-color mode was EHB 'extra half-brite' mode, where you could not choose the extra colors, the extra bitplane just specified 'halve the intensity of the color of this pixel' where a bit was set. If you pick a 32-color palette, then copy it and apply Levels 0..128 to the copy, you will have a result that may be right (documentation on this is not clear; it just says 'halve intensity' -- is the resultant intensity quantized to the 16**3 limits of Amiga OCS or not?)

This is hard to say, indeed.
The Amiga Hardware Reference Manual says:

The color register output selected by the first five bitplanes is shifted to half-intensity by the sixth bitplane.

The phrasing (and especially the fact that the word "output" is used instead of "value") suggests that the halving is "real".
However, the Amiga ROM Kernal Manual says:

If you draw using a color number from 32 to 63, then the color displayed will be half the intensity value of the corresponding color register from 0 to 31. For example, if color register 0 is set to 0xFFF (white), then color number 32 would be half this value or 0x777 (grey).

which suggests that halving is limited to the palette generator capabilities as you suspected.

Actually, when you quoted 'is shifted' -- that is a real tip off, and IMO indicates that bits set in the 6th bitplane caused the equivalent of a SHL A,1 instruction on the values taken from the palette, since that would have executed very fast.

So, which to choose? I personally would go for the option #1, because:
 - when it comes to hardware, the Amiga Hardware Reference Manual is likely to be more reliable than the Amiga ROM Kernal Manual;
 - Amigas' engineers were too clever to go for option #2 when the other solution was so easy
 - emulators (at least the version of UAE I used for testing) use halved intensity (I assume that the programmers did their research/testing).

The difference is not large, though. in fact, it's nearly invisible in many cases.
Here is the 'exactly-halved' scale

00 08 11 19 22 2a 33 3b 44 4c 55 5d 66 6e 77 7f

and here is the 'shifted-left' scale

00 00 11 11 22 22 33 33 44 44 55 55 66 66 77 77

As you can see, each second 'exactly-halved' value differs from the 'shifted-left' value by exactly 8.

Anyway! It is possible to emulate both effects, whichever is correct.

The first is as I said: Divide sRGB intensities directly by 2. (aka levels with output range set to 0..128)

The second is to first divide by 34 (aka levels with output range set to 0..7),
then to multiply by 17 (aka levels with input == 0..7, output = 0..119)

I'm not sure which is correct, now.

I must admit that in my life I had never asked myself such question

I know, these issues are sooo important )))) I like to get them correct for my Pixlab library, though.

[4] the actual number of onscreen colors possible is between 262144 and 414720
(see http://en.wikipedia.org/wiki/Amiga_Hold-and-Modify)

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.).

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

As said at the beginning, Amigas' video circuitry is entirely programmable, so that countless resolutions/modes/frequencies are possible. For example, there is the DDFSTRT (Display Data Fetch STaRT) register which allowed the programmer to tell the chipset at which position of the raster beam to actually start drawing - and this was also refined in the ECS chipset with the addition of the DIWSTRT (DIsplay Window STaRT) register. And that's just the beginning. Moreover, HAM modes are so tricky that it makes little sense to just give rough numbers.
If I were you, I would just specify figures of "normal" modes.

Okay, good idea.

[happymonster]

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

The interlaced screenmodes were prone to flickering, but this could be minimised by reducing the contrast between vertical scan lines (i.e. adding gray between black and white, a form of anti-aliasing). When done this could dramatically improve things while still keeping the higher resolution detail.

There was even a program for Workbench called something like MagicTV which did the same kind of filter in real-time to allow you to have minimally flickering high-resolution desktops on normal TV's or standard monitors (not capable of proper non-interlaced high resolution gfx). I never saw any slowdown with this program, so no idea how it worked so well!

[saimo]

Though the Amiga is the only one with an actual processor synced to the monitor

Just for precision's and completeness' sake, it must be said that the only hardwired synchronization is that the Copper restarts processing its copperlists (sequence of instructions that constitute its programs) when the raster beam restart drawing a frame.
Other than that, there is the WAIT instruction which allows it to wait for the raster beam to reach the wanted position (but it can also be used to wait for other events, like the Blitter being done with data processing) - but how to use that instruction is up to the programmer.

so the changes can be very numerous and exact (kind of overkill -- being able to change palette every 4 pixels, when your total palette may be 8 times that size, heh)

It's not that one *has* to change colors that frequently, you know
Jokes aside, the Copper is not limited to just changing colors (it can write any 16-bit value into the chipset registers, so it is a rather general-purpose processor) and the connection to the raster beam is looser than commonly thought of. The 4 pixel resolution is given by the Copper's speed: it simply cannot write consecutive 16-bit values more quickly than that - in other words, saying "4 pixels" is just a rough way of measuring the Copper's speed*. Had the Copper been quicker, Amigas would have been even more powerful - f.ex., if it had been "just" 4 times as quick, LORES chunky screens would have been trivial to implement at (almost) zero CPU cost.

*Of course there is a connection between the Copper's and the rest of the chipset's clock speed, but at the moment I cannot remember - it is a few years since I last programmed those chips, so my memory got quite rusty

What I want to know, is, how is this relevant to an artist? Does it amount to any technical limitation or advantage, or is it a thing which is strictly useful only in-game?

I don't really understand the meaning of the last part. Anyway, certainly those technical aspects are relevant to an artist: when he draws something, he must know what he can or cannot do and also what the programmer is going to do with the graphics.

Actually, when you quoted 'is shifted' -- that is a real tip off, and IMO indicates that bits set in the 6th bitplane caused the equivalent of a SHL A,1 instruction on the values taken from the palette, since that would have executed very fast.

Agreed.
Still, at the same time, I can harly imagine the engineers - who were perfectly aware that the graphics department was fundamental for the revolutionary machine they were creating - going for such a solution when halving the brightness just before sending the signal to the monitor would have not been very expensive. On the other hand, IIRC, one of Jay Miner's (the Amiga's father) favourite lines was "engineering is the art of compromise", so maybe they just had to resort to the simple shift.

The difference is not large, though. in fact, it's nearly invisible in many cases.
Here is the 'exactly-halved' scale

00 08 11 19 22 2a 33 3b 44 4c 55 5d 66 6e 77 7f

and here is the 'shifted-left' scale

00 00 11 11 22 22 33 33 44 44 55 55 66 66 77 77

As you can see, each second 'exactly-halved' value differs from the 'shifted-left' value by exactly 8.

Anyway! It is possible to emulate both effects, whichever is correct.

The first is as I said: Divide sRGB intensities directly by 2. (aka levels with output range set to 0..128)

The second is to first divide by 34 (aka levels with output range set to 0..7),
then to multiply by 17 (aka levels with input == 0..7, output = 0..119)

I'm not sure which is correct, now.

A reliable way to check it out is:
 1. connecting the video out of a real Amiga to a graphics card;
 2. grabbing the output of an EHB screen;
 3. checking the half-brite pixels.

Take those figures with a pinch of salt.
As regards the maximum value, it has been calculated assuming 720x576 as maximum resolution, but that is not correct (Edit: f.ex., other more or less standard resolutions possible: 800x600, 1280x256, 1440x512 interlaced, etc.).

I understood that those modes were highly subject to flickering, so they were not very practical or useful.

As happymonster said, only the interlaced modes flicker.
Indeed, the 800x600 mode I mentioned is a "productivity" mode: instead of PAL's 15 kHz, the horizontal scan frequency is about 31 kHz* (VGA-like), which makes the picture look very crisp and stable. The only problem is that to enjoy it without losing the PAL modes one must have a bi-sync or multi-sync monitor.

*Again, since the chipset was entirely programmable, this figure is not set in stone: all the video parameters depend on one another.

saimo

[Ai]

interesting and related:
a guide to common game resolutions
This told me for instance that you could get doubleheight pixels as well as doublewidth on the Amiga (apparently this is obvious to someone who's really used an a amiga since Workbench uses this 640x240 mode.)
PS1 also has a 640x240 mode which presumably has doubleheight pixels, and a 320x480 w doublewidth  -- I wonder why? Were these ever used in games??

[saimo]

interesting and related:
a guide to common game resolutions
This told me for instance that you could get doubleheight pixels as well as doublewidth on the Amiga

In PAL/NTSC modes Amigas have basically three horizontal "resolutions": LORES (1:1), HIRES (1:2) and SHRES (1:4). HIRES/SHRES are obtained by simply doubling/quadruplicating the pixel speed. That's where the "standard" PAL screens (320x256 LORES, 640x256 HIRES, 1280x256 SHRES) and the double/quadrupleheight pixels come from.
ECS introduced the "VGA" modes, which double also the number of lines, so that also 1:1 modes with resolutions like 640x512 or 800x600 are possible (these modes, however, are not as common as PAL/NTSC ones for a number of reasons, including non-technical ones).

(apparently this is obvious to someone who's really used an a amiga since Workbench uses this 640x240 mode.)

For PAL, it's 256. Maybe 240 is for NTSC... but it could also be 200... cannot remember, sorry

saimo

[Mathias]

Geeze, I wish I was in the know like you guys. Studying this subject from the outside is intimidating, with all the formlas and whatnot. Math and I declared war on each other years ago and the battle rages on . . . whatever that means.

Ptoing, I'm sorry but in reference to your above posted Commodore 64 color palette image, I am not able to get the same results as you when converting it to greyscale. The pairs of greys present in the palette is ingenious on the part of the C64 developers, but I can't prove it to be true through my own efforts, so that I can be confident in it. I've created an image that should do the talking:





When creating sprites with the C64 pal, each colors' base luminance value is paramount in what colors I pick for what. With only 16 colors, you better pick well. I need to have confidence in which colors are really darker or lighter than others. But I can't come to the correct conclusion.

ptoing, how did you generate that greyscale conversion?

[Ai]

Yes you are doing the conversion wrong. I thought the same. Anyway, you need to convert it to YCbCr colorspace. All of these other things you tried are various measures of intensity, but they aren't luma (==Y).

The luma values for those colors are:

  [  0.000e+00,   2.579e-01,   2.539e-01,    3.301e-01,  3.294e-01, 4.088e-01, 4.041e-01, 5.007e-01, 5.020e-01, 5.400e-01,
     5.419e-01,   6.717e-01,  6.706e-01,  8.008e-01,  8.011e-01,  1.000e+00,]

You can convert rgbp -> ycbcr by applying the following matrix (ie. get the dot product) to the rgb values (which must be normalized to the range 0..1)

[[0.299, 0.587, 0.114],
 [-0.168736, -0.331264, 0.5],
 [0.5, -0.418688, -0.081312]]

Alternatively, some of the more esoteric image conversion software might be able to produce a YCbCr image for you.

[ptoing]

I just used Promotions Gray function in the palette box, which seems to do the trick. There are several ways to convert things to grayscale, so yeh, Promotions does it right in this case.

[Mathias]

Ai, what are you talking about!? Hehe, crappola. I had no idea simple greyscale conversion could be so complicated. The terms "ycbcr" and "rgbp" don't appear once in Photoshop CSIII's help docs or any other Adobe CSIII's help docs for that matter. I'll look into this more, later. I'll have to see what other imaging tools I can get t deal with pixel art projects more accurately.

But, can we at least define the actual colors for the C64 pal in easy to use hex codes?
When importing a palette into a working image document it's easy to accidentally ruin it with different color space conversions, which may sometimes impose very subtle dithering when converting, thereby increasing the amount of colors in your sprite or scene unnecessarily. Having defined hex to refer to would prevent that, here's my submission, can we all agree on this? :

[Helm]

It's not a matter of agreeing on one, every c64 differs a little on its actual color ramp because of some technical reasons.

[Mathias]

Didn't know that, how odd.
But does every C64 not target the same colors, despite the actual output differing?
How much difference are we talking about?

The #7 post in this thread by ptoing does contains an image with an alternate C64 palette with much more saturation, called VIC20, but I don't know where/when it occurs.

[saimo]

Ai, what are you talking about!? Hehe, crappola. I had no idea simple greyscale conversion could be so complicated. The terms "ycbcr" and "rgbp" don't appear once in Photoshop CSIII's help docs or any other Adobe CSIII's help docs for that matter. I look into this more, later. I just don't have the tools I guess.

Do not be scared, it's easier than it seems.
To obtain the grayscale value of an RGB value just use this simple formula: (R * 0.299) + (G * 0.587) + (B * 0.114).

F.ex.:

 orange: RGB #FF8000

 ->

 R = 0xFF = 255
 G = 0x80 = 128
 B = 0x00 = 0

 ->

 (255 * 0.299) + (128 * 0.587) + (0 * 0.114)

 ->

 76.245 + 75.136 + 0

 ->

 151.381

By rounding 151.381 you obtain the value of the RGB components of gray color that corresponds to the initial RGB color:

 R = 151 = 0x97
 G = 151 = 0x97
 B = 151 = 0x97

 ->

 gray: RGB #979797


saimo

[Ai]

Didn't know that, how odd.
But does every C64 not target the same colors, despite the actual output differing?
How much difference are we talking about?

I don't know all the reasons. I do know that YPbPr is a relative colorspace, and its meaning is dependent eg on the contrast setting of the display device. YCbCr is it's digital equivalent.

BTW, I later found out that GIMP supports decomposing an image to YCbCr (with various variants) -- see the menu item Colors->Components->Decompose and choose one of the YCbCr variants ending with '256'

Also, rgbp is a pixlab internal term, sorry. It just means standard gamma-adjusted sRGB, the colorspace practically everything uses.

The #7 post in this thread by ptoing does contains an image with an alternate C64 palette with much more saturation, called VIC20, but I don't know where/when it occurs.

On VIC20 computers, naturally.
http://en.wikipedia.org/wiki/VIC20

Saimo, thanks for showing a bit more presence of mind than me Yeah, the input actually doesn't need to be normalized (at least for calculating the Y channel) and you do only need to apply the first row of the matrix to get the desired data.

[ptoing]

One reason the colours on each C64 slightly vary is because they use resistors for the colourinformation, and those resistors are each slightly different because Commodore was being a bit cheap here.

Also, that image that Mathias posted up there wants me to go all OCD over the official names of the colours, but I wont *bites fist*

[Helm]

I think Mathias shares your ocd-ness so why not give him the actual 'official' color names ?

[Gil]

I find the C64 palette absolutely lacking in the darker shades. Is anyone agreeing here? You can't do a subtle dark scene with these colors...

[ptoing]

Official names are on this page.

http://www.pepto.de/projects/colorvic/

Gil: how about this?


Also, try and compare the C64 palette to any other limited colour fixed palette of the olden days. It may not be perfect, but it is by far the best.

[Gil]

I agree it is the best, but it can still be better

Arne did a great job on his, though it favors a certain kind of look. You can't get THE best palette with only 16 colors. There's always going to be stuff that can't be done pleasingly on a small fixed palette.

As for your example image, it's far from subtle in the dark range. Try to picture a situation in very very dim light and try to pixel it. There's no colors in between that dark blue/purple color and black. Imo, that's a huge luminance jump. I don't consider the dark blue to be a very dark color, yet the next thing is full on black.

Ah well, I'm a bright color person anyway, so it doesn't really matter for me.

[Helm]

You can use asslace mode to make everything darker if you wish.

[Gil]

Yep, true enough, for a totally dark scene that'd work 

[Mathias]

Official names are on this page.

http://www.pepto.de/projects/colorvic/

The holy grail of C64!!!! Yes!

[Ai]

For completeness' sake, PC-Engine / TurboGrafx:
Sprites or tiles could use one of 32 sets of 15 colors + transparency from a 512-color master palette; the first 16 sets were usable for tiles, the second 16 for sprites. In the case of tiles, the 0th color is not used for transparency, but must still be the same between all 16 of the tile palettes.

The available RGB intensities are:
   00 24 49 6d 92 b6 db ff
(RGB 8*8*8 == 512)

[Mathias]

This is a noteworthy excerpt from that above linked page on pepto.de. I'm not sure how long that bit at the bottom has been there - the email from Robert 'Bob' Yannes.

Notice he says, this,

"I'm afraid that not nearly as much effort went into the color selection as you think. Since we had total control over hue, saturation and luminance, we picked colors that we liked. In order to save space on the chip, though, many of the colors were simply the opposite side of the color wheel from ones that we picked. This allowed us to reuse the existing resistor values, rather than having a completely unique set for each color."

The C64 palette toted as being the best severely limited palette of it's time, and it's certainly adored even now. According to that excerpt, the colors were chosen rather haphazardly, and not with complicated color theory principles in mind. Sounds like hardware geeks picked the colors out based on their preference at the time, hehe. Oh well, it works.