Development:Image dyeing

Simple colors and palettes

A pixel has a simple color if it is not black and if its non-zero RGB components are all equal.

There are seven simple colors:

• Red
• Green
• Blue
• Cyan
• Magenta
• Yellow
• White (gray, that is)

For a given color, there are 255 different values of pixels (from components equal to 1 to components equal to 255). For gray pixels, this is actually their intensity.

All the pixels of a given color can be dyed with a particular palette. A palette is a sequence of RGB colors, e.g. 8c4b41,da9041,ffff41. Pixels of value 255 are transformed to color ffff41. Pixels of value 0 (unavailable) are left unchanged to black, that is 000000. Other colors are applied to equally-spaced pixel values between these extreme values, so 8c4b41 to value 85, and da9041 to value 170.

The color sequence can have from one color to 255 colors. For values with no explicit color, the associated color is linearly interpolated between the two closest value.

Pixels with complicated colors or without any dedicated palette are left unchanged by image recoloring. At most, the system allows to dye 1785 sets of pixels in an image independently.

Specifying palettes

Whenever an image (usually a png file) is specified in an xml file, a palette can be appended to its name. The image is then automatically dyed on loading. For example, if one changes an image resource from foo.png to foo.png|W:#ffff00, then all the gray pixels of test.png will be replaced by shades of yellow, proportionally to their intensity.

Several palettes (one per simple color) can be appended to an image. For example, green and red pixels are recolored independently for image foo.png|G:palette1;R:palette2.

Palettes can either be specified as the name of a file containing a palette (format not yet defined) or directly defined as a color sequence. A # symbol (often called pound, hash, or sharp) is prefixed to a color sequence, so that the system understands that this is a color, not another file.

Dyeing sprites

When indicating the dyeable colors in an image, some palettes can be left unspecified. For example, the resource name foo.png|G;R:palette1;Y means that green, red, and yellow, pixels of the image have to be dyed. But no palettes are specified for green and yellow pixels.

These palettes will be specified at a higher level. If the foo.png file is part of a sprite description named bar.xml. Then palette specifications can be appended to the file name, e.g. bar.xml|palette2;palette3. These additional palettes are then propagated to any image loaded by bar.xml with unspecified palettes. So the foo.png is finally recolored with the dye G:palette2;R:palette1;Y:palette3.

One-channel example

Here is a simple example taken from actual game data. The data/monsters.xml file contains the descriptions of all the monsters. For black scorpions, the definition begins with

   <monster id="1009" name="Black scorpion">
       <sprite>monster-scorpion.xml|#0d1313,435a5a,879999,ffffff</sprite>
       <sound event="hit">scorpion-hit1.ogg</sound>
       ...

The data/graphics/sprite/monster-scorpion.xml then describes the animation of any scorpion, whatever its color. It contains this line:

   <imageset name="base" src="graphics/sprites/monster-scorpion.png|W" width="48" height="45" />

The monster-scorpion.png file is a grayscale image, hence the W color specifier, so that all its pixels are blackened (or dyed to brown or red for other species of scorpions). If it contained some non-gray pixels, these would not be recolored by the palette specified in the monsters.xml file.

Multi-channel example

Here an example for multi-channel dyeing of an equipment sprite. This example recolors the grey sections of the image to green and the red sections to a greyblue.

items.xml:

<sprite>head-devcap.xml|#22ff22,ffffff;#9999ff</sprite>

head-devcap.xml:

<imageset name="base" src="graphics/sprites/head-devcap.png|W;R" width="28" height="19" />

Implementation remark

Palettes have to be specified as part of the image and sprite resource names, so that they can be properly cached. If they were not, there would be collisions: All the recolored sprites would have the same color, the first one to be put in the cache for a given sprite definition. Since they are part of the resource names, they may as well be part of the filenames written in .xml files.