X-Face

Latest revision as of 09:29, 26 September 2025

X-Face is a compressed image format that can be placed in an email or Usenet newsgroup message header. It is expected to contain the sender's picture or avatar. It is a 48×48 bi-level (apart from its extensions to support 1-to-8 bit grayscale, 3-to-24 bit color, bigger images, and animation) image. The format appears to be fairly complex, and probably uses arithmetic coding.

[edit] Discussion

Although X-Face data is often expected to be stored in a file, there isn't really a standard X-Face file format. The main thing to be aware of is that sometimes the "X-Face:" header name is stored in the file, and sometimes it is not (a behavior that can potentially break the format's improvement extensions). Different software has different requirements.

File extensions .face and .xface have both been suggested. Sometimes, X-Face data will be in a file named ".face" in the user's home directory.

It is a common theme amongst extended X-Face (X-Face-el and Datula's extensions of it) for the viewer code to support more than the generator code can write. X-Face-el due to it using sections of an XBM to composite the final result, where Red, Green, and Blue were stacked on top of each other, won't be able to encode taller-than-48px RGB X-Faces, especially animated ones, but the actual decode operation will happily decode taller RGB X-Faces, even animated, but they need manual coaxing (copy & paste to build up the header) to do it. FaceMake only takes BMP, but Datula's viewer will honor animated headers made via encoding each frame one-by-one with FaceMake, even though they were never officially generated. FaceMake will only ever generate up to 5x5 (240x240px), but there are no true hard limits to extended X-Face. In theory, if space isn't a factor, 24-bit color animations in any resolution that can be made from 48x48px cells with a frame rate as low as a textual decimal can go are supported. Datula will theoretically decode these but can't send.

Animation in X-Face-el has a lower bound frame rate of 10fps, but Datula lifts that limit. Datula's RGB mode can have unequal bit depths for each channel, because it, after all, takes 3 grayscale X-Faces and slots them into the channels of a color X-Face, exactly as X-Face-el does. Well, it DOES break if the first header in a grayscale or color component is changed to "X-Face-0" to mitigate legacy decoder issues, something that doesn't break on X-Face-el. X-Face-el's RGB+multi (beyond-48x48px)+animation code and grayscale code are separate sections in the relevant codebase, a missed opportunity for rich color ultimately seized by the later builds of FaceMake.

The limits on sending from Datula are due to it having a limit on how big of a custom header it will let you send. It has no problem in the situation of it reading a header that is too large to send. An outright video header could be sent, email server-permitting, and it in theory would display. X-Face-el so far works best on XEmacs, its original environment.

Another factor is that unequal channel depths in a TrueColor X-Face have been found to work even though the relevant X-Face-Type: header (which contains, separated by semicolons, geometry=NxN for multi, animate=N for animation, and RGB or GRAY for color and grayscale, the latter with a depth=N field with a value from 1-to-8 and these aren't the only flags, because X-Face-el can generate animated beyond-48x48px monochrome X-Faces too) only has one depth value. More-consistently is that because grayscale (and by extension Datula color components) features X-Face-1 through X-Face-7 headers, it is also at least plausible to change bit depth per frame too, even potentially in conjunction with this.

So in theory it is possible when converting color animations to optimize the headers for size as needed based on colors usage. So if a scene favors Red, Green, or Blue (or multiple), you can allocate the most-used relevant channel(s) more bits (assuming you are skipping out on full 24-bit to save space, and/or accounting for the human eye being more sensitive to green), and do this per-frame. And FaceMake allows one to set the bit depth of the color components to uncommon sizes not possible in PNG, and that's without the unequal component ones in which manual assembly is needed to utilize it, let alone the per-frame changes. There's really no limits here.

X-Face's extensions, X-Face-el, and the FaceMake+Datula extensions of it, were Japanese-made, and the email clients that supported them were often Japanese. Considering that the Face header used PNG and Base64 together, abandoning compface altogether, these extensions were to an extent uncommon enough for Face headers to take the approach they did, not being aware of the fact that a color X-Face had already been devised long before Face: headers in 2005. X-Face-el dates back to 1996, and the Datula extensions to 2002 in some sections. Nonetheless, it IS possible to make an X-Face header with ALL extensions coexist with a Face: header, & it has no ban on APNG.

Regarding the X-Face-Version header, it contains a string. X-Face-el will ONLY write this header, but will not read it. The X-Face-el codebase includes names of Beatles songs as its version number string (but numbered internally), the most current being "All Together Now (remix)", while FaceMake reports its version and OS in the X-Face-Version field. Other X-Face software puts different content in it.

Note that having 24 headers for a static 48x48 Datula RGB header adds up in size by the time one adds multi and animation, and FaceMake asks users if they are really sure that they want to go all the way to 24-bit multi because the header size starts to add up fast.

Getting ALL X-Face types (and Face) to coexist is nebulous as to whether or not it was ever done historically. Furthermore, another factor behind extended X-Faces is that adding them generally requires using an e-mail client allowing bulk input of custom headers. So software compatibility does involve this factor. It is also quite hard to find modern e-mail suites that work with (extended) X-Face.

Most or all X-Face code is based on James Ashton's Compface software, and Compface's code is fairly opaque (several programs would require compface itself to be installed or at least be a loaded library and/or plugin, even breaking cross-OS support for X-Face at times). A specification has been written by reverse-engineering Compface.

[edit] Compface intermediate format

The Compface software by default converts X-Face to and from the Ikon format. It only supports 48×48 images with a bit depth of 1. Most implementations use 16-bit words but one implementation[1] uses 8-bit words.

[edit] Software

• Compface
  • compface-1.4.tar.gz (uncompface -X to convert to XBM format)
  • compface-1.5.2.tar.gz
  • compface-25Jan90.tar.gz
  • X-Faces for Windows 95/NT
• FFmpeg
• Deark
• Online X-Face Converter
• x-face-el — extends the format, in a manner unsupported by other software, adding colour/greyscale pixels, animation, and larger image sizes
  • https://web.archive.org/web/20051029080636/http://www.jpl.org/elips/ - Additional Emacs Lisp scripts that handle X-Face, plus examples of extended X-Face.

• Datula - A Japanese e-mail client which supported plugins in versions such as 1.52.01.01, two of which involved extended X-Face.
  • Datula DFaceEX X-Face Plugin - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
  • XFacePlugin with FaceMake - Another viewer plugin by the same author (saku/Saku works) which includes a program called FaceMake which, on the latest version (Datula's is, but the version of FaceMake shipped in X-FaceTool004, a version for e-mail clients like EdMax and Eudora, among others, isn't) combines the X-Face-el extensions into a unified format of 24-bit RGB with animation (needs to be done frame-by-frame, but the decoder will happily decode it, at least where Datula is concerned) and beyond-48x48px. The 24-bit support in FaceMake doesn't exist in the build bundled with X-FaceTool004, unlike the FaceMake for Datula's X-Face plugin that it is bundled with. FaceMake is also picky, but it does support beyond-48x48px and animated grayscale images (assuming frame-by-frame assembly for animated) (or both), unlike X-Face-el.

Furthermore, if a 24bit 48x48px X-Face of any type is loaded in X-Face-el, it will have wrong colors, but anything larger is garbled.

[edit] Samples

• https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
• WinFace1_3-src.zip → WinFace/default_face.txt
• faces man page, "XFACE SUPPORT" section, has an example.

• https://stgiga.github.io/X-FacePlusFaceAll48pxHeaders.txt - Sample of regular X-Face, Face (Base64+PNG), & the 48x48 x-face-el extended X-Face types (8-bit grayscale & animated 3bpp RGB).
  • https://stgiga.github.io/X-FacePlusFaceAll48pxHeadersFix.txt - Sample of regular X-Face, Face (Base64+PNG), & the 48x48 x-face-el extended X-Face types (8-bit grayscale & animated 3bpp RGB, in a way that works on Datula).
• https://stgiga.github.io/QuadFace.gif - A GIFski GIF rendering of the above, assembled into a 96x96 square cell (useful if everything is 48x48) that modern UIs would prefer.

• https://stgiga.github.io/X-FacePlusFaceAllHeaders.txt - Sample of regular X-Face, Face (Base64+PNG), & the x-face-el extended X-Face types (8-bit grayscale & animated 3bpp RGB, including going beyond 48x48px).
  • https://stgiga.github.io/X-FacePlusFaceAllHeadersFix.txt - Sample of regular X-Face, Face (Base64+PNG), & the x-face-el extended X-Face types (8-bit grayscale & animated 3bpp RGB, including going beyond 48x48px, and in the way that works on Datula).
• https://stgiga.github.io/TallFace.gif - A GIFski GIF rendering of the above, assembled into a 96x144 cell that modern UIs would prefer over stringing them side-by-side like x-face-el does, or in a tiny gallery like Datula does.

• https://stgiga.github.io/X-FacePlusFaceAllHeadersPlus24bitFixOG.txt - Sample of regular X-Face, Face (Base64+PNG), & the x-face-el and Datula extended X-Face types (Datula's animated 24-bit RGB, plus x-face-el's 8-bit grayscale & animated 3bpp RGB, including going beyond 48x48px.)
• https://stgiga.github.io/LushFace.gif - A GIFski GIF rendering of the above, assembled into a 96x144 cell that modern UIs would prefer over stringing them side-by-side like x-face-el does, or in a tiny gallery like Datula does.

• https://web.archive.org/web/20051029080349/http://www.jpl.org/elips/image/x-faces.gif - Many samples of X-Face and X-Face-el (extended mode is known as X-Face-Xmas internally) from long ago.
  • https://web.archive.org/web/19980630075245/http://www.jpl.org/elips/image/x-faces.gif - Oldest (1998) archived version of the collage, featuring beyond-48x48px X-Face-el/X-Face-Xmas X-Faces from long ago in addition to the RGB ones, even mixing the two modes.

• dexvert samples — image/xface

[edit] Links

• Faces Archive - Lists some X-Face resources
  • [2] - Archived page
• faces man page
• Wikipedia: X-Face