AuthorTopic: 32/64 colour generic palette  (Read 21301 times)

Offline Arne

  • 0010
  • *
  • Posts: 431
  • Karma: +1/-0
  • Panties.
    • View Profile
    • AndroidArts

32/64 colour generic palette

on: January 21, 2009, 01:00:08 am
It would be interesting to tackle a 32 / 64 color palette sometime. I remember Ptoing and I musing about it. It's almost daunting though, seems like a lot of work getting the most out of ramps, 'cross ramps' while covering the most useful part of the spectrum (like I histogram'ed). However, while the 'generic' 16 color palette was kind of geared towards being useful for games with smaller sprites, a palette with more colors could also be used for demo art (i.e. traced Boris Vallejo paintings ;) ), photos, etc. The, uh, color space weight field of useful colors would be different. I started a bit on a tool for visualizing how ramps relate in color space, but didn't get very far. Just imagine little pearl necklaces jumbled into a cube, cone or cylinder. with R,G,B or H,S,V tied to any of the dimensions (Radius, Angle, Height)
http://androidarts.com/palette/

A warning: Don't screencap the Color Table in PS (5.5 atleast) and rescale down to 16*16 pixels to make a palette image. I'm guessing that color profiles or something affects those colors, so they won't be the same as on the canvas.

( I may have mentioned this before, but my CRT monitor was slightly mis-calibrated when I/we did the 16 color palette. Then I re-calibrated the monitor, and it got a little better. However, now I have an iMac with 2 flat screens, but of course, there are still calibration issues. Also, one of my eyes has a red hue and the other a green. Maybe the amount of color receptors varies. Anyways, before I had calibrated at all I couldn't see any color below 20-30 (grey) well. This meant that I was mostly working in a shorter range, making my stuff too bright and grey. I have to curve a lot of my older stuff. I'm not sure if I've calibrated the palette for the iMac LCD yet, it seems the latest version is 20 and it was made on the old PC. I might need to adjust it for brighter back-lit LCD screens. )
« Last Edit: January 21, 2009, 01:04:21 am by Arne »

Offline ptoing

  • 0101
  • ****
  • Posts: 3063
  • Karma: +0/-0
  • variegated quadrangle arranger
    • the_ptoing
    • http://pixeljoint.com/p/2191.htm
    • View Profile
    • Perpetually inactive website

32/64 colour generic palette

Reply #1 on: January 21, 2009, 01:20:02 am
A 64 colour generic palette would in deed be daunting to do, but I guess overall not as hard as sorting out a very good 16 colour palette.

Could be worth giving a shot at some point :)
There are no ugly colours, only ugly combinations of colours.

Offline Gil

  • 0100
  • ***
  • Posts: 1543
  • Karma: +1/-0
  • Too square to be hip
    • http://pixeljoint.com/p/475.htm
    • View Profile
    • My Portfolio

32/64 colour generic palette

Reply #2 on: January 21, 2009, 12:34:38 pm
We need to create a VM emulating an old system running arne's palette and cool restrictions on programmers. That'd be awesome.

Also, I worked on converting Arne's to 32 colors for a project I was doing with someone else (don't remember who)

Offline Mathias

  • 0100
  • ***
  • Posts: 1794
  • Karma: +2/-0
  • im not real
    • http://pixeljoint.com/p/9542.htm
    • View Profile

32/64 colour generic palette

Reply #3 on: January 22, 2009, 02:36:30 am
A 64 colour generic palette would in deed be daunting to do, but I guess overall not as hard as sorting out a very good 16 colour palette.

How would you do that?

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

32/64 colour generic palette

Reply #4 on: January 22, 2009, 04:09:39 am
A 64 colour generic palette would in deed be daunting to do, but I guess overall not as hard as sorting out a very good 16 colour palette.

How would you do that?
Basically the same as Arne did:
http://www.wayofthepixel.net/pixelation/index.php?topic=4306.0
Some reference, some thought, some drawing; trying to maximize the number and length of ramps that can be made, etc.

Just with far more checking. With a 16-color palette, you want to check each color's relation with each of the 15 other colors, at least; and you also want the palette to have a good distribution (covering the hue and lightness gamut well rather than clustering in some areas of it). Basically just amounts to: 4x the colors, 16x the amount of checking required. A semi-automated tool would probably help to cut this down.
Another approach would be to start with a larger colorcube (eg 7*7*7 == 343 colors) and automatically remove the 'least different' colors until the count of colors reaches 64. There's definitely room for some automation as a basis with 64 colors.
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Arne

  • 0010
  • *
  • Posts: 431
  • Karma: +1/-0
  • Panties.
    • View Profile
    • AndroidArts

32/64 colour generic palette

Reply #5 on: January 22, 2009, 04:48:13 am
I don't think it can be easily automated. If you do 7^3 colors you end up with a lot of bad unusable colors, in particular greens, purples and neons, missing a lot of usable colors, and also make the ramps jaggy. I once made a 3D RGB histogram by sampling photos, game screenshots etc to see what colors are the most common. Perhaps that data can be used to distort the 7^3 grid, then ramp recognition routine could align the colors into lines/curves... but I'm not sure if writing such a thing is possible. Maybe something... Gaussian. There'd still be a lot of (for the computer) arbitrary parameters though, and I think an artist would have to be involved.

A while back I wrote a sodaplay'esque thing. It's easy to write in a way. The points just tug each other, trying to stay at certain distances. My 3D histogram was extremely populated in the grey areas. By setting a minimum distance for the points, but making the populated areas magnetic, it might be possible to have the points form a cluster with varied density, and also have a 3D hexagonal pattern... which may or may not be useful. If you do the same thing in 2D the points will settle into a hexagonal pattern.

I think it's easier to use something like my color space visualizer and just manually place the colors, while making sure to space and cross the ramps properly.

I discovered too late with the 256 color Cortex Command palette that I had neglected ramps (as well as monitor calibration). Most of that palette was made with automated processes (Partly Photoshop which I think uses a low res RGB histogram cube with thresholds of some sort). I went in and removed unneeded and too close colors with a program I made, but as it turned out, you can't neglect hand tuning ramps even with as many as 256 colors. I'll have to redo that palette some time :/
« Last Edit: January 22, 2009, 04:52:22 am by Arne »

Offline Mathias

  • 0100
  • ***
  • Posts: 1794
  • Karma: +2/-0
  • im not real
    • http://pixeljoint.com/p/9542.htm
    • View Profile

32/64 colour generic palette

Reply #6 on: January 22, 2009, 05:43:31 am
Sounds like a colossal task, and one that would be very difficult to finally determine as complete and finished. Seems like a person would want to always tweak it from time to time. So many colors, how could you not.

Does it have to be a binary friendly number? Why not 47, for example? I too, default to numbers like 8, 16, 32, 64, etc when thinking about such things, but are these rules applicable in this situation?; Why an arbitrary limit?

And isn't 64 a bit much? What low-color games use 64 colors at once? That's enough for full gradation in smaller more monochromatic/less colorful sprites/objects, maybe not a big gradiently shaded sunset bg for instance, but certainly smaller things.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

32/64 colour generic palette

Reply #7 on: January 22, 2009, 06:00:31 am
I don't think it can be easily automated. If you do 7^3 colors you end up with a lot of bad unusable colors, in particular greens, purples and neons, missing a lot of usable colors, and also make the ramps jaggy.
..If you are calculating the colorcube in sRGB, that's true. I find L*a*b colorcubes (as used in eg. http://pixeljoint.com/pixelart/13313.htm) more usable. L*c*h might be even better, I'll see. Anyway it's true that a plain colorcube doesn't work particularly well. More like a 14-shade L ramp applied to seven 7*7 squares of a*b* or circles of c*h*, with a little foolery to avoid duplicating grays+whites.
Like a better done version of the palette used by http://pixeljoint.com/pixelart/13313.htm#

Quote
I once made a 3D RGB histogram by sampling photos, game screenshots etc to see what colors are the most common. Perhaps that data can be used to distort the 7^3 grid, then ramp recognition routine could align the colors into lines/curves... but I'm not sure if writing such a thing is possible. Maybe something... Gaussian. There'd still be a lot of (for the computer) arbitrary parameters though, and I think an artist would have to be involved.
Yes of course. As a basis, as I said.
It is possible. IMO it would make more sense to convert that RGB histogram into LAB or LCH, then automatic fitting would be pretty simple and reasonably reliable. Might also be interesting to see what GIMP makes of your test data, since it does color reduction in LAB colorspace.

What it came up with is pretty similar to c64 palette. If I apply unsharp mask radius = 2 amount = .25 beforehand, even more so.
Additionally applying auto-whitebalance, I'm pretty happy with the resulting 16color palette.


Not so happy with the 64-color palette it picked. (I suspect the result would be better if using the fullsize test image though)


Quote
I think it's easier to use something like my color space visualizer and just manually place the colors, while making sure to space and cross the ramps properly.
I hope that's visualized in linear RGB rather than standard sRGB.. otherwise it'll suffer major distortion (eg a perceptual curve can appear straight, and a perceptual line will appear curved.) Even more so for HSV/HSL visualization.


Quote
I discovered too late with the 256 color Cortex Command palette that I had neglected ramps (as well as monitor calibration). Most of that palette was made with automated processes (Partly Photoshop which I think uses a low res RGB histogram cube with thresholds of some sort). I went in and removed unneeded and too close colors with a program I made, but as it turned out, you can't neglect hand tuning ramps even with as many as 256 colors. I'll have to redo that palette some time :/
One of the criteria I found was to maximize vividness at about 75% intensity so that you have a ramp somewhat-gray .. bright clear color.. whitish. Most programs I have found don't address that. GIMP does address that somewhat.
« Last Edit: January 22, 2009, 06:35:29 am by Ai »
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Ai

  • 0100
  • ***
  • Posts: 1057
  • Karma: +2/-0
  • finti
    • http://pixeljoint.com/pixels/profile.asp?id=1996
    • finticemo
    • View Profile

32/64 colour generic palette

Reply #8 on: January 22, 2009, 06:33:44 am
Sounds like a colossal task, and one that would be very difficult to finally determine as complete and finished. Seems like a person would want to always tweak it from time to time. So many colors, how could you not.
Hence, some automation tool is needed. Surt had some idea about fitting colors to splines to determine 'good' ramps, and I have an algorithym which finds all reasonable available ramps; these are the main things that would be desirable in a tool: tunable subjective judgement of color/palette 'kwalitee' in conjunction with objective judgement of color/palette 'kwalitee'[1]
Quote
Does it have to be a binary friendly number? Why not 47, for example? I too, default to numbers like 8, 16, 32, 64, etc when thinking about such things, but are these rules applicable in this situation?; Why an arbitrary limit?
Because of premature optimization.

Binary-friendly means no values are wasted.
Say you use a 48-color palette. You are then obligated to store your sprites in at least 6bpp format,  and 6bpp provides 2^6 == 64 different values, why not use those extra values then?
Storing the palette itself can be more convenient with a power-of-2 sized palette, too, because 3*NCOLORS*BITSPERCHANNEL always fits into an exact number of bytes when NCOLORS is a power of 2  >= 8

Of course you can use a 48 color palette, there is no good reason not to. Just, on current systems, the 'perfect fit' of power-of-2 sized palettes is seductive.

Quote
And isn't 64 a bit much? What low-color games use 64 colors at once? That's enough for full gradation in smaller more monochromatic/less colorful sprites/objects, maybe not a big gradiently shaded sunset bg for instance, but certainly smaller things.
SEGA Genesis / Megadrive uses 62 colors at once (two layers with 15c+transparency, two layers with 16c).

[1] kwalitee: "It looks like quality, it sounds like quality, but it's not quite quality."
http://pycheesecake.org/
If you insist on being pessimistic about your own abilities, consider also being pessimistic about the accuracy of that pessimistic judgement.

Offline Arne

  • 0010
  • *
  • Posts: 431
  • Karma: +1/-0
  • Panties.
    • View Profile
    • AndroidArts

32/64 colour generic palette

Reply #9 on: January 22, 2009, 03:49:57 pm
Yeah, I noticed when doing my HSV, HSL, etc color space plots that you get distortions on straights and curves. But I think it's actually not a huge deal, because it's only the relations of the colors you're after. You only really need to see if the curve/line is consistent and how the ramp relates to the other ramps, and what part of the color space you've left untouched. In my program I have the ability to swap... for example HSV to HVS, or change formula for calculating intensity/ grey value. I just want to give the user the ability to see the color space in many different ways to get a feel for things.

Another issue is that of halfbrites. If we're talking old hardware, halfbrites could be useful when doing shade and light effects, like shadow and spotlights. The indexes of the different colors would have to be layed out so a shl/shr (?) and other operators would do... neat things. Yet another thing to think about is reserved colors for flashing, copper, masks, etc.

Then there's the grey value approach that the C64 palette uses to... bridge colors. With a 64 color palette, it may or may not be as useful.

Of course, the palette could actually just be a help or starting point, and not have anything to do with hardware. Most games are 24/32bit these days. In my latest project I made a separate masked image to allow me to flash a color...


« Last Edit: January 22, 2009, 03:53:54 pm by Arne »