X-Face

Latest revision as of 21:24, 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 is fairly complex (especially when extended), and uses a form of arithmetic coding as its compression method (which is part of the aforementioned complexity because it is implemented curiously, but it works, though it could benefit from better efficiency given how more-complex extended types perform in terms of size, but at least the Base94 is good).

[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 MONO for 1-bit BW, and RGB or GRAY for color and grayscale, the latter with a depth=N field with a value from 1-to-8 and these do not have to be in this order, and only the flags you need can be used) 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.

X-Face's code has an off-by-one quirk in it, and additionally, a solid black image compresses with different efficacy than a solid white image. The pieces of a grayscale X-Face are inverted compared to the 1-bit type, due to quirks in compface. Also of note is that extended X-Face headers that don't do anything too wild can display on weaker decoders. For example, grayscale X-Face's first header can display like a regular X-Face but all white is now black and all black is now white. Multi X-Faces that keep simple can end up with their first 48x48 cell displayed. Animated X-Faces kept simple will show their first frame. 48x48 beyond-3bpp Datula X-Faces display in X-Face-el recognizable but with wrong colors. Datula-favoring grayscale content displayed on X-Face-el can also mirror other weaker decoder rendering. Also, X-Face-el and Datula both allow toggling different extensions. Additionally, certain scattered patterns can compress badly. And as predictive as the Arithmetic coding is, X-Face IS lossless (as is Face due to PNG use), and it doesn't try to favor face-like shapes, which is an added bonus for the extensions because if either limit existed, extensions may have failed.

On a historical note, X-Face in its un-extended form harked back to Plan9's 48x48 sender icons, as well as Picons and Ikons, but it actually pre-dates a few formats. Compface's code's earliest date is "Written 11th November, 1989", but has a copyright date of June 1990, and it must be said that extended X-Faces above a certain size were considered a potential nuisance due to them bogging down slow connections, something that Japanese extended X-Face software made very clear in its Readmes, especially due to Internet prices then. So a one-of-every-extension X-Face header, in spite of its compatibility, would have been an even bigger nuisance. Also, some of these extensions were better supported than others, and the way in which they rendered differed. X-Face-el puts all the headers next to each other, Datula and X-FaceTool004 display them in a lightbox inside a balloon sized to a size that fits the largest multi headers it sees. Some X-Face programs could tint a grayscale or monochrome X-Face arbitrarily, to the text color, or to the theme color of the client. So there was a varied array of ways an X-Face could display, even un-extended. And based on X-Face-el and Datula testing, one-of-everything X-Faces work fine. X-Face-el in theory COULD be made to support Face headers and Datula's extensions to X-Face-el, even FPS, if edited.

Also, a decent chunk of X-Face software has certain quirks in it beyond those of the format. FFmpeg-generated .xface files have 0x00 in them, and, in general, the way junk is handled is varied. Also, X-Face headers pre-date stuff like GNU Privacy Guard and other e-mail encryption software, which can get confused upon seeing X-Face and Face headers. Also, the odds of a given e-mail system stripping X-Face and Face headers is not zero, so sending them may or may not work, and depending on various factors, there's a non-zero chance of an e-mail spam and/or virus filter like one would see in an organization being confused by X-Face and Face headers. Also, some servers can send or otherwise deal with larger X-Face headers than others. Also, because e-mail software can support custom headers AND HTML e-mail simultaneously if good enough, X-Face and Face headers can still be useful to identify senders, particularly if the recipients of an e-mail block external resources (X-Face and Face are inside the message headers of an e-mail) to prevent malware. The ability for multiple X-Face headers to coexist, at least in Datula and X-Face-el, allows joint-written e-mails to have avatars for each writer. X-Face-el and parts of Saku works X-Face software can even decode them inline if they are found in running text. These, among other uses, are ones that X-Image-URL and Gravatar e-mail avatars simply can't offer, and they have the ability to be of great utility to users.

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
  • Faces Archive - Archived page
• faces man page
• Wikipedia: X-Face