@Spring: It's not SMS, it's SMSHD! ;)

I am pretty old school and simple minded so just good old fashioned RGB works best for me. I also generally work with retro palettes (NES, SMS, etc) and that is how you'll typically find these palettes expressed so that helps too.

I like to store my palettes as a PNG file with square swatches for each color. There doesn't seem to be much a 'standard' palette format anyways so I find putting the colors on a grid in an image file the easiest and most portable approach.

I use the Gimp and my general work flow is to have the palette image open in one window and whatever I'm drawing open in another. Then I just use the color picker tool to manually grab colors from the palette as I need them. It's kind of a bizarre approximation of using a color selection bar in a palette based editor like GrafX or Deluxe Paint, but it works for me.

As far as writing colors out, I do find HEX representation easiest to deal with, just because you can encapsulate the whole color in one string. And over the years, I've gotten so I can read HEX pretty easily.

@William.Thompsonj: Yay! The manual swapping interface definitely gets the job done.

Some thoughts:

1) The manual swap interface pops up over and partially obscures the image. This can make it tough to see the impact of your color selections. For example, what if the color you are swapping is mainly used in the obscured portion of the image?
Consider moving and/or resizing the interface so it doesn't obscure the image so much. For example, it could be made simultaneously wider and shorter and moved down. Or it could be made a free-floating window so users could move it about as needed.

2) Having to click 'apply' every time you change a swap color is cumbersome. I suggest just having the swap take effect immediately but maybe have an 'undo' button (something PPT lacks) so you can easily roll back a change you don't like.

3) The load/save icons seem out of order to me. I would group them either by function (load/save) or by target (image/palette). As it is, the first icon is to load an image, the second is to save a palette, which is confusing to me.

4) 'Add Color' is an awesome feature and one that's still missing from PPT. :)

Feature requests:

Some way displays all the current color swaps. Actually having the swaps permanently displayed somewhere would be best. I find it helpful for a lot of reasons, not least of which is checking to see if I've already used a particular color in another swap.

Some way to manually sort the colors in the manual palette swap interface. This is big help when working with color ranges.

Some way to zoom/pan around the image. Sometimes a color is only used in a small part of the image (ex. a color used for shadows in a single sprite on a larger sprite sheet) so it's nice to be able to zoom in and look at the specific area you are working on.

Some way to load/save not the image or the palette but the swap data (eg. aa55ff -> cc77ee, etc.). This would allow one to apply the same swaps to multiple images and also be handy for saving your current state and returning to later.

@all:
Have released PixelPaletteTool v1.70.
This version adds a command for auto mapping colors to the command line and switches the auto color mapping algorithm from CIE76 to CIE2000.

Many, many thanks to William.Thomsonj for sharing me the code for CIE2000 color distance calculation.

@William.Thompsonj + all:

Since you bring up mapping a color (background color) to alpha 0, I do have another tool I've written that does this and a few other tricks. It's strictly a command line program and (so far) just something I wrote for myself to use internally but if it was useful for others I'd be happy to share it.

Here's the help statement for it:

PixelTool v3.4
usage: pixeltool -i infile -o outfile [command ...]
commands:
-c2a red green blue = set alpha 0 on matching pixels, alpha 255 for others
-outline = add black outline around alpha 255 pixels
-thick_outline = add black outline around alpha 255 pixels (thicker)
-edge = set color of alpha 0 pixels to avg of surrounding alpha != 0 pixels
-regrid w h new_w new_h = respaces image (useful for grid of sprites)
-split w h = split image, 1 new image per grid square, image files named outfile1x1, outfile1x2, outfile2x1, etc.
-skip_empty = skip (don't save) empty images when splitting an image
-fill_color red gree blue alpha = specify color used to replace c2a pixels with and/or fill regrid image with before copying grid pixels
-dim width height = specify width, height of output image
-depth 24|32 = specify bit depth for output image
-palettize = output image is pallete of unique colors found in image (or all images in dir, if given a dir)

The difference between regular (thin) outlines and thick outlines is that thick outline checks /diagonally/ adjacent pixels instead of just up, down, left, right pixels.

The purpose of edge is to get the edges of a sprite/image to blur correctly when using bi-linear (or other) filtering. Classic hardware bilinear filtering just blends all adjacent colors independent of their alpha values. So color from the invisible pixels around your sprite will get bleed into the edges of your sprite if it is scaled or rotated. The '-edge' routine solves this problem by filling transparent pixels with color values from nearby visible pixels. This way the transparent pixels around the edge of a sprite are the same color as the edge of the sprite.

Does this stuff sound useful to anyone out there?
If there is interest, would folks rather see this released as it's own tool or should I just pack these functions into PixelPaletteTool's existing command line interface?