Palette talk

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

User avatar
sheamkennedy
Liquid Metal Slime
Posts: 1110
Joined: Mon Sep 16, 2013 9:29 pm
Location: Tama-shi, Tokyo, Japan
Contact:

Post by sheamkennedy »

That PalEdit thing is great! Saves me a lot of trouble creating a nice set of desaturated palettes for my game. Thanks!
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
User avatar
Mogri
Super Slime
Posts: 4668
Joined: Mon Oct 15, 2007 6:38 pm
Location: Austin, TX
Contact:

Post by Mogri »

sheamkennedy wrote:That PalEdit thing is great! Saves me a lot of trouble creating a nice set of desaturated palettes for my game. Thanks!
Then you'll love this.

I've overhauled PalEdit to allow you to customize your ramps. Here's how it works:
  • Generate your initial palette using the settings you like. As you go, you can use the Save/Load buttons to keep ones you like. (Your palettes are remembered even if you close the browser and come back, as long as you're on the same computer.)
  • Once you have something you're happy with, you can start hand-editing your palette. Start by clicking on one end of a color ramp and dragging to the other end. This will highlight the selected colors and open a new menu.
  • The new menu allows you to specify a start color and an end color. You can do this in RGB or HSV, whichever you prefer. After tweaking the colors, click the Ramp button to alter your palette. You can use the Copy/Paste buttons to store the values in the form and paste them onto a different ramp.
Color selection is freeform, so you can highlight multiple ramps or part of a single ramp. But once you click on the Ramp button, the selection is treated as a ramp, regardless of the size of your selection.

I've attached a sample palette that I created yesterday. The UI isn't perfect, but it's got the basic feature set that I wanted from a palette editor (aside from a "download BMP" button - but it's simple enough to just screenshot and crop).
Attachments
Palette (large)
Palette (large)
hueshift.png (4.76 KiB) Viewed 7542 times
Palette (importable BMP)
Palette (importable BMP)
hueshift.bmp (822 Bytes) Viewed 7543 times
Last edited by Mogri on Wed May 20, 2015 5:32 pm, edited 1 time in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Cool, but it doesn't seem to work in Firefox 37. I can't drag to select a ramp; only the first colour gets selected by a box. The selection also seems to disappear after I release the mouse cursor, as changing the values and clicking Ramp it up does nothing.

I went to create a small page about this to the wiki, but there is already a utility called PalEdit. Not sure what you want to call it, "Mogri's PalEdit"?
User avatar
Mogri
Super Slime
Posts: 4668
Joined: Mon Oct 15, 2007 6:38 pm
Location: Austin, TX
Contact:

Post by Mogri »

Opps! I had tested in Firefox and I got halfway to fixing the bug, but apparently I got distracted by something and never finished the fix. It's working now.

I've changed the page title to "Palette Pal," so you can call it that instead.
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

Does anyone know of a decent way to convert an old palette to a new one if, say, the old palette uses 16-color ramps and the new one uses 4 or 8 (or whatever)?

As much as I'd like to update my old game from the OHR's original palette to one of the newer, more color-diverse ones, my concern is often that the change inevitably screws up color schemes across the board, and when you have thousands upon thousands of graphics assets to update, it's probably too much work to justify changing the master palette.

So, my question is that would there ever be the possibility of having a "smart conversion," where the new palette tries to match the old one as closely as possible based on the current colors available, making any other necessary changes minimal?

And does that make sense?

To rephrase: If we have the ability to store a number of master palettes in the engine, it might be nice to have some kind of justification tool that plugs in colors from the selected palette over colors used from the source palette (if the graphics were already set to use the source palette, and you want to convert them as quickly as possible to the new palette). And if we already have that ability, how do we do it?

To be clear, I'm not asking for the ability to rewrite a palette based on an old palette. I'm asking about the ability to redistribute the colors from the new palette to the in-game graphics (sprites, tiles, etc.) based on the colors used from the original, or in more technical terms, source palette that the user defines as being the palette he used to create the graphic. So, if I want to convert my yellow beach sand to something more tan, but I don't want to convert all of my yellows throughout the game to tan, and if I have eight different shades of yellow represented in various places throughout the game, is there some way I could use a conversion tool to detect the eight shades of yellow used throughout the game, reduce each graphic to the nearest yellow as represented by the new palette (which may have its yellows positioned where the original palette might've positioned its 16 green colors), thus keeping the original look of the game mostly intact (with some variances to shades), while allowing me the use of new, non-interfering colors? So, I could keep my yellow buildings and yellow carts and stuff, but give my beaches tan sand and my characters blond hair?
Place Obligatory Signature Here
User avatar
BMR
Metal King Slime
Posts: 3310
Joined: Mon Feb 27, 2012 2:46 pm
Location: The Philippines
Contact:

Post by BMR »

This is the palette I use now:

Image

Doesn't have as many really high-saturation colors as the one I have on the wiki, but it works for the style of stuff I do. It still needs a bit more tweaking though, as some colors are still a bit too close to others. Still, I can get pretty good ramps for most things, so it works for me.

Speaking of, I should prolly change the one I have on the wiki, or at least add this one as well.
Being from the third world, I reserve the right to speak in the third person.

Using Editor version wip 20170527 gfx_sdl+fb music_sdl
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Pepsi, I didn't understand everything, but it sounds like you're asking for two different things.

Firstly, a tool to switch to a different master palette, and modify all 16-colour palettes, tilesets and backdrops to use the nearest colour in the new palette to the old colour. Yes, there's a tool for that:
http://rpg.hamsterrepublic.com/ohrrpgce/CHGPAL
It's quite old so would need updating to handle portraits and box borders. Also it doesn't handle things like slices and UI colours, but the engine has builtin remapping of UI colours.
However in practice you'll probably be disappointed with the results. Typically multiple colours in the original palette will get remapped to a single colour in the new palette, meaning that ramps get converted to solid blocks of colour. Or two similar shades of blue get converted to green and grey. This is more likely the harder it is to find a match in the new palette. However at least you can fix up 16-colour palettes manually.

The second thing you were talking about seemed to be to remap colours, changing sand from yellow to tan. There's no OHRRPGCE-specific tool to do that; I would export the graphics, remap colours using a graphics editor and reimport.
Last edited by TMC on Fri May 22, 2015 5:28 am, edited 1 time in total.
User avatar
Pepsi Ranger
Liquid Metal Slime
Posts: 1457
Joined: Thu Nov 22, 2007 6:25 am
Location: South Florida

Post by Pepsi Ranger »

No, I was asking for one thing, and your first answer was what I needed to know. Thanks.

The yellow-to-tan was an example of why I would want to change the palettes, but also why I don't want to lose the colors already established in the game.

It sounds to me, though, that CHGPAL doesn't consider degrees of color needed for lighting or shading, so I can see where that would complicate things, and maybe even leave the whole conversion process undesirable. I'll have to experiment with it to see if it's something I even want.

But it does sound good for small games. At any rate, it's better than nothing.
Place Obligatory Signature Here
User avatar
shakeyair
Slime Knight
Posts: 217
Joined: Fri Jun 12, 2009 6:15 am

Post by shakeyair »

Pheonix wrote: Image
Love these colors

EDIT: Especially that magenta ramp. And the top sort of orange-ish crimson one.
Last edited by shakeyair on Tue May 26, 2015 7:51 pm, edited 1 time in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

I'm not aware of any palette tweaking tools anywhere that are aware of ramps, contrast, and shading. That would be a very hard problem to solve.

Rather than using a palette I ended up using the one James posted. However I haven't really been using the ramp. I notice that there are still lots of similar colours in that palette, if you cut across different ramps. I need to develop the habit of picking out a few colours and sticking to them instead of having no plan and using blending and shading tools which use the nearest match.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

(don't remember if I ID'ed myself here before, but I was previously known as Neo)
It's interesting to see what you all think of my palette, after some time of using it.

I was disappointed shortly after it became the new default palette, when I realized people were just using it like it was a bunch of 15-long ramps. But it's actually carefully designed so you can cross between ramps at many points, so instead of 17 15-long ramps you have about 64 - 96 ramps of all different sizes.

A clear case of foolishly expecting the -user- to automatically understand the things that -you- know.

(I actually originally arranged it into large ramps because I thought that was what people expected, honestly. But it had always been planned as a 'reassemblable' palette)

To illustrate, here's a very quickly resorted version of the exact same palette, thanks to GPick:
Image
Large version:
Image

Nowhere near optimal sorting , but hopefully shows some different rampings you hadn't considered.
I also found this:
Image
Image
Which I'm pretty sure is also a resorted version, of a slightly earlier revision of the current OHRRPGCE default.

But WRT lacking orange, that's quite accurate. I tried to consider it but clearly was over-concerned with ramp crossover (it's hard to crossover if colors are too saturated)
Having too much purple is also obvious in retrospect.

----

Pepsi Ranger:
CHGPAL doesn't consider degrees of color needed for lighting or shading
Not sure what you mean by that, Pepsi. All I can say is that it simply examines the old palette, and finds a 'best match' in the new palette for each color in the old palette. The rest of the code simply applies that, with a small level of intelligence, to the graphics in the RPG file.

There are a number of things that could be improved about it:

* matching is RGB based. That is quick, but it doesn't need to be quick. Using LAB based matching with CIE94 Delta-E color difference formula would likely give much improved results. This mainly requires a sound LAB<->RGB conversion system -- GIMP 2.8 has a largely self contained one in the files 'cpercep.[ch]'

* A mode that forces every source color to remap to a different destination color index would guarantee no information loss (unlike the current state, where as TMC observed, multiple source colors may map to a single output color). Be aware that this almost certainly would look ugly, since some colors would inevitably be assigned output colors that are bad or even incredibly bad matches. IIRC that is why I originally didn't implement such an option.

* being uptodate as TMC mentions, of course.

* If you were being more ambitious, you could also detect particularly bad matches and replace them with a dithering between two colors. This would require a rework of the code though (in order to actually parse the images as 2d rectangles, rather than just considering them as 1d arrays of palette indices).

* some way to output the translation map in a way that lets the user edit it (and of course a feature that would apply such a saved map) so that they can change any mappings they find unsuitable. Maybe a 2x256 image?

----
James:
I know I made a palette with a bunch of 5-ramps in it at one point, and overall that palette reminds me of me, as Gizmog suggests, but I'm not completely sure. Well, whatever.

In any case, as TMC points out, there is some degree of duplication. Which may not mean it's a poor palette. I'm beginning to think that providing a format that people easily grasp is necessarily going to result in, at least, some very similar colors.

----

Palette Editing
I'd like to recommend GPick for any palette editing -- it doesn't have all the esoteric features I put in PalEdit*, but it is much more powerful and has really nice tools for building high quality ramps and reordering palettes.
However, it does seem that currently it's only available for Linux (there was a Windows build, but that seems to have gotten lost in the migration to Github. I'll file an issue.)

If you can't use that, the palette editor included in GrafX2 is also quite capable.
If you just want to rearrange an existing one, GIMP's 'Rearrange colormap' plugin is not bad either.

*Not to be confused with Mogri's tool.

---
Generic 256c palette - what I originally came here to post

I found this palette on the web: http://kim.oyhus.no/Palette256.html
It is a generic palette, essentially a much-improved version of the standard web palette.
Here it is "unsorted":
Image
Image



And quickly sorted:

Image
Image

With a little more sorting work, I think it would be a good contender for a default palette. Should be pretty simple to arrange it into 64 ramps that are 4 long, for example.

(It's also licensed under GPL, for whatever the heck that's worth for a palette, so including it should be okay.)

---

Palette Editing, or wizard?
The comments people have made in this thread have led me to think that maybe having a monolithic 'master palette' is not what people really want. I mean, obviously the current limitations require the use of a master palette, but it seems to me that there is room for a simple tool that just allows the user to select between saved 'ramps' and put them together one by one into a master palette. A sort of 'master palette creation wizard', I guess, with basically four functions: 'add a ramp', 'remove a ramp', 'resize ramp', and 'reorder ramps'. Maybe also an option that would detect and remove duplicate colors.

Just putting that idea out there as I feel that the potential for a single set of 256 colors, no matter how well chosen, to suit everyone's tastes well, is quite low, and obviously a kind of 'component-based' model lets you get an 'approximately-right' palette together quickly.


(YOU HAVE MADE IT TO THE BOTTOM OF THIS POST, CONGRATULATIONS!)
(I considered double or triple posting instead, but that seemed uncivilized)
Last edited by 0ion9 on Sun Oct 04, 2015 12:52 pm, edited 10 times in total.
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

I don't think it's rude to triple-post and that it's a misguided etiquette, it's much easier to see what's new than editing a previous post (in this case I forgot to check back).

Actually, your palette did teach me to use cross-ramp colours, and that's the way I used it. However I feel the benefit is much-reduced if you just use a soup of colours like I tend to, instead of picking out your own ramps and sticking to them.

I was actually interested in using something like the CIEDE2000 colour distance when importing graphics into the engine, but that's hideously complicated. The CIE94 you mentioned is considerably simpler and more reasonable, so I think I'll use that. And thanks for the pointer to GIMP's LAB implementation. I also added an implementation of Floyd-Steinberg dithering (not finished and merged into SVN) and wanted to try using something better than RGB distances in the FS dithering. See here for details & examples. There are surprising differences between GIMPs implementation and mine, which I suspect are due to 1) GIMP probably doesn't use RGB distances, 2) the OHR default palette sparsely/doesn't cover a lot of the colour space, which changes how such an algorithm should be tuned. But neither of the two give acceptable results.

Regarding forcing an injective mapping, that could indeed give very bad results if the input uses a large number of colours. Violations of injectivity ought to be allowed, by applying penalties instead of strict constraints, ideally in addition to using better than greedy selection.

That sphere-packed palette is interesting, it does sound a lot better than Web216. And as I said, the poor coverage of the current default palette is readily apparent in the huge errors when remapping to it. The use of the GPL is very dubious though. Can you copyright a palette? I've never heard of anyone claiming ownship over such a thing. But if you can, then a GPL palette certainly can't be used as the default OHR palette.

Having a single default or common palette does have a large advantage that it removes all problems with remapping when importing. There are now sets of free graphics available, like Vikings, which almost require using the original master palette. Solving this longterm by moving to 24 bit graphics is still the plan.
Last edited by TMC on Wed Oct 07, 2015 3:50 pm, edited 1 time in total.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

TMC wrote:I don't think it's rude to triple-post and that it's a misguided etiquette, it's much easier to see what's new than editing a previous post (in this case I forgot to check back).

Actually, your palette did teach me to use cross-ramp colours, and that's the way I used it. However I feel the benefit is much-reduced if you just use a soup of colours like I tend to, instead of picking out your own ramps and sticking to them.
That's encouraging to hear.
Personally I'm pretty adhoc about ramps too, but I believe that what allows me to do that is a strong understanding of color. It's well noted on Pixelation for example that new pixel artists routinely use oversaturated and monochrome ramps. So for me, the strongest case for predefined ramps is for those whom color is NOT easy to understand yet, but there is still a strong case to make that they improve visual consistency no matter how well you know color.

Also for palette swapping purposes. I don't think pal swaps are going to go away.
The CIE94 you mentioned is considerably simpler and more reasonable, so I think I'll use that. And thanks for the pointer to GIMP's LAB implementation.
No worries. GPick also has some good color conversion code (LAB, LCH, CIE94 Delta-E, etc) that's generally pretty clear.
I also added an implementation of Floyd-Steinberg dithering (not finished and merged into SVN) and wanted to try using something better than RGB distances in the FS dithering.
Good luck, it's a notoriously difficult problem to pick good dither colors programmatically.
BTW if there's anything at all relating to dithering you're vague about, http://caca.zoy.org/study/part2.html is a FANTASTIC resource. It really goes into depth with all the different variations of algorithms and their effects, and even includes full code. One thing I spotted there is the 'void-and-cluster' method of generating ordered dither matrices, which is an option you might want to consider if you ever want to dither animated images -- it's superior to classic Bayer matrices while still being an ordered dither (so it doesn't have FS's jumpiness issues with animated images)
See here for details & examples. There are surprising differences between GIMPs implementation and mine, which I suspect are due to 1) GIMP probably doesn't use RGB distances, 2) the OHR default palette sparsely/doesn't cover a lot of the colour space, which changes how such an algorithm should be tuned. But neither of the two give acceptable results.
GIMP's algorithm is basically a median cut in LAB colorspace. You can compare median cuts in different colorspaces fairly easily using ImageMagick or GMIC; IMO LAB is generally the most reliable performer, with Linear RGB also a decent performer.
Regarding forcing an injective mapping, that could indeed give very bad results if the input uses a large number of colours. Violations of injectivity ought to be allowed, by applying penalties instead of strict constraints, ideally in addition to using better than greedy selection.
Don't remember if I mentioned it, but generating a bunch of possible fits and choosing the one that minimizes global error would definitely be a good improvement.
That sphere-packed palette is interesting, it does sound a lot better than Web216.
My tests so far (884 vs 666 vs CC256) bear out the webpage's somewhat wild-sounding claim that it's almost as good as a 512-color palette in terms of effective depth; it really does blow away the other generic palettes, getting about double the perceptual closeness to the original image.

(testing was done using ImageMagick's and GIMP's quantization (but mainly IM))

I should probably try some tests that are in -colorspace lab or -colorspace rgb
(not to be confused with -colorspace srgb, which is what images generally have when loaded), for maximum accuracy, though, maybe also with GMIC.

And as I said, the poor coverage of the current default palette is readily apparent in the huge errors when remapping to it.
Since I spent a fair bit of time tweaking and testing it to minimize color error, that's pretty odd. For very saturated colors I wouldn't be surprised though.

(If I recall correctly, I felt at the time that OHR's current default palette was promoting an epidemic of oversaturated everything, so I was definitely biased -- even though I still think that now when I look at those Vikings examples for your algorithm)
The use of the GPL is very dubious though. Can you copyright a palette? I've never heard of anyone claiming ownship over such a thing. But if you can, then a GPL palette certainly can't be used as the default OHR palette.
Oh? My memory must be incorrect, I thought OHR was under GPL.
Personally I don't think you can copyright a palette.
Having a single default or common palette does have a large advantage that it removes all problems with remapping when importing. There are now sets of free graphics available, like Vikings, which almost require using the original master palette. Solving this longterm by moving to 24 bit graphics is still the plan.
I'm not really in favor of chucking graphics with conflicting palettes in a game. But I have no doubt people will do it.

This is one big thing that having a master palette does get you IMO -- some of the way towards having color choices that are not totally disjointed (whether through your own lack of knowledge of color or just plain apathy).

EDIT: Somewhat improved ordering of colorsphere palette:
Image
Last edited by 0ion9 on Fri Oct 09, 2015 1:28 pm, edited 4 times in total.
User avatar
Bob the Hamster
Lord of the Slimes
Posts: 7658
Joined: Tue Oct 16, 2007 2:34 pm
Location: Hamster Republic (Ontario Enclave)
Contact:

Post by Bob the Hamster »

The OHRRPGCE engine is GPL, but the data files can be any licence. Anything included into a .rpg file by default has to be public domain or similar
Last edited by Bob the Hamster on Fri Oct 09, 2015 12:13 pm, edited 1 time in total.
0ion9
Red Slime
Posts: 40
Joined: Sun Aug 02, 2009 7:45 am

Post by 0ion9 »

Oh, of course (BTW, CC0 > public domain. same intent, more legally clear)
Anyway if this palette turns out to be of interest I would think the author is probably pretty amenable to relicensing it. Which is certainly not required (copyrighting palettes may be a nonsense, and licensing them under a code license such as GPL is almost certainly nonsense), but would be polite if possible.

EDIT:
Second update of sorted version of colorsphere palette. Image
Is looking decent IMO, large blue ramp is main thing that still needs sorting out.
Last edited by 0ion9 on Fri Oct 09, 2015 1:58 pm, edited 1 time in total.
Post Reply