X PixMap

Template:Short description Template:Infobox file format X PixMap (XPM) is an image file format used by the X Window System, created in 1989 by Daniel Dardailler and Colas Nahaboo working at Bull Research Center at Sophia Antipolis, France, and later enhanced by Arnaud Le Hors.<ref name="xpm1">Template:Cite book</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

It is intended primarily for creating icon pixmaps, and supports transparent pixels. Derived from the earlier XBM syntax, it is a plain text file in the XPM2 format or of a C programming language syntax, which can be included in a C program file.<ref name="xpm1" />

HistoryEdit

XPM1Edit

The first (1989) XPM format is relatively similar to the XBM format.Template:Efn Compared to XBM, it uses additional macro definitions and variables for indexed colors, and replaces bits with characters for describing the image. The following is a black-and-white image in the 1989 XPM format.

define XFACE_format 1
define XFACE_width 48
define XFACE_height 48
define XFACE_ncolors 2
define XFACE_chars_per_pixel 1

static char *XFACE_colors[] = { "a", "#ffffff", "b", "#000000" }; static char *XFACE_pixels[] = { "abaabaababaaabaabababaabaabaababaabaaababaabaaab", // and so on for 48 rows with 48 pixels </syntaxhighlight>

XPM2Edit

XPM2 (1990) simplifies the format by removing all C code.Template:Efn Template:Efn The structure is simplified to

! XPM2
<Values>
<Colors>
<Pixels>
<Optional Extensions>

The value section describes the overall dimension of the image similar to the #define statements.
The color section defines the values, and a new concept of the "type" of the color. The types may be c for "color", m for "monochrome" output, g for "grayscale", and s for "symbolic", explaining what a defined color is supposed to do.
The pixels and optional extensions remain as in the original format.

The above file, with width 48, height 4, 2 colors, and 1 character per pixel, becomes:

! XPM2
48 4 2 1
a c #FFFFFF
b c #000000
abaabaababaaabaabababaabaabaababaabaaababaabaaab
abaabaababaaabaabababaabaabaababaabaaababaabaaab
abaabaababaaabaabababaabaabaababaabaaababaabaaab
abaabaababaaabaabababaabaabaababaabaaababaabaaab

ColorsEdit

In addition to hexcodes, the colors can be any of the X11 color names. In addition, None indicates transparency.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>Template:Cite book</ref>

The "symbolic" feature permits adjusting colors depending on the context where they are used. Code such as s border c blue could be adjusted on a blue background.

Many-color encodingEdit

One tool is known to use only a to p for 16 colors, switching to aa up to dp for 64 colors, but still reading single character encodings for 64 colors; compare Base64.

With more colors the codes use more characters, e.g. aa up to pp for 16 × 16 = 256 colors. This is less useful for text editors, because a string ab could be actually the middle of two adjacent pixels dabc. Spaces are allowed as color code, but might be a bad idea depending on the used text editor. Without control codes, backslash, and quote (needed in XPM1 and XPM3) 128 − 33 − 2 = 93 ASCII characters are available for single character color codes.

Simplified example: 90 US-ASCII characters could be arranged into nine non-overlapping sets of 10 characters. Thus unambiguous strings of nine characters could set the color of each pixel by its XPM palette index with up to 10⁹ = Template:Val colors (compare to GIF, which supports only 256).

For XPM2 it is clear how many lines belong to the image – two header lines, the second header line announcing the number of color codes (2 lines in the example above) and rows (height 4 in the example above), e.g. 2 + 2 + 4 = 8 lines.

XPM3Edit

The current and last format is XPM3 (1991). It re-introduces the C wrapper, but instead of explicitly showing a file's structure, the strings stored are essentially identical to XPM2.

<syntaxhighlight lang="C"> /* XPM */ static char * XFACE[] = { "48 4 2 1", "a c #ffffff", "b c #000000", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab", "abaabaababaaabaabababaabaabaababaabaaababaabaaab" }; </syntaxhighlight>

If the "values" line contains six instead of four numbers, the additional values indicate the coordinates of a "hotspot", where 0 0 is the upper left corner of a box containing the icon and the default. A "hotspot" is used for mouse pointers and similar applications.

Comparison with other formatsEdit

File:Blarg.xbm.png

Blarg file opened in program window

The following code displays the same blarg file in the XBM, XPM and PBM formats.

XBM version:

define test_width 16
define test_height 7

static char test_bits[] = { 0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55, 0xa5, 0x93, 0xc5, 0x00, 0x80, 0x00, 0x60 }; </syntaxhighlight>

File:Blarg.xpm.png

Blarg.xpm (XPM2) rendered by XnView

XPM2 version:

! XPM2
16 7 2 1
* c #000000
. c #ffffff
**..*...........
*.*.*...........
**..*..**.**..**
*.*.*.*.*.*..*.*
**..*..**.*...**
...............*
.............**.

XPM3 version:

<syntaxhighlight lang="C"> /* XPM */ static char * blarg_xpm[] = { "16 7 2 1", "* c #000000", ". c #ffffff", "**..*...........", "*.*.*...........", "**..*..**.**..**", "*.*.*.*.*.*..*.*", "**..*..**.*...**", "...............*", ".............**." }; </syntaxhighlight>

PBM file:

P1
16 7
1 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0
1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0
1 1 0 0 1 0 0 1 1 0 1 1 0 0 1 1
1 0 1 0 1 0 1 0 1 0 1 0 0 1 0 1
1 1 0 0 1 0 0 1 1 0 1 0 0 0 1 1
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0

Application supportEdit

ACDSee, Amaya, CorelDRAW, GIMP, ImageMagick, IrfanView (formats plugin), PaintShop Pro, PMView, Photoshop (plugins), and XnView among others support XPM.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> Gravatar also supports XPM.<ref>Gravatar unofficial, no XPM2</ref><ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

An X11 libXpm vulnerability was fixed in 2005,<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref> and three more in 2023.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>

FFmpeg version 3.3 or later can decode XPM.<ref>{{#invoke:citation/CS1|citation |CitationClass=web }}</ref>