Just Solve the File Format Problem - User contributions [en]

X-Face

2026-04-21T20:07:58Z

St. GIGA: fix accidental markdown

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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 two 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with VTF/[[Valve_Texture_Format]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
All of these "graceful" fallbacks apply when the headers are read from the first to the last. In the Pan newsreader and apps like it, the rare approach of using the last header in a sequence would mean that the blue channel, the final multi cell, and/or the final frame would be seen, essentially the inverse of the "conventional" way/ordering. So if making a fancy extended X-Face, ideally the first and last 48x48px 1bit header should be significant. Also of note is that if one is building a client that can view grayscale and 1bit and tint them, both the grayscale and the 1-bit headers should each have their own tint setting (this keeps certain image shades visible).

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no [[XML]]/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents ''can'' be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-15T22:18:50Z

St. GIGA: fix another typo

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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 two 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with VTF/[[Valve_Texture_Format]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
All of these "graceful" fallbacks apply when the headers are read from the first to the last. In the Pan newsreader and apps like it, the rare approach of using the last header in a sequence would mean that the blue channel, the final multi cell, and/or the final frame would be seen, essentially the inverse of the "conventional" way/ordering. So if making a fancy extended X-Face, ideally the first and last 48x48px 1bit header should be significant. Also of note is that if one is building a client that can view grayscale and 1bit and tint them, both the grayscale and the 1-bit headers should each have their own tint setting (this keeps certain image shades visible).

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no [[XML]]/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-15T22:17:29Z

St. GIGA: /* Discussion */

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with VTF/[[Valve_Texture_Format]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
All of these "graceful" fallbacks apply when the headers are read from the first to the last. In the Pan newsreader and apps like it, the rare approach of using the last header in a sequence would mean that the blue channel, the final multi cell, and/or the final frame would be seen, essentially the inverse of the "conventional" way/ordering. So if making a fancy extended X-Face, ideally the first and last 48x48px 1bit header should be significant. Also of note is that if one is building a client that can view grayscale and 1bit and tint them, both the grayscale and the 1-bit headers should each have their own tint setting (this keeps certain image shades visible).

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no [[XML]]/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-15T22:16:23Z

St. GIGA: fix typo

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
All of these "graceful" fallbacks apply when the headers are read from the first to the last. In the Pan newsreader and apps like it, the rare approach of using the last header in a sequence would mean that the blue channel, the final multi cell, and/or the final frame would be seen, essentially the inverse of the "conventional" way/ordering. So if making a fancy extended X-Face, ideally the first and last 48x48px 1bit header should be significant. Also of note is that if one is building a client that can view grayscale and 1bit and tint them, both the grayscale and the 1-bit headers should each have their own tint setting (this keeps certain image shades visible).

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no [[XML]]/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-14T21:34:22Z

St. GIGA: Add more info

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
All of these "graceful" fallbacks apply when the headers are read from the first to the last. In the Pan newsreader and apps like it, the rare approach of using the last header in a sequence would mean that the blue channel, the final multi cell, and/or the final frame would be seen, essentially the inverse of the "conventional" way/ordering. So if making a fancy extended X-Face, ideally the first and last 48x48px 1bit header should be significant. Also of note is that if one is building a client that can view grayscale and 1bit and tint them, both the grayscale and the 1-bit headers should each have their own tint setting (this keeps certain image shades visible).

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no {{XML}}/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-14T20:51:52Z

St. GIGA: fix formatting

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no {{XML}}/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-04-14T20:51:19Z

St. GIGA: Added more info

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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.

On the topic of quirks, the way in which legacy decoders handle a combo header differs. MOST apps not used to Japanese extensions will see the first X-Face: header, or if present a Face: header which it may prioritize. The Usenet reader Pan, however, in addition to it trying to pare down custom headers, if you can hoodwink it into loading a non-mangled (headers should be stored verbatim and in bulk, no {{XML}}/etc. al. or prefixes that make long headers painful) header, it will display the X-Face header at the very end of the file, a very rare phenomenon. At least the ALL-modes X-Face that has the 96x48 multi in the examples section has an ending X-Face that is the blue channel of the right half of the 96x48 header's last frame, and its context survives the cropping of that portion to 48x48 1bit. Most won't. To fix Pan without a bug report you should use an "X-Face-Type: MONO; geometry=1x1" plus a classic X-Face at the end. It IS a hack though, but one doesn't have to use a clone, but this CAN be bad for grid purposes, never mind that this is a shim for a minority of X-Face viewers that, if using X-Face embedded in something, could be a bit confusing to viewer code, even with the X-Face-Type and unique values, given that 3bit RGB Multi is at the end of the proper order, and it doesn't have the Datula header numbers. So confusion even then is possible, especially given how sensitive Datula X-Face headers are to gibberish. The idea of separation is why the Face header is where it is in the example and the reason why X-Face-Version is used. If there is improper separation, things REALLY go wrong so if one ends up clobbering the last frame+cell+channel via a superfluous/shim ending, it's going to do some damage. Also ideally you want a terminator header like the X-War: header made by some mailing list users whose contents are either "is not the answer" or "No, thank you." The X-Meow: header (whose contents *can* be "Wouf") COULD confuse the Mew e-mail client which DOES support X-Face and has its own X-Mew: headers. And having superfluous terminators is a bit risky (at minimum in Datula and its related BalloonFace). And using more than one Pan shim is also dubious. Note: This format is from the modem era so the odds of a skipover of an X-Face-Type: header near the end for a Pan shim is not impossible given the flakiness of those connections. And both Datula and the client (HidemaruMail) that supports header sending best, are modem-compatible. Mind you, having more than one of the same type of header CAN be sketchy and confusing/nebulous to shoddy decoders. So this whole codec is delicate. At least it IS possible to mix the types safely. It was never really done back in the format's heyday, but it DOES work, so long as it is done correctly. The results are quite amazing when it works.
Also the reference header uses CRLF so Windows, Unix-type OSes, and Classic Mac OS can all handle it if they receive it (and yes, Mac OS X and Mac OS 9 both had X-Face header support in e-mail software, and it was quite popular, but whether it supported extended X-Face is murky, but in theory X-Face-el could work if you hooked into the post-Mac OS 9 Emacs that comes with Mac OS X and macOS and did it in a way/mode where displaying images is possible.

One 2016 X-Face user on Reddit used Mac ports of Mozilla e-mail software for X-Face, but note that SeaMonkey and Thunderbird absolutely do not support the fancier headers, and unfortunately the extensions to Thunderbird and SeaMonkey that do display message headers are both also incompatible AND are not able to work with newer versions of the Mozilla e-mail programs due to changes in how extensions work, around/near the time of XUL deprecation, and need significant refactoring to work again.

In the case of Datula, it can read headers from the message body or signature, but it can be a bit wonky. Also, Datula's Usenet mode in conjunction with the 24bit headers plugin does not view headers gracefully, unlike with e-mail. It essentially tries to overlay ALL headers, including extensions, into a regular 1989 X-Face cell. So when Datula mode shows up in this article, it is referring to when you use Datula as an e-mail client, and NOT a Usenet client. Also finding usable Usenet clients has been quite unfortunate, and that's not even considering that the amount of conversation newsgroups is rare, and that Usenet in the modern area even in those servers is still a bad mess and sparse. As such, X-Face's intended environments (Email and Usenet as opposed to image viewers) are both VERY hard to come by, especially when one chooses to mix modes. Most of the users left over are more often than not Unix, Linux, BSDs, Hurd, or OpenDarwin users. The alt.linux newsgroup on eternal-september's (a Usenet server meant for talking, not file sharing) news server has the newest X-Face users but none use extensions. Then again one would most likely see those on a Japanese environment. Ultimately this format is SO rare that if someone has their own X-Face and can do anything with it, it's a good sight to behold. This format badly needs programs and software support to handle it and its extensions. Especially tying it into modern systems, given how Usenet as a social network and custom email headers are very nearly extinct as a result of unfortunate factors. As such X-Face headers are VERY elusive in the modern era and not something that crops up very often at all, but when it does, it's also likely not an extended type of 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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-03-25T22:13:35Z

St. GIGA: Revert space

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-03-25T22:12:49Z

St. GIGA: Cleaned up spacing

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-03-25T22:11:55Z

St. GIGA: Added more details after investigation

{{FormatInfo
|formattype=electronic
|subcat=Graphics
|extensions={{ext|face}}, {{ext|xface}}
|released=~1990
| spec = https://purl.org/x-face-spec
}}
'''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).

== 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, and superfluous fields like geometry=1x1 on a 48x48px X-Face are relatively safe) 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, which is quite helpful for usage.

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.
Essentially, under controlled conditions, you can do a limited form of how video codecs handle size reduction by exploiting that the human eye is more sensitive to changes in brightness than changes in color.

One thing that has been tested in Datula (but is still under investigation) is that changing the grayscale depth in a multi grayscale (albeit less investigated) or TrueColor X-Face is possible on each 48x48 cell. Such a feature is capable of improving compression. A lot of the special part of why Datula can do what it can do is that because of how the oldest grayscale X-Face code would create X-Face-1: through X-Face-7: headers AND that X-Face-el ALSO defined its grayscale as using a field in X-Face-Type:, it means that 24bit via taking grayscale headers and shoving them into each channel of an RGB X-Face is possible, AND that you can fiddle with the depth in each channel, frame, and 48x48 cell, though doing something like switching from TrueColor in one cell to 1-bit BW in the other cell requires filling that second cell with 3 copies of the 1-bit header. Also all of this is creepily similar to NTSC color. Also the inversion of the grayscale code is preserved and you can make 1-bit grayscale X-Face headers, so you could potentially do something with that if you're clever, and do it because of the difference in output size between solid black and solid white. But simply put, it IS possible to significantly optimize extended X-Face to not waste space, and in a way creepily similar to the NTSC-J inspiration AND modern video file codecs, though regrettably this historically was fairly niche. JPL's (NOT Jet Propulsion Laboratory) grid of X-Face images that has a few of the extended types only collected 3-bit color and multi X-Faces, but not grayscale, Datula RGB, animated X-Face, or X-Face code. Even though the file was a GIF. The archived 1998 version of the image DOES feature a very tall (tall multi is harder to generate than wide multi if you use RGB and this didn't) multi X-Face as well as an RGB multi X-Face that is 96x48 and has Japanese Kanji over color bars. So we know that SOME mixing of modes happened back in the day, and the fact that Yuuichi Teranishi made different expressions, as well as 2-bit grayscale, monochrome animation, and 3-bit RGB of his X-Face cartoon avatar implies that SOME people tried to go for an ALL modes header pool, but nobody seemed to have fully mixed the modes to the max historically, most likely due to the high usage of 56K and ISDN as slow as they are. But as long as you avoid throwing multi into a Datula X-Face you can do this safely. Sadly, no one tried.

Another factor to consider with regards to the extensions is that the grayscale X-Face headers go from most significant bits to least. As a result of Datula TrueColor mode shoving grayscale into an RGB X-Face's color components, this is inherited. Also, multi/larger size images are ordered specially depending on their dimensions. The way combined modes work is that first color or grayscale if present is involved, then the larger picture, and then the animation. This is why it is so easy to make Datula FaceMake do animation, because it is the last step so frame-by-frame assembly is possible. This is fortunate, though it would seem nobody considered doing this. If they DID do an outright video X-Face and actually managed to send one, this would be interesting, but from what evidence there is out there it is the case that extended X-Face was exceedingly rare. Now, in lieu of Datula, for people who wanted to send color images not within the 8 colors of 3-bit RGB, what they did was use dithering, which was also used by most of the monochrome users to send images that were not just on or off. The extended X-Face headers and Face were designed to allow more-recognizable images to be used. It's unfortunate that they were rarely used. That said, in 3-bit RGB mode it was the case that the dithered images worked enough to do even the Mona Lisa, but it DID get used for at least one face in JPL's file. Oh and Yuuichi Teranishi's drawn X-Face in all its modes was given a 24-bit version for his Twitter/X profile picture, which is 96x96, so it could be fed into Datula to finish the collection. But seeing as he was one of the developers of X-Face-el, him not knowing about a Windows extension of X-Face-el is likely, given that X-Face-el and Linux were tied.

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, along with its sibling program "select-xface" includes names of Beatles songs as part of its version number string (but numbered as well, and with select-xface resident in memory, both its version number + song name, of which the latest is "Live and Let Die" and X-Face-el's, of which the latest version's song is "All Together Now (remix)" are put in the field), 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, such as FaceMake puts different content in it. It should be treated as a string, given how many programs populate it with non-numeric contents.

Note that having 24 headers for a static 48x48 Datula RGB header bloats 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.

Oh and another factor is that in theory you COULD do HDR and image sizes beyond what some formats support. If you, say, did X-Face-0 and X-Face-8 through X-Face-9, you could go beyond 10bpc HDR, and maybe hit 12bpc. Though you could go higher. Also a construct like X-Face-A: through X-Face-A9: could be used for an alpha channel for APNG parity. And if you wanted to do distance fades like can be done in the Source Engine with [[VTF]] sprays, you could in theory do that too with extra fields. Since X-Face-el doesn't see the 7 least significant bits in a 48x48 TrueColor X-Face but sees a version of the image that is recognizable (albeit only in 48x48 mode), a decoder could just ignore the HDR and alpha components if it only does Datula mode at best. On the topic of Datula, DFaceEx by Saku works (the Datula X-Face plugin credits this person as SAKUDA Yasunori) has the unfortunate nature of supporting 3-bit RGB, multi, and animation, but not grayscale or TrueColor mode. The 24-bit version that came after, but only in Datula, not the other apps, had added it as a bonus feature over the X-Face-el parity addition of grayscale, and the readme warns that X-Face-el apps like Gnus will not display it properly and so interchange of it was marred, but at least SAKUDA Yasunori saw this avenue for improvement and did so in the simplest way that by sheer chance is easy to replicate even after the source code has become lost media and only FaceMake and the plugin as binaries survive.

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.
Especially as you start to get fancier and fancier, at least going by various mailing list archives still online. Also the people who still talk on Usenet still frequently use X-Face, but unfortunately even though Emacs/Gnus support X-Face-el and Datula can read news, finding examples of extended X-Face on Usenet is quite elusive, be it in archival news servers or in the servers that people still, to an extent, converse in rather than use as a way to obtain elusive files. Not to mention to have any hope of finding a Datula one, you would almost certainly need to look in Japanese newsgroup archives from the very early 2000s from 2002 to a bit after 2005's Face header and before the rarity of custom header support and decent newsgroups. It's like trying to catch smoke. They are like a golden unicorn.

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.
Of note is that X-Face itself was optimized by James Ashton himself to try and fit in a certain number of lines in a text-based e-mail client, part of why the choice to use 1bpp BW was used, even though computers in 1989 supported enough colors to make [[GIF]] possible.
James Ashton's later (and unpublished) experiments to add color to X-Face were ran when e-mail technology was a bit more complex. But the Japanese users figured this out in his stead in the late 1990s to early 2000s. The idea of using multiple X-Face headers to make a more-complex image according to an X-Face-el readme was had when one of the Japanese developers working on it had seen an e-mail that accidentally had two X-Face headers and didn't implode. So that's when the idea to deliberately use multiple headers came about. For color mode, the relevant developer was inspired by how the 3 color components of color TV work. This was in the 3-bit RGB context. But in essence, the format was extended based on sudden ideas by Japan that the West never considered, prior to making Face headers.

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).
[https://purl.org/x-face-spec A specification] has been written by reverse-engineering Compface.

== 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[http://kinzler.com/ftp/faces/compface-win/] uses 8-bit words.

== Software ==
* Compface
** [http://ibiblio.org/pub/linux/apps/graphics/convert/compface-1.4.tar.gz compface-1.4.tar.gz] (<code>uncompface -X</code> to convert to [[XBM]] format)
** [http://ftp.xemacs.org/xemacs/aux/compface-1.5.2.tar.gz compface-1.5.2.tar.gz]
** [https://ftp.ussg.iu.edu/solaris/freeware/SOURCES/compface-25Jan90.tar.gz compface-25Jan90.tar.gz]
** [http://kinzler.com/ftp/faces/compface-win/ X-Faces for Windows 95/NT]
* [[FFmpeg]]
* {{Deark}}
* [http://www.dairiki.org/xface/ Online X-Face Converter]
* [https://packages.debian.org/sid/x-face-el 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.

* [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp Datula] - A Japanese e-mail client which supported plugins in versions such as [https://web.archive.org/web/20040405125946*/http://www.onsystems.co.jp:80/download/datula1.52.01.01.exe 1.52.01.01], two of which involved extended X-Face.
** [https://web.archive.org/web/20001025151154/http://www.find.co.jp:80/~saku/download/dfaceex1001.zip Datula DFaceEX X-Face Plugin] - An X-Face viewer plugin for Datula capable of viewing extended X-Faces.
** [https://web.archive.org/web/20080828060424/http://cgisv.chldren.net:80/~saku/xfaceplugin.html 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.

== Samples ==
* https://dev.mutt.org/trac/wiki/MuttGuide/XFace - Search for "compface tao.xbm".
* [http://kinzler.com/ftp/faces/winface/WinFace1_3-src.zip WinFace1_3-src.zip] → WinFace/default_face.txt
* [http://faces.sourceforge.net/Documents/faces.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.

* {{DexvertSamples|image/xface}}

== Links ==
* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
** [https://web.archive.org/web/20170319101112/http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Archived page
* [http://faces.sourceforge.net/Documents/faces.txt faces man page]
* [[Wikipedia: X-Face]]
[[Category:E-Mail, newsgroups, and forums]]

X-Face

2026-03-24T21:22:38Z

St. GIGA: Add info on more of the Japanese modes.

BWTC32Key

2026-03-06T18:14:50Z

St. GIGA: Added details about how the AES works.

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| mimetypes = {{mimetype|application/prs.bwtc32key}}
| wikidata = {{wikidata|Q105859280}}
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the 8.3-safe "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. .B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing. Also it can do camel case if required but mostly to avoid bugs. Also the .B3K extension being an unclaimed 8.3-safe file extension was quite lucky and useful given how it's friendly to older hardware if ported to something like C.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Additionally, setting the AES256-CTR counter value to the current time and/or an LFSR RNG (the latter would serve as a salt) both prevent decoding being reversible, and unencrypted use only works due to how exactly the key is generated. This is important to factor.

Also, the program's assumed "application/octet-stream" MIME type from other sources may have fit more in the past, but the canonical and IANA-compliant MIME type that ISN'T generic is "application/prs.bwtc32key", but it is not intended to be implemented in a way breaking existing code using "application/octet-stream". Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type until years later, and it's in the prs/personal range for best IANA compliance but if that wasn't a factor there would be no "prs." and it may not be "application" as the family of formats it is under, rather, something like "text/" due to the format being text-based (and by extension not technically binary especially given the number base being 32768 instead of 2). Oh and the developer hasn't contacted the IANA yet due to not wanting to reveal their real name for multiple significant reasons. At least the program is distinct enough and is in the "personal" range of types to keep on the good side of the IANA as best as possible in light of the circumstances.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.

In 2024 the SHA-256 got a security fix and the program got some extra UI features involving copy and paste.

So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

BWTC32Key

2026-01-23T21:21:55Z

St. GIGA: File extension info

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| mimetypes = application/prs.bwtc32key
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the 8.3-safe "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. .B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing. Also it can do camel case if required but mostly to avoid bugs. Also the .B3K extension being an unclaimed 8.3-safe file extension was quite lucky and useful given how it's friendly to older hardware if ported to something like C.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Also, the program's assumed "application/octet-stream" MIME type from other sources may have fit more in the past, but the canonical and IANA-compliant MIME type that ISN'T generic is "application/prs.bwtc32key", but it is not intended to be implemented in a way breaking existing code using "application/octet-stream". Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type until years later, and it's in the prs/personal range for best IANA compliance but if that wasn't a factor there would be no "prs." and it may not be "application" as the family of formats it is under, rather, something like "text/" due to the format being text-based (and by extension not technically binary especially given the number base being 32768 instead of 2). Oh and the developer hasn't contacted the IANA yet due to not wanting to reveal their real name for multiple significant reasons. At least the program is distinct enough and is in the "personal" range of types to keep on the good side of the IANA as best as possible in light of the circumstances.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.

In 2024 the SHA-256 got a security fix and the program got some extra UI features involving copy and paste.

So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

BWTC32Key

2026-01-23T21:17:43Z

St. GIGA: More mime info

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| mimetypes = application/prs.bwtc32key
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Also, the program's assumed "application/octet-stream" MIME type from other sources may have fit more in the past, but the canonical and IANA-compliant MIME type that ISN'T generic is "application/prs.bwtc32key", but it is not intended to be implemented in a way breaking existing code using "application/octet-stream". Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type until years later, and it's in the prs/personal range for best IANA compliance but if that wasn't a factor there would be no "prs." and it may not be "application" as the family of formats it is under, rather, something like "text/" due to the format being text-based (and by extension not technically binary especially given the number base being 32768 instead of 2). Oh and the developer hasn't contacted the IANA yet due to not wanting to reveal their real name for multiple significant reasons. At least the program is distinct enough and is in the "personal" range of types to keep on the good side of the IANA as best as possible in light of the circumstances.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.

In 2024 the SHA-256 got a security fix and the program got some extra UI features involving copy and paste.

So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

BWTC32Key

2026-01-23T21:07:59Z

St. GIGA: Amend mimetype explanation

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| mimetypes = application/prs.bwtc32key
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Also, the program's assumed "application/octet-stream" MIME type from other sources may have fit more in the past, but the canonical and IANA-compliant MIME type that ISN'T generic is "application/prs.bwtc32key", but it is not intended to be implemented in a way breaking existing code using "application/octet-stream". Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type until years later, and it's in the prs/personal range for best IANA compliance but if that wasn't a factor there would be no "prs." and it may not be "application" as the family of formats it is under, rather, something like "text/" due to the format being text-based.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.
So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

BWTC32Key

2026-01-22T20:15:34Z

St. GIGA: Added a canonical MIMEtype that satisfies IANA rules if registered and is neither short and cryptic nor a length hog.

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| mimetypes = application/prs.bwtc32key
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Also, the program's "application/octet-stream" MIME type may fit NOW, but a dedicated one is planned, yet it is not intended to be implemented in a way breaking existing code. Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.
So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

X-Face

2025-09-26T21:24:47Z

St. GIGA: Include info about MONO X-Face types, I feel like there's a LOT of ground covered, and there's more, but I can spare you from it.

X-Face

2025-09-26T20:13:21Z

St. GIGA: Extra explanation

X-Face

2025-09-26T18:01:18Z

St. GIGA: Fix link mistake on archived page

X-Face

2025-09-26T17:59:46Z

St. GIGA: Added further info about size and complexity.

X-Face

2025-09-26T17:48:19Z

St. GIGA: Links

X-Face

2025-09-26T09:29:28Z

St. GIGA: Added more info

X-Face

2025-09-25T21:41:11Z

St. GIGA: Fix accidental typo

X-Face

2025-09-25T21:40:42Z

St. GIGA: Added mention of extensions, and their potential effect on certain clients.

X-Face

2025-09-25T21:31:37Z

St. GIGA: Added notes about FaceMake support.

X-Face

2025-09-25T21:11:40Z

St. GIGA: Fix link typo

X-Face

2025-09-25T21:10:53Z

St. GIGA: Fix typo.

X-Face

2025-09-25T21:10:06Z

St. GIGA: Add X-Face-el samples that were made when the format was in active use.

X-Face

2025-09-25T21:01:07Z

St. GIGA: Added archived and additional links

User:St. GIGA

2025-09-06T06:26:05Z

St. GIGA:

I'm a techie who does cool stuff, including fiddling around with compression (BWTC32Key), and holding the record for most-complex X-Face.

X-Face

2025-09-06T06:24:44Z

St. GIGA: Include properly-folded headers in the Datula example (intended to be the pinnacle example), and the associated GIF now has a pixel in one frame restored. Nothing too exotic. Folding of the prior usage of Face may be done off-and-on depending on time

X-Face

2025-08-29T15:53:37Z

St. GIGA: Added example of Datula 24-bit mode with its secret animation mode combined with ALL X-Face-el modes and of course Face:

X-Face

2025-08-29T00:51:21Z

St. GIGA: fix typo

X-Face

2025-08-29T00:50:40Z

St. GIGA: Added Datula-safe versions of extended X-Face

X-Face

2025-08-22T21:35:01Z

St. GIGA: Fix indent

X-Face

2025-08-22T21:34:23Z

St. GIGA: Added a recent discovery that the e-mail client Datula got plugins for X-Face that took the X-Face-el extensions even further, unifying them into beyond-48x48px 24bpp animated RGB , allowing for what is basically opaque APNG in MIME headers.

X-Face

2025-07-29T23:48:07Z

St. GIGA: Added examples of X-Face extensions that go beyond 48x48px.

X-Face

2025-07-12T04:31:41Z

St. GIGA: Fix link typo

X-Face

2025-05-26T18:25:16Z

St. GIGA: Fix line bleed.

X-Face

2025-05-26T18:20:59Z

St. GIGA: Explain that Face: headers are Base64+PNG in a MIME header.

X-Face

2025-05-26T18:01:51Z

St. GIGA: Add extended X-Face samples.

User:St. GIGA

2025-05-10T21:23:33Z

St. GIGA: Created page with "I'm a techie who does cool stuff."

I'm a techie who does cool stuff.

BWTC32Key

2023-11-28T23:14:11Z

St. GIGA: Added further and important information

{{FormatInfo
| formattype = electronic
| subcat = Transfer Encodings
| tpm = Encryption
| developed by = stgiga
| maintained by = stgiga
| spec availability = Free
| error resilience = Yes
| patent license = Unencumbered
| reference impl = https://stgiga.github.io/bwtc32key
| extensions = {{ext|b3k}}
| released = 2019
| magic = 0xFEFF4D00, "bwtc", "nomo", "dfsm", "fenw", 0x4D01
| compression = Always Lossless
| extended from = bzip
| spec = https://github.com/stgiga/bwtc32key
| endianness = Big-Endian
| }}
'''BWTC32Key''' is a single-file [[compression]] tool and format with optional [[encryption]], that also is text-armored, and also initially defined the "*.B3K" file extension that was first used by the format.

== Discussion ==
The code is based upon specific [[JavaScript]] implementations of Base32768, [[AES]], [[SHA-256]], and a spiritual successor to the original [[bzip]] format. The code is based upon JS code that runs in pure JS with no dependencies and is housed in the [[HTML]] frontend as a single monolithic program.

The output of the encoder is a text string. B3K files are always [[UTF-16]] Big-endian text documents bearing the Byte Order Mark that contain said string. That string is a version of Base32768 which uses [[Hangul]] Syllable blocks and Han ideographs to allow font support while keeping size down in bytes. Also, the string is essentially a Korean message but in a different style. The file starts with a header of 0xFEFF4D00 and ends with a trailer of 0x4D01. The file CAN be concatenated, but to reverse that, one must use a text editor to extract the portion you need, due to the way the original program currently works.

All of the code is stream and chunk compatible, and this includes the AES256 implementation which uses the Counter mode. The password field as of 2023 accepts [[UTF-8]] and has never had a length limit. Also, the encryption can be blanked out, allowing the format to be used in things that encryption wouldn't be useful in, such as an image compression format, essentially leaving the encryption feature unused when the password field is left blank or at default.

The format was written in pure [[JavaScript]] and is purely FOSS. The format was written by the author starting at age 15 (the earliest POSSIBLE estimate COULD very well be AROUND 14) and was definitely finished by the time they turned 17. This does show in the code. The compression and encryption functionality of this program coincidentally harks back to the Classic Mac OS days of [[PackIt]], which featured similar sequential concatenation and compression of multiple files and forks into the archive as well as encryption, all far more primitive and inefficient than BWTC32Key.

The Base32768 final step is essentially the antithesis of the original [[BinHex]], because instead of using an algorithm that doubles the binary input size via base 16, the Base32768 step makes the AES256-CTR encrypted BWTC archive (with standard US [[ASCII]] magic number "bwtc" in the Base32768-decoded decrypted compressed BWTC archive, which uses another US-ASCII magic number of "nomo" for the NoModel step of the process, before a DefSum step with yet another US-ASCII magic number of "dfsm" (assuming a compression level of five or lower), followed by the Fenwick Tree-based range coder step that has one more US-ASCII magic number of "fenw", (if the compression level is higher than 5. The five-or-lower is called "Fast mode" in the code.) (All 8-bit and 7-bit US-ASCII variants of these ASCII magic numbers are allowed.) all of which must each be present in their respective steps during each of their respective spots in the decompression steps of the decompression process, which is done last after the AES256-CTR decryption and the Base32768 decoding have completed, which all must successfully happen correctly with everything in the right places and sequences in order for the program to work, which is why all of these magic numbers exist. All of them are used to make the program safer from data corruption and other errors that may occur at any point during the execution of the program.)
compression only 16/15 of the original compressed size prior to the inherently padding-free AES and Base32768 steps, assuming that the UTF-16BE with BOM output is the encoding to be fed into the output text file, which uses the ".B3K" extension instead of the .txt extension that is normally used for standard plain text documents. It should be noted that since the BWTC compressor is very simple compared to even the original bzip, and that the 256-bit [[AES]] variety used uses the counter mode which needs no padding at all, the BWTC32Key format is very slim and subtle in every possible way.

As a text based format that closely resembles human text, it can be used where text is exclusively required (in most cases), while also being similar in spirit to authentic human scripts, which allows it to be injected into written works as if it were a Korean section of actual human writing, with no humanly-distinguishable traces at all. Also, due to it being stream compatible, broadcasting it can be done as a means of sending data through live channels as a stream of data one could opt into. Another feature it has is that it will never decode corrupt input, without computing anything. Meaning, it will fail if the magic number of the BWTC archive ("bwtc") (or the other magic numbers) isn't present in the compressed data due to corruption or the wrong key, or if the Base32768 text itself has junk thrown in or isn't properly formed or decodable. And if the corruption corrupts the Base32768 text data itself, or even the UTF16BE (with BOM) encoded Base32768 text itself, it will also fail in either case. This ensures that corrupted files will not be created by the decoder or your system, which can help stop damage to your system if something like a firmware blob or an executable was affected. This format does not care about file information of any kind. Hence, this is why it can be used as a chunk or stream format in cases where file info isn't needed. This is only possible because of the encryption feature being optional to apply to the input, thus allowing data (such as uncompressed image data, typeface data, soundbank data, and open streams) that would be pointless and unwise to encrypt to be able to be used with this format. As mentioned before, live input streams are allowed, and real time data input is as well. And in other implementations, multiple files could be encoded and then concatenated, optionally with different keys per file, all with the right logic.

The format is well suited to tarred input because tar files are a text-like block and stream based format that has many null bytes, all of which make the tar format very similar to the rest of the entire BWTC32Key format itself. Thus, it is a match made in heaven, and that means that it is a good idea to use tarred input for that very same reason.

The Korean text output does not interfere with actual Korean because Zhuyin (also known as Bopomofo) and Hangul Jamo can be used to replace the Han ideographs (Hanja), and Korean syllable blocks (Hangul) respectively in a message running alongside the data. Thus, it does not render Korean communication impossible when using it, which allows for use in textual messages as if it were native text but with the extra feature of not locking out anyone's language from being spoken there. This means one can seamlessly put this in something like a written work in txt format. This is superficially similar to using [[PGP]] on part of a written work in regards to how the headers and text encoding work. BWTC32Key is its own animal entirely though, and the details may require accurate emulation to ensure that nothing messes up in ports/etc. Coincidentally, the letter "K" in the ".B3K" file extension can be interpreted as a reference to the format using Korean-esque text as its output, which is similar in meaning to the format's intentional usage of UTF16BE in order to alphabetically match up the "BE" part of UTF16BE to the "B3" part of the ".B3K" file extension. On systems with all-caps filenames, the ".B3K" file extension has the extra bonus feature of properly acronyming the full name of the format according to most rules for capitalized acronym casing.

Some things to note: In 2022, support for the program generating and reading its own files without needing the user to manually paste the string was added (this also made it so that the files are done correctly. UTF-8 harms the compression savings, and 0xEFBBBFE4B480 is, due to being UTF-8, indicative of wrongful UTF-8 transcoding. The first bytes of .B3K files should be 0xFEFF4D00, not THAT. The ending bytes should be 0x4D01. Basically, reading .B3K files that aren't in compliance with a header of 0xFEFF4D00 and a trailer of 0x4D01 is allowed, but never generate anything that is not that. That being said, because Unicode itself using Big-endian goes against many processor architectures in modern use, this fact isn't intended to be an immovable directive. Basically, the preferred encoding is UTF-16BE.

Also, the program's "application/octet-stream" MIME type may fit NOW, but a dedicated one is planned, yet it is not intended to be implemented in a way breaking existing code. Furthermore, if one is surmising said "application/octet-stream" MIME type, the place it shows up in the code's reference implementation is in the "MIME type" box, which is actually supposed to be the MIME type of a decoded file, not an encoded one. Since the format stores only the data of a file, when decoding it, the user specifies the file name, extension, and MIME type to "download" after decoding. If one wants multiple files, attributes, names, and dates, TAR beforehand is advised. Basically, the developer never gave the program a MIME type.

As for downloading a .B3K with the button in the reference implementation, the code involved downloads whatever is in the output string box as a UTF-16BE text document, and the relevant code assigns a MIME type of "text/plain". Samsung Internet on Android gives a ".B3K.txt" as the file downloaded, but nothing else does. That said, because ANYTHING put into the box gets saved, you don't need a text editor to encrypt text. All you need is to put your text in the box, change the extension in the "B3K filename" box to .txt or the extension of a text-based format of your choice, and download. Then, upload THAT with your desired key. The decoding of files doesn't care what you upload to be put in the box. That code reads whatever you feed it as UTF-16BE. So, after decryption, you can upload the output file into the .B3K uploader, and the text/etc will appear. So, the program can operate as a textual cipher. So trying to make the extension on such a Samsung case be .B3K would actually reduce functionality, albeit unintended functionality, which the program has a LOT of. One of the best ones is password generation and storage, in conjunction with other cryptographic and additional uses, of which there are many.)

Also, in 2022, the Compression Level was allowed to be set by the user rather than hard-coded at 9. It can be made to go higher, which can net extra savings if you are clever. Also, one should test to see whether the output successfully decompresses on a chosen overdriven level. Secondly, it supports going below one, which is helpful if speed is a priority over anything else. Basically, you can go lower than 0.5. The way the compression level in this and in the BZip-family archivers work is that they multiply the level times 100,000 to get the block size. So one can use non-integral numbers if the program lets you, and the developer of BWTC32Key sees no need to restrict to integers between 1 and 9. Also, that year, a fix was found for the reference implementation having problems on newer macOS versions, namely due to their stripping of the Byte Order Mark. Basically, the program was made to behave fine in such a situation.

Additionally, in 2023, fixes were made that don't break compatibility, and one of the side bonuses of the fix was Unicode support in the password box.
So, in the span of several years since the 2019 version, various limitations of the program were lifted thanks to further development.

== Links ==
* The author's format implementation is at [https://stgiga.github.io/bwtc32key/ Github Implementation]
* The github repository is at [https://github.com/stgiga/bwtc32key The Repo]

[[Category:Compression]]
[[Category:Encryption]]

BWTC32Key

2021-09-14T07:21:47Z

St. GIGA: Wording improvements

BWTC32Key

2021-05-19T23:36:15Z

St. GIGA:

BWTC32Key

2020-04-02T22:46:40Z

St. GIGA: Added bonus trivia

BWTC32Key

2020-03-10T16:19:13Z

St. GIGA: Fixed spelling

BWTC32Key

2020-03-05T18:15:10Z

St. GIGA:

BWTC32Key

2020-03-05T18:10:43Z

St. GIGA:

BWTC32Key

2020-03-05T18:06:28Z

St. GIGA: Early estimates added

BWTC32Key

2020-03-01T06:53:58Z

St. GIGA: Added extra trivia on code