--- Expanding the C64 palette to 32 colors ---

[Mathias]

Currently engaged in a game project. All graphics use only the Commodore 64 palette. After already completing quite a bit of art, the game is now changing significantly.

As a result I feel the C64 pal is now inadequate for what I want to do with the game's art, since a slightly different art direction is being chosen. So I set out to "update" it.

Unfortunately, I assumed I could remap the palette easily and quickly with new/better colors, while not manually re-pixelling any existing art. But no. This was a naive notion on my part. Afterall, the C64 palette is a good generic 16 color palette. Not easily thwarted.

-- View a quick test --

So, that was a failure. Learned, and moved on.

___


Rather than alter the existing pal, I'm just going to add to it, round it more. That way the existing art can stay and not require updating, and at the same time I can create new game art with the new colors.

Sven suggested I not exceed 32 colors for the new expanded C64 pal. I agreed.

So, the idea is to add 16 more colors. I suck at palette creation. Never tried it before actually. With so many great palettes readily available I haven't had the need until now.

___


Let's get started.

The rest of this post is pretty much images, since this is an inherently visual/graphical issue, I figure why not. I hope the following images are decipherable. They convey my C64 pal editing progression.

Notice, the first thing I do is investigate the existing C64 pal's underlying luminosity values.







Disappointing, but this is as far as I've gotten. I'm hoping for some insights from you Pixelatians.

I get the haunting feeling I should have more midtones and less darks and lights. As of right now, my luminosity range is pretty much an even gradient from black to white, with a little bias towards shadows (mainly because I've always wanted more darks in the C64 pal).




Thoughts?

[ptoing]

I see you have somewhat averaged the closeness of the light blue/grey and light red/green lumapairs. Those are very close on the real thing, almost so close that they can be used for almost invisible PAL blending with each other.

Also, the nice thing about the lumapairs on the real thing is that you can get new colours by arranging them in lines. Like alternating likes of blue/brown/blue and so on will yield a new colour, and you acutally get a different one if the first colour is brown (depends on which colour is on odd or even lines I think). So you can actually get 14 new clean colours like this and with the mixing of the 2 close pairs a bit more (not as clean).

This effect tho you can not do see on a PC monitor (apart from some emulators and there not quite perfect yet), it has to do with how the PAL signal works.
So perhaps you should make a call on which colour you want darker in each pair, and give up on the lumapairs, which are only good for really really subtle tinting, and to be honest I do not see any subtle tints in your stuff to begin with, everything is very poppy and bright. Maybe worth a try.

[Mathias]

So, you're basically saying that the lumapairs is pointless on a PC?

One reason I like the lumapairs is that it simplifies using the palette - when you're shading something you only worry about 16 shades, with my new palette. If each color was a different luminosity, you'd have 32 shades to worry about. Not a bad thing, though . . .

I dunno. Seems like a major decision I better make right now, before going further. Can't decide . . .

[HughSpectrum]

I'd probably recommend, especially for your darks, to use teal and a dark gold at the very least.  I find that these colors do a good job of having a similar effect to greyscale where they act as buffers to many other colors, which should make them useful for shading.  A bluish-purple should work too for shadows and the like (since it's also an intermediate color).

Not sure about the light colors.  Maybe a tan (which would make be useful for skin and buffering alike), but I don't work with light colors often enough to really know what should be there.

[Helm]

Α global palette over 16 colors is counter-intuitive. What you're doing imo doesn't achieve a step up from the original palette, regardess of the interesting SCIENCE! behind it. Just take the plunge and either work with 8-bit limitations or not. Middle-steps do not achieve an esthetic end, and you can't improve 8-bit artwork just by throwing more colors at it, you'll have to repixel it.

[Mathias]

I'll keep that in mind, Kitten. Thanks.

Α global palette over 16 colors is counter-intuitive. What you're doing imo doesn't achieve a step up from the original palette, regardess of the interesting SCIENCE! behind it. Just take the plunge and either work with 8-bit limitations or not. Middle-steps do not achieve an esthetic end, and you can't improve 8-bit artwork just by throwing more colors at it, you'll have to repixel it.

True, part of why I'm doing this is the interesting science behind it. But, I'm not really trying to improve the C64 palette; once out of the 16 color realm we enter a different "bracket".
Working with 8-bit limitations was never my intention. Originally, deciding to use the C64 pal was meant to capture some automatic nostalgia, but is now a detriment.

Agreed; adding more colors doesn't improve/fix, therefore ALL game art objects will not have more than 16 colors. Imposing this restriction disallows me to repixel the large story screen images (such as the one used in the "tests"), since they all already have the original 16 colors, and preserve the general "graphical depth" of all new game art assets.

This initiative to expand the C64 pal may or may not be particularly useful to others, but for me, it at least solves a specific problem and will allow me to move forward with my game art creation.

__

Right now, I'm trying to decide:

1) Whether I'm ditching lumapairs.
2) If I should focus on more midtones instead of shadows. The orig C64 pal is mainly midtones. My underlying luminosity ramp may need weighting towards the middle-range.
3) Add in more grey colors like orig pal?

[yrizoud]

You may want to try DawnBringer's perceptual lightness, to see if it shows different "gaps" where an extra color with a unique lightness would fit.

sqr[(0.26*r)^2, (0.55*g)^2, (0.19*b)^2] , multiplying with 1.56905 normalizes to a scale of 0-255

RGB is notably a bad space to work in, things that are mathematically "pretty" (even statistical distribution, linear interpolation) will not produce the best visual result.

[Mathias]

what

[ptoing]

you can do it in google with this (if i understood him right)

Code: [Select]

(sqrt((0.26 * R)^2 + (0.55 * G)^2 + (0.19 * B))) * 1.56905
Where the result would be a number which you enter for all 3 values to get a straight grey.

I just tried it with one of the c64 colours and it is the same result as going greyscale in Promotion.
Which might have been a fluke. Just tried another colour and it did not produce the same grey as it does in PM (and as is the proper luma value)

[Mathias]

Crap that reminds me, I'm applying luminosities to each color with  . . . PHOTOSHOP.

Will have to proof PS's output against PM's and make necessary adjustments. OR I can figure out PM's palette gizmos and work exclusively in PM for all this. (but I doubt it)
OR OR
sven can do it all for me!

[yrizoud]

Here's the result of calculation, reordering the colors according to this formula:

[Ai]

Yeah, that formula performs fairly well;It's not quite right, though.
In particular, colors #1 and #2 are swapped, in terms of brightness, as are #3 and #4, #7 and #8

Here are the brightnesses, sRGB intensities calculated via LAB colorspace (using GMIC_gimp custom command "-srgb2rgb -rgb2lab -sh 1,2 -*[-1] 0 -rm[-1] -lab2rgb -rgb2srgb -round"):

0 69 68 86 84 102 105 126 128 137 153 171 180 212 217 255

(this doesn't pick up on the problem with #7 and #8)

And a version calculated via YCbCr: ("-srgb2rgb -to_rgb -rgb2ycbcr -channels 0 -rgb2srgb -round")
(This 'feels' a bit more accurate to my eye)

0[clipped] 96 100 111 105 126 122 141 137 149 150 172 176 204 205

(here the problem with #7 and #8 is picked up, but not the one with #1 and #2.  )

All of them pick up on some errors, but I haven't seen an implementation of any colorspace that's fully perceptually-correct yet.

I began trying linearized RGB with DB's coefficients, but haven't got GMIC to cooperate yet.

[Mathias]

Wow you guys! Some serious math goin' on there . . . uhm so let me see if I understand what's being done - you're taking RGB values and calculating the correct greyscale value from them?
Does the math really matter, though? A palette is such a visual thing. Does it matter if it's mathematically sound? It has to look right to the eye. And even that is subjective. Don't get me wrong, I highly appreciate the math figures being thrown around. Greyscale conversion is the ONE thing, in my workflow, that I HAVE to use ProMotion for. Photoshop doesn't do it right. I don't know of any other software that greyscale converts a color correctly.

I was going off of this at first, to make an even ramp, which I ditched - 100 / 32 = 3.125  -OR-  255 / 32 = 7.968. 32 equal lightness steps.


I've decided to ditch lumapairs and just go with a 32 step luma ramp for the palette - here's the ramp I've worked out:



It doesn't alter the original colors much at all, while lightening up the dark end, creating a larger midtone range in the palette.

I plan to soon to fill in the missing colors. One idea I have for that is to attempt to represent each main RGB spectrum component (Red, Green & Blue) every 3-6 shades. Secondaries and even tertiaries will hopefully make a sufficient appearance. No idea yet . . . we'll see. Might get some time to work on this tonight.

If you feel like taking a crack at inputting some new colors into the future pal, by all mean go for it; would love to have another's palette attempt to bounce my own off of.

[yrizoud]

After his successful search for a 16-color palette, Arne had a try at a 32/64-color one. It may be interesting to watch the process.

[Helm]

Straight up, your two darkest and your two brightest are interchangable, too close they're wasted. Unless you plan to use some supersaturation on them, they won't read as different colors to pure black and pure white.

[Mathias]

After his successful search for a 16-color palette, Arne had a try at a 32/64-color one. It may be interesting to watch the process.

Bugger! I forgot he started a generic 32 color palette project. I'll read that thread thoroughly. Why did it halt I wonder. Thanks, yrizoud.

Helm, you're right. The extreme ends of my little gamma ramp are unsurprisingly troublesome. Monitor profiles can even come into play. I'll certainly pay attention to darkest and lightest colors as I proceed.




*EDIT

[Mathias]

I'd say my palette isn't too bad at the moment. Though I haven't really used it yet. Here it is, in version 3.






Hard to judge a palette without work made with it. Will have to remedy this soon . . .

[HughSpectrum]

I personally can't tell the difference between colors 1 & 2.  5 & 6 are also very similar despite being very different hues.

[Mathias]

Important feedback. Thanks. Not sure how to levy gamma issues across displays. Every display is different. Calibrations, etc. Perhaps I should just lighten the dark end some more.

[ptoing]

If you can not tell the difference between colours 1 and 2 your monitor is set too dark I am afraid.

Colours 5 and 6 however are very, very close in perceptual brightness, which does not mean that they are not helpful tho. Would have to be tested I would reckon.

[Tourist]

If you can not tell the difference between colours 1 and 2 your monitor is set too dark I am afraid.

Not necessarily the case.  The png files that Mathias posted include both an ICC profile and chromaticity data in the header chunks.  Here are the files with that information stripped out, just the raw RGB colors (verified with a hex editor).





If these colors look different than the post above, it is because your browser is interpreting either the color correction profile, or the white point, and adjusting what you see.  If the images look the same then either your browser is ignoring that information or your setup is similar to the one Mathias has.

Yay for software trying to help us.  ("I know the palette says xx, but I'm sure he means yy").  See also test pages
http://www.libpng.org/pub/png/png-gammatest.html
http://www.libpng.org/pub/png/png-colortest.html

Tourist

[Ai]

Let's not forget KittenMaster's side of it: setting his display profile correctly in the first place.
(And Mathias -- choosing the right image color profile)

Desktop color-correction is still young and quirky. Raw RGB values without a profile attached, only have very vague meaning ('something that looks somewhat like sRGB.. maybe if you squint')

[Mathias]

Thanks, Tourist. I see that your stripped-out version loses a very slight bit of saturation compared to mine (load them both up in different browser tabs and toggle back and forth to a quick/easy comparison). Virtually no difference really. But, I don't understand why they are different. I get that the ICC instructs the computer/program "how" to interpret RGB values, but honestly, beyond that the science of it all just doesn't jive for me . . .


AI, I use the same color profile for all my RGB Photoshop projects - the one that came with my dual monitors: "Samsung - Natural Color Pro 1.0 ICM". It makes everything look correct in my Photoshop. I realize that browsers pretty much all use sRGB, but my images usually translate quite well once saved from PS and displayed in a browser, such as when I host 'em somewhere and link them in a forum.

[Ai]

I get that the ICC instructs the computer/program "how" to interpret RGB values, but honestly, beyond that the science of it all just doesn't jive for me . .

Okay, Color management 101:
* All color management depends on having TWO color profiles. One is for the image data. The other is for the display. We could call these 'source' and 'target'
* That combination of two profiles allows the computer to calculation the relation between them, and transform the data using that, so that it displays as intended. To be more explicit: the actual displayed RGB values change, to match the original appearance of that color.
* The above is an ideal scenario. Most commonly, people don't have color management setup (in which case, the browser assumes sRGB as a target.. hopefully. Some just don't color manage at all.). Fairly commonly, artists don't have color profiles setup; or they have assigned their display profile as the image profile (this seems to be what you did), which effectively disguises that their settings are exactly the opposite to what they should be.
* As a rule the image profile (commonly known as 'working space') should be something standard (if you can use sRGB, do so; otherwise, there are Various other working spaces, kindly catalogued by Bruce Lindbloom)
* The display profile should accurately describe the color characteristics of your monitor. Some professionals use colorimetry devices to recalibrate their display profiles every 1-2 months. It's generally a good practice to assume the viewer is running uncalibrated sRGB (and so, make sure your image is converted to sRGB -- the best you can do overall -- when you are exporting a file to show on the web)

Charles Poynton accurately describes the details, wherefores, howtos, etc in his Color FAQ

[HughSpectrum]

I just used Windows 7 to configure my monitor in conjunction with a monitor calibrating site.

Tourist's image does indeed appear slightly lighter, and colors 1 & 2 are more distinguishable.

[Mathias]

oh god . . . I'm going to die in this color management hell . . . leave me AI, just leave me . . . there's no hope for me . . . go . . . JUST GO!!!14

Gaaaaahhhhhhh arrrr . . . why  . . .



I will try and read that color FAQ PDF. In the digital realm, I feel like an alien from War of the Worlds; the mere basic nature of the environment itself is hostile towards me and if not careful, deadly. Time to get my color legs. Thank you for being you.

[Tourist]

Ai : I agree, although I would use stronger language than 'quirky.'    

When folks talk about png images being too light or dark, the culprit is usually an embedded gamma correction chunk.  Since these files didn't have one, I agree the problem is likely KittenMaster's setup.

Mathias:  Eh, don't worry so much.  You're not calibrating an input device like a camera or scanner, so just use sRGB for your pixels.  Calibrate your monitor.  Done. 

When I look at your colors, I see too many light pinks (29, 30, 31), too many blue shades (middle row), and probably too many dark colors (first column, and #2) for my tastes.  But I don't have a different methodology to offer.

Tourist

[Ai]

Tourist: I don't think you agree with me. Specifically, I think KittenMaster's setup is probably okay. I believe that Mathias is not using sRGB for his pixels.

Mathias: If I've understood the situation correctly, at least for pixel art, you need to use the sRGB profile for your image, and that Samsung profile for your display (rather than your current situation, which seems to be approximately the reverse -- Samsung on the image, sRGB assumed as default for your display). Last thing I heard, the default image profile ('working space') was in the preferences, for Photoshop (http://www.computer-darkroom.com/ps10_colour/ps10_1.htm). The display profile is something you set system-wide. It's possible you have a Samsung utility to do this -- I don't know how that works on Windows.

If you do prints, it's also important to get this handled.  A lot of printers expect sRGB, and depending on how well your color management is setup, sending non-sRGB data can result in outputs that are simply wrong.

[DawnBringer]

Interesting stuff. This is the result produced by my "Expand Palette" Grafx2-script (It comes with the program...but this was produced with an updated/improved algorithm I think).
It "Continously fill the greatest void in the area of the color-cube enclosed by (or along ramps of) initial colors. This algorithm will create lines of allowed colors (all ranges) in 3d colorspace and the pick new colors from the most void areas (on any line)."

It probably won't produce a perfect result (whatever that may be)...but it's a good place to start if you prefer a uniform looking palette.