Palette Cleanup

This is WIP, should not be linked to yet.

Purpose

Unit sprites are supposed to be pixel art, but sometimes this breaks down. Maybe someone accidentally edited an image with an anti-aliasing tool (e.g. cut-paste lasso, paintbrush) or maybe the original contribution just had too many similar colors. Starting in 1.17, an effort was made to enforce a set palette: https://github.com/wesnoth/wesnoth/issues/6417

This page does not address image metadata, that is covered elsewhere.^*

Background

Why do sprites need to be pixel art?

The game works just fine with non-pixel art images^*, but there are some reasons for the pixel art sprite convention:

• Simplifies color swapping - having a set palette makes it simpler to map the original colors to new colors. The most obvious example of this is the team coloring magenta/pink conversion to red for player 1.
• Distinction from terrain/scenery - The terrain and scenery images are not pixel art. With the current conventions, the sprites or "game pieces" should have a clear distinction from the background or "game board"
• Stylistic decision - pixel art is an art form, not simply a limitation, even if it may have had its origins in graphics limitations of the 1970s and earlier.

Enforcing a palette means restricting colors... Don't cramp my artistic expression!

It might sound restrictive, but no one said the palette needed to be 8-bit. If you need to add a color to the palette, that is fine, just do it deliberately (see below).

Palette Cleanup (with an Example)

Consider these two images:

The one on the left has 72 colors, the one on the right has 41. Notice the difference? If the palette was chosen correctly, the changes should not noticeably alter the image. Even 41 colors is probably more than is really needed. A bash script to produce the output was:

#!/bin/bash  
mkdir output
mkdir reports
for f in *.png
  do
    magick $f -dither None -remap HumanLoyalist_ColorMap.png -strip output/$f
    # comment these out if you don't need to manually check the results
    convert output/$f -define histogram:unique-colors=true -format %c -write histogram:info:reports/info-histo_output_$f.txt
    convert $f -define histogram:unique-colors=true -format %c -write histogram:info:reports/info-histo_input_$f.txt
done
rm output/*ColorMap.png
echo Finished!

The ColorMap image

is included in mainline unit image directories, but you could use your own if the image is not intended for mainline contribution. With the ImageMagick bash script shown above, the ColorMap needs three things:

1. the colors needed for the palette
2. at least one fully transparent pixel
3. at least one 60% opacity shadow pixel (srgba(23,0,53,0.6))^**

You'll see in the output reports that there are still colors with only 1-3 pixels, so this isn't optimized. But the palette is still fairly small and, most importantly, every color is tracked and the same across the animation frames, so simple color-swapping is now (reliably) possible and broken team coloring is less likely. The restrictions on the alpha channel, where only the shadow can be semitransparent, help to clean up any almost invisible cruft floating around the sprite.

If you do intend to contribute a sprite image to mainline, and the relevant ColorMap image does not have the colors you need, simply add the needed colors as squares to the ColorMap. The image can be as large as it needs to be, so add another column or row if needed (be sure to leave at least one empty square).

---

---

Notes

^*CI currently enforces attribution and copyright, it doesn't enforce color palettes, that is still a manual process. Neither of these things are required for UMC, however the copyrights of UMC content do still matter if hosted on the add-ons server.

^**It looks like there has already been some slight drift since Creating_Shadows_Under_Units was written, which makes the palette restriction more relevant