1. Graphics types
    1. graphic
    2. color
    3. pixel

Graphics types

Refers to types that manage 2D images.

Graphics types must implement the following keys:

Transformations must work like this:

When dealing with images one must pay special attention to color support of the target formats. Notably color depth, if alpha is allowed, and palette (both space and available colors). If an image is imported that contains more colors than the depth allows or that contains colors than the palette does not have, Delta-E calculations should be used to find the nearest neighbors and a single warning per image file should be printed (note that multiple structs may point to one image file). If the import is allowed to fill a palette on its own, it may be limited to a certain length, in which case it should degrade the image as little as possible to achieve the desired palette size.


This is the generic struct for describing graphics data. It should be able to handle most graphical formats on its own but of course a library implementation for common formats is much faster (in terms of processing speed) and easier to read and write.

graphic must implement the following additional keys:


This is a value type that represents a color. It should be able to at least support 24-bit color plus alpha.

color must implement the following keys:

When defined/set, it must accept either a number of the form $aaRRBBGG (where aa is most solid at 0, see pixel), a list of the form [red, blue, green, alpha] (alpha is optional (default: 100%), in this case it is most transparent at 0), or a case insensitive string referencing a predefined color.

Colors that must be supported:

Note that these are meant to be percentages of the depth.

When retrieved as a list, it should return the [red, blue, green, alpha] form even if alpha was not originally set.

It should not be retrievable as a number.

When stringified, if there is a predefined color name for it, it should use it. If the depth is 256, it should write the number form. Otherwise, it should write the list form.

This should ideally keep track of the highest resolution of the color that it knows. For instance, if an image is imported as 24-bit color but changed to 16-bit color, it should keep track of the 24-bit color values (until written to) and only scale down as the return value for retrievals. It could possibly do this by storing percentages.


Represents a pixel format, that is, how to unserialize a binary value into a color and back again.

pixel must implement the following keys:

When defined/set, takes a string of the following format:

Example to explain chunking and ordering:

Given the following format and data:
format: 2bRRBBGG
binary: 0110 1000 0111
forward/forward ordering:
red: 0110, blue: 1000, green: 0111
reverse/reverse ordering:
red: 0110, blue: 0001, green: 1110
reverse bits/forward chunks:
red: 1001, blue: 0100, green: 1011
forward bits/reverse chunks:
red: 1001, blue: 0010, green: 1101

Retrieval is undefined.