Palette talk
Moderators: Bob the Hamster, marionline, SDHawk
- sheamkennedy
- Liquid Metal Slime
- Posts: 1110
- Joined: Mon Sep 16, 2013 9:29 pm
- Location: Tama-shi, Tokyo, Japan
- Contact:
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
â� C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Then you'll love this.sheamkennedy wrote:That PalEdit thing is great! Saves me a lot of trouble creating a nice set of desaturated palettes for my game. Thanks!
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.
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)
- hueshift.png (4.76 KiB) Viewed 7541 times
-
- Palette (importable BMP)
- hueshift.bmp (822 Bytes) Viewed 7542 times
Last edited by Mogri on Wed May 20, 2015 5:32 pm, edited 1 time in total.
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"?
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"?
- Pepsi Ranger
- Liquid Metal Slime
- Posts: 1457
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
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?
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
- BMR
- Metal King Slime
- Posts: 3310
- Joined: Mon Feb 27, 2012 2:46 pm
- Location: The Philippines
- Contact:
This is the palette I use now:
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.
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
Using Editor version wip 20170527 gfx_sdl+fb music_sdl
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.
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.
- Pepsi Ranger
- Liquid Metal Slime
- Posts: 1457
- Joined: Thu Nov 22, 2007 6:25 am
- Location: South Florida
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.
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
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.
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.
(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:
Large version:
Nowhere near optimal sorting , but hopefully shows some different rampings you hadn't considered.
I also found this:
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:
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":
And quickly sorted:
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)
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:
Large version:
Nowhere near optimal sorting , but hopefully shows some different rampings you hadn't considered.
I also found this:
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:
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.CHGPAL doesn't consider degrees of color needed for lighting or shading
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":
And quickly sorted:
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.
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.
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.
That's encouraging to hear.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.
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.
No worries. GPick also has some good color conversion code (LAB, LCH, CIE94 Delta-E, etc) that's generally pretty clear.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.
Good luck, it's a notoriously difficult problem to pick good dither colors programmatically.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.
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)
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.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.
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.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.
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.That sphere-packed palette is interesting, it does sound a lot better than Web216.
(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.
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.And as I said, the poor coverage of the current default palette is readily apparent in the huge errors when remapping to it.
(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)
Oh? My memory must be incorrect, I thought OHR was under GPL.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.
Personally I don't think you can copyright a palette.
I'm not really in favor of chucking graphics with conflicting palettes in a game. But I have no doubt people will do it.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.
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:
Last edited by 0ion9 on Fri Oct 09, 2015 1:28 pm, edited 4 times in total.
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
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.
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.
Is looking decent IMO, large blue ramp is main thing that still needs sorting out.
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.
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.