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.
ok, we're well into the jam now and I am trying to break my 'secret squirrel' habits, so here's a little taste of what I've got cooking for this summer's jam.
It's an all new Wonder Kids adventure, this one mixes proper spelling with Mr Do and Dig Dug to create a fun filled edutainment package for the whole family!
@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?
Ok, color me convinced!
I've added a very simple command line mode to PixelPaletteTool.
The command line mode is limited to performing a single palette swap using a swap set file previously created and saved via the PixelPaletteTool GUI.
But if you are at all handy with make or shell scripting it shouldn't be a big deal to get it to work on an entire directory or more of files.
The general idea of the work flow would be to use the GUI to create a color swap set, save it and then use the command line tool to apply the swap set to multiple files.
Here's the usage statement for it:
usage: PixelPaletteTool.exe -i infile -o outfile -s swap_file
notes:
swap file should be a color swap file previously constructed in PixelPaletteTool GUI.
Running with no arguments will launch PixelPaletteTool GUI
BTW
PixelPaletteTool saves three types of files:
Images (png, etc)
'Color Swap Set' Files
'PixelPaletteTool Project' Files
You want the 'Color Swap Set' files, the buttons just to the left of the 'View' and zoom buttons. These files contain just the info for matching and replacing colors.
Project files contain the full details of your current session (image file, palette, all color swaps (maps)).
TBH, if you save a swap set and load it up in any text editor, the format should be pretty human readable and even editable if you are feeling ambitious.
If there are other operations that might be useful from the command line, let me know!
awesome work!
I replied a bunch on the other palette tool thread, but here I'll add that all those blow hard swaps are really impressive, definitely show off the versatility of your program and surt's art! :)
ok, just to keep rambling here while I'm on a tear...
The main fill color for the slime highlights the challenge I was talking about earlier with using one mapping for an image with multiple different characters on it.
My CLIE algo seems to have made an odd choice for this color, opting for a slightly darker green instead of the yellow or the bright green in DB32 either of which would seem like better fits for a slime. But if you play around with the mapping a bit, you'll see that that color is actually used in a few other places around the image. Specifically, it's used for a highlight in the hair and scalp on the other characters. In those cases, choosing a green would be very odd and even the bright yellow is kind of problematic. Personally, I found the bright flesh tone (#EEC93A) to work best for the hair highlight and either the yellow or the off white (#CBDBFC) to work best for the scalp. So again, this just highlights the limits of trying to use one mapping for multiple different sprites or images.
here's a preview image of Pixel Palette Tool v1.6 showing the mapping my CIE distance maths chose for mapping Tiny16 Basic to DB32.
also:
@William.Thompsonj: One more comment for you, the preview images should be displayed with any texture filtering turned off. They look to be bilinear filtered on my display. Assuming we're dealing with mainly pixel art, 'nearest' or no filtering is what you want.
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.
ok, we're well into the jam now and I am trying to break my 'secret squirrel' habits, so here's a little taste of what I've got cooking for this summer's jam.
It's an all new Wonder Kids adventure, this one mixes proper spelling with Mr Do and Dig Dug to create a fun filled edutainment package for the whole family!
How's everyone else fairing?
@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.
Congrats to FabinhoSC this month's winner!
Thanks for participating!
@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?
@all:
Ok, color me convinced!
I've added a very simple command line mode to PixelPaletteTool.
The command line mode is limited to performing a single palette swap using a swap set file previously created and saved via the PixelPaletteTool GUI.
But if you are at all handy with make or shell scripting it shouldn't be a big deal to get it to work on an entire directory or more of files.
The general idea of the work flow would be to use the GUI to create a color swap set, save it and then use the command line tool to apply the swap set to multiple files.
Here's the usage statement for it:
usage: PixelPaletteTool.exe -i infile -o outfile -s swap_file
notes:
swap file should be a color swap file previously constructed in PixelPaletteTool GUI.
Running with no arguments will launch PixelPaletteTool GUI
The url to get it is still:
https://withthelove.itch.io/pixelpalettetool
BTW
PixelPaletteTool saves three types of files:
Images (png, etc)
'Color Swap Set' Files
'PixelPaletteTool Project' Files
You want the 'Color Swap Set' files, the buttons just to the left of the 'View' and zoom buttons. These files contain just the info for matching and replacing colors.
Project files contain the full details of your current session (image file, palette, all color swaps (maps)).
TBH, if you save a swap set and load it up in any text editor, the format should be pretty human readable and even editable if you are feeling ambitious.
If there are other operations that might be useful from the command line, let me know!
awesome work!
I replied a bunch on the other palette tool thread, but here I'll add that all those blow hard swaps are really impressive, definitely show off the versatility of your program and surt's art! :)
ok, just to keep rambling here while I'm on a tear...
The main fill color for the slime highlights the challenge I was talking about earlier with using one mapping for an image with multiple different characters on it.
My CLIE algo seems to have made an odd choice for this color, opting for a slightly darker green instead of the yellow or the bright green in DB32 either of which would seem like better fits for a slime. But if you play around with the mapping a bit, you'll see that that color is actually used in a few other places around the image. Specifically, it's used for a highlight in the hair and scalp on the other characters. In those cases, choosing a green would be very odd and even the bright yellow is kind of problematic. Personally, I found the bright flesh tone (#EEC93A) to work best for the hair highlight and either the yellow or the off white (#CBDBFC) to work best for the scalp. So again, this just highlights the limits of trying to use one mapping for multiple different sprites or images.
here's a preview image of Pixel Palette Tool v1.6 showing the mapping my CIE distance maths chose for mapping Tiny16 Basic to DB32.
also:
@William.Thompsonj: One more comment for you, the preview images should be displayed with any texture filtering turned off. They look to be bilinear filtered on my display. Assuming we're dealing with mainly pixel art, 'nearest' or no filtering is what you want.
ok, you know I couldn't stay out of this fun, so Pixel Palette Tool officially has an auto-map button now too!
https://withthelove.itch.io/pixelpalettetool
it only maps the colors that aren't already mapped. Not sure if that's how it should work or not, but that seemed the best route at first thought...
it uses CIE color distance, does seem to make some odd choices at times, so perhaps my CIE maths are the ones that are incorrect...
Pages