X-Face - Revision history

St. GIGA: Bad Apple info

2026-05-16T21:44:15Z

Bad Apple info

St. GIGA: Added Wikimedia Commons link

2026-05-01T21:10:29Z

Added Wikimedia Commons link

St. GIGA: Fix typo

2026-04-26T07:34:49Z

Fix typo

St. GIGA at 00:37, 25 April 2026

2026-04-25T00:37:56Z

St. GIGA: Added more info

2026-04-25T00:32:44Z

Added more info

St. GIGA at 22:44, 24 April 2026

2026-04-24T22:44:13Z

St. GIGA: /* Links */

2026-04-24T18:03:04Z

‎Links

St. GIGA: /* Software */

2026-04-24T18:02:21Z

‎Software

St. GIGA: Add Saku's name

2026-04-24T18:01:18Z

Add Saku's name

St. GIGA: Preliminary edit on inversion with bit depth

2026-04-24T08:55:54Z

Preliminary edit on inversion with bit depth

@@ Line 26: / Line 26: @@
 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. The thing with extended X-Face in this situation is that it does not even have to follow a lossy approach, especially given that this is NOT the only type of space savings that can be done here. And for the record higher bit depth RGB headers have the same inverted status as grayscale because it literally IS 3 grayscale X-Face headers merged into a TrueColor RGB X-Face header.
-One thing that has been tested in Datula is that changing the grayscale depth in a multi grayscale (and in fact each cell can be true 1-bit) 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 but they only invert in X-Face-el, so you could potentially do something with that IF you're clever, and do it because of the huge difference in output size between solid black (larger due to an off-by-one error, and this is pretty bad for extended X-Face due to what those look like split-up, especially when you add the grayscale and TrueColor inversions) 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. That being said, you CAN do per-cell and per-frame bit depth changes in Datula's extended grayscale mode, which would make for a perfectly-accurate Bad Apple! test animation or reproduction of films on the silver screen, without wasting space. It really is quite ingenious how Datula X-Face works and what you can do with it in a nuanced way.
+One thing that has been tested in Datula is that changing the grayscale depth in a multi grayscale (and in fact each cell can be true 1-bit) 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 but they only invert in X-Face-el, so you could potentially do something with that IF you're clever, and do it because of the huge difference in output size between solid black (larger due to an off-by-one error, and this is pretty bad for extended X-Face due to what those look like split-up, especially when you add the grayscale and TrueColor inversions) 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. That being said, you CAN do per-cell and per-frame bit depth changes in Datula's extended grayscale mode, which would make for a perfectly-accurate Bad Apple! test animation (48x48 1bit is possible via using ffmpeg and X-Face-el but for proper frame rate you need to change the 10fps limit line in X-Face-el to a no operation line via commenting it out and then recompiling the Emacs Lisp files) or reproduction of films on the silver screen, without wasting space. It really is quite ingenious how Datula X-Face works and what you can do with it in a nuanced way, entirely possible by sheer chance.
 So if you combine per-frame bit depth, unequal channel bit depth, and per-48x48px bit depth, you can actually make X-Face videos either using ONLY the needed colors to represent any given scene, without loss, or if that is not helping it can be coupled with the lossy approach of intentionally going under that. And if you used something like GIFski's pngquant-based temporal dithering, you could do some pretty wild compression (well, to the extent that the dither pattern isn't too checkerboard to trigger X-Face's compression worst-case compressed size). Even if you DO lower the depth a bit lower than needed, you could temporally dither as needed (which may be a good way to mitigate the over-dithering expansion risk). Whether intended or not, Datula X-Face's image and video fidelity is very very EXTREMELY selective. A bruteforce-match encoder would be the best option for doing X-Face video encoding so as to not waste space, as long as you do a colorcube analysis or its grayscale analysis sibling to see how many bits are needed for the smallest perfect reproduction or even below that if doing lossy compression (the creator of GIFski helped make a lossy [[GIF]] encoder so it IS possible to make lossless formats lossy) if one needs it even smaller, and then there's the temporal dithering. One could even do what Guetzli does and exploit human perception like it does with [[JPEG]] but for X-Face, though in ALL of these cases the code and potentially encode time would be slower. And this hasn't been fleshed out but an approach to the Arithmetic Coding step akin to what Zopfli and FlexiGIF do may work.

@@ Line 169: / Line 169: @@
 * 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.

@@ Line 29: / Line 29: @@
 So if you combine per-frame bit depth, unequal channel bit depth, and per-48x48px bit depth, you can actually make X-Face videos either using ONLY the needed colors to represent any given scene, without loss, or if that is not helping it can be coupled with the lossy approach of intentionally going under that. And if you used something like GIFski's pngquant-based temporal dithering, you could do some pretty wild compression (well, to the extent that the dither pattern isn't too checkerboard to trigger X-Face's compression worst-case compressed size). Even if you DO lower the depth a bit lower than needed, you could temporally dither as needed (which may be a good way to mitigate the over-dithering expansion risk). Whether intended or not, Datula X-Face's image and video fidelity is very very EXTREMELY selective. A bruteforce-match encoder would be the best option for doing X-Face video encoding so as to not waste space, as long as you do a colorcube analysis or its grayscale analysis sibling to see how many bits are needed for the smallest perfect reproduction or even below that if doing lossy compression (the creator of GIFski helped make a lossy [[GIF]] encoder so it IS possible to make lossless formats lossy) if one needs it even smaller, and then there's the temporal dithering. One could even do what Guetzli does and exploit human perception like it does with [[JPEG]] but for X-Face, though in ALL of these cases the code and potentially encode time would be slower. And this hasn't been fleshed out but an approach to the Arithmetic Coding step akin to what Zopfli and FlexiGIF do may work.
-Oh and in the case of unequal bit depths for RGB, you CAN have a mixture of multi-bit/grayscale and 1-bit color channels, so long as it doesn't go below 3 channels. This naturally brings up the concept of inversion (also doing an X-Face-el trick where you use a depth of 1 in a grayscale X-Face but use a regular X-Face for the purposes of inversion and to deal with the solid-black inflation is not how it works on Datula for reasons that will become clear, and in fact it acts as if there was no X-Face-Type when you try via "X-Face-Type: GRAY; depth=1" which does invert on X-Face-el but the odds of someone intentionally generating this is quite low so it isn't a big problem), and basically if the channel is 1 bit Datula doesn't invert it and if it's more than 1 bit Datula inverts it for each 48×48 region. Also, because grayscale is 1-channel it doesn't need 3 copies of a monochrome X-Face to make 1-bit cells in a multi animation. Also, adding onto the part about Zopfli/FlexiGIF-like tricks the bitstream can technically be made smaller in some cases but not very usefully, only when the bottom right matches a specific pattern (same patterns you see when you make the x-face string something really short, like 1 character). These x-faces are smaller than they would be if you decoded and re-encoded them but also by their nature they're mostly that dot pattern type, which are scrambled. Some even have that worst-case checker pattern, so there is that. An example is using ";-)" for a black checkerboard (which if encoded properly would be a worst-case), and ":-)" for a white checkerboard that would still be at least somewhat bad if encoded properly. So if an encoder ''really'' wants to save space it can change the actual shape to a smaller bitstream, situationally. Oh and assuming one uses image processing capable of identifying subjects this could be useful to be good shortcodes when they are needed most. Also codes like ":-|" have some utility too. And of course the fact this can be done to each bit of an image means you can subtly alter the image a la [[JPEG]] for smallest image size, beyond just doing the per-frame, per-cell, per-channel bit depth adjustments with (temporal) dithering and perceptual (Guetzli-esque tricks) methods. So in a way it is possible to compensate quite well for the inefficiency of this codec compared to other codecs, even ones that are already inefficient. In this case, the very sparse structure CAN save the whole thing in a way that other codecs simply cannot offer. None are nearly as selective codecs.
+Oh and in the case of unequal bit depths for RGB, you CAN have a mixture of multi-bit/grayscale and 1-bit color channels, so long as it doesn't go below 3 channels. This naturally brings up the concept of inversion (also doing an X-Face-el trick where you use a depth of 1 in a grayscale X-Face but use a regular X-Face for the purposes of inversion and to deal with the solid-black inflation is not how it works on Datula for reasons that will become clear, and in fact it acts as if there was no X-Face-Type when you try via "X-Face-Type: GRAY; depth=1" which does invert on X-Face-el but the odds of someone intentionally generating this is quite low so it isn't a big problem), and basically if the channel is 1 bit Datula doesn't invert it and if it's more than 1 bit Datula inverts it for each 48×48 region. Also, because grayscale is 1-channel it doesn't need 3 copies of a monochrome X-Face to make 1-bit cells in a multi animation. Also, adding onto the part about Zopfli/FlexiGIF-like tricks the bitstream can technically be made smaller in some cases but not very usefully, only when the bottom right matches a specific pattern (same patterns you see when you make the x-face string something really short, like 1 character). These X-Faces are smaller than they would be if you decoded and re-encoded them but also by their nature they're mostly that dot pattern type, which are scrambled. Some even have that worst-case checker pattern, so there is that. An example is using ";-)" for a black checkerboard (which if encoded properly would be a worst-case), and ":-)" for a white checkerboard that would still be at least somewhat bad if encoded properly. So if an encoder ''really'' wants to save space it can change the actual shape to a smaller bitstream, situationally. Oh and assuming one uses image processing capable of identifying subjects this could be useful to be good shortcodes when they are needed most. Also codes like ":-|" have some utility too. And of course the fact this can be done to each bit of an image means you can subtly alter the image a la [[JPEG]] for smallest image size, beyond just doing the per-frame, per-cell, per-channel bit depth adjustments with (temporal) dithering and perceptual (Guetzli-esque tricks) methods. So in a way it is possible to compensate quite well for the inefficiency of this codec compared to other codecs, even ones that are already inefficient. In this case, the very sparse structure CAN save the whole thing in a way that other codecs simply cannot offer. None are nearly as selective codecs.
 Currently the cleanest extended X-Face: files you can generate with existing software fall within the "pixel art" resolutions at 24bpp.

@@ Line 20: / Line 20: @@
 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. Modern Emacs doesn't even try to load it.
-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 in situations where excessive size is a problem, such as, say, the Internet speeds of the format's early days (~90s).
+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 (for instance something like "X-Face-Type: geometry=2x1; GRAY" is valid, 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 in situations where excessive size is a problem, such as, say, the Internet speeds of the format's early days, 1989 through the 1990s, and up until Face: headers. Dial-up was the issue.
 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, fit a limit, send faster on dial-up, 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. Of course, encoding this type of fancy optimized X-Face is a tall order, given this complexity.

@@ Line 26: / Line 26: @@
 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. The thing with extended X-Face in this situation is that it does not even have to follow a lossy approach, especially given that this is NOT the only type of space savings that can be done here. And for the record higher bit depth RGB headers have the same inverted status as grayscale because it literally IS 3 grayscale X-Face headers merged into a TrueColor RGB X-Face header.
-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 huge difference in output size between solid black (larger due to an off-by-one error, and this is pretty bad for extended X-Face due to what those look like split-up, especially when you add the grayscale and TrueColor inversions) 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.
+One thing that has been tested in Datula is that changing the grayscale depth in a multi grayscale (and in fact each cell can be true 1-bit) 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 but they only invert in X-Face-el, so you could potentially do something with that IF you're clever, and do it because of the huge difference in output size between solid black (larger due to an off-by-one error, and this is pretty bad for extended X-Face due to what those look like split-up, especially when you add the grayscale and TrueColor inversions) 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. That being said, you CAN do per-cell and per-frame bit depth changes in Datula's extended grayscale mode, which would make for a perfectly-accurate Bad Apple! test animation or reproduction of films on the silver screen, without wasting space. It really is quite ingenious how Datula X-Face works and what you can do with it in a nuanced way.
 Currently the cleanest extended X-Face: files you can generate with existing software fall within the "pixel art" resolutions at 24bpp.
-The resolution of what you can get out of FaceMake is about what you get out of NTSC Video CD but worse, though online video around the time of the Face header was on par with a theoretical Datula X-Face video file in resolution. Another caveat about mixing depths is that while some cases will have the "depth=N" field be the largest value of the animation (when doing frame changes alone, but this is still under investigation and needs more documenting too), but in cell depth changes and unequal bit depths it either has to be blank or it has to be the other way around. Also XEmacs when given grayscale and geometry displays each 48x48px piece sequentially. FaceMake can fold headers in varying ways. Also the X-Face-el developer information on backstory references a mountain picture and his own face as a test image used for color after finding someone with more than one B&W header before getting the idea to do color. Also a "status=" field existed in unpublished prototypes of X-Face-el's "X-Face-Type:" field and there was an X-Face-Shape: header planned that behaved like "geometry=NxN" in "X-Face-Type:", and for color, "X-Color-Face:" was planned too, and this is akin to the "RGB" and "depth=N" parts of "X-Face-Type:". Another catch is that in regards to depths Datula supports, a bit depth of 1 (channel-wise) is inverted compared to all higher depths (a side effect of grayscale being inverted compared to 1bit and compface quirks, and this plus another quirk make header size a thick mess in a situation like 24bit), and the "depth=N" in X-Face-Type has a visible effect on any images with a bit depth lower than the stated depth but it can be removed or lowered. So you may not even need depth=N if you're going to go at it with optimization on a granular, selective level, making each channel of each 48x48px cell in each frame be the exact bit depth needed to render it faithfully to the input content, and no bigger, or you go below that in a lossy approach. In essence, the extensions to X-Face are both quite nice and powerful but they are also just very particular and need to be handled appropriately given just how many quirks the whole codec has and still manages to work.
+The resolution of what you can get out of FaceMake is about what you get out of NTSC Video CD but worse, though online video around the time of the Face header was on par with a theoretical Datula X-Face video file in resolution. Another caveat about mixing depths is that while some cases will have the "depth=N" field be the largest value of the animation (when doing frame changes alone, but this is still under investigation and needs more documenting too), but in cell depth changes and unequal bit depths it either has to be blank or it has to be the other way around. Also XEmacs when given grayscale and geometry displays each 48x48px piece sequentially. FaceMake can fold headers in varying ways. Also the X-Face-el developer information on backstory references a mountain picture and his own face as a test image used for color after finding someone with more than one B&W header before getting the idea to do color. Also a "status=" field existed in unpublished prototypes of X-Face-el's "X-Face-Type:" field and there was an X-Face-Shape: header planned that behaved like "geometry=NxN" in "X-Face-Type:", and for color, "X-Color-Face:" was planned too, and this is akin to the "RGB" and "depth=N" parts of "X-Face-Type:". Another catch is that in regards to depths Datula supports, a bit depth of 1 (channel-wise) is inverted compared to all higher depths (a side effect of grayscale being inverted compared to 1bit and compface quirks, and this plus another quirk make header size a thick mess in a situation like 24bit), and the "depth=N" in X-Face-Type has a visible effect on any images with a bit depth lower than the stated depth but it can be removed or lowered. So you may not even need depth=N if you're going to go at it with optimization on a granular, selective level, making each channel of each 48x48px cell in each frame be the exact bit depth needed to render it faithfully to the input content, and no bigger, or you go below that in a lossy approach. In essence, the extensions to X-Face are both quite nice and powerful but they are also just very particular and need to be handled appropriately given just how many quirks the whole codec has and still manages to work. The kicker is that the creator, James Ashton, as well as the X-Face-el developers, are university professors. Also the other thing to note is that the developer of Datula's X-Face plugins and their ancestor XFaceTool004 has the same Romanized Japanese name as a major game developer who has quite the studio history, and had programmer roles, so it COULD be him, but since the Wayback Machine is where the Datula plugins are relegated to, it's hard to say for sure if this is the same person.
 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.

@@ Line 105: / Line 105: @@
 Another note is that this is far from the only eclectic decision by the developers working with X-Face, and even from the start, because
-X-Face's code has an off-by-one quirk in it that as an effect of it makes a solid black image compress with worse 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.
+X-Face's code has an off-by-one quirk in it that as an effect of it makes a solid black image compress with worse efficacy than a solid white image, and incidentally checkerboard patterns are up there in being the worst case for compression efficiency and so it makes dithering, shading, and higher bits of grayscale+Datula headers bloated at times, so like with solid black bloat it is a cause for concern, AND to top it off with regards to solid black vs solid white, the pieces of a grayscale X-Face or Datula 24-bit X-Face channels 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).

@@ Line 174: / Line 174: @@
 == Links ==
-* [http://www.cs.indiana.edu/ftp/faces/ Faces Archive] - Lists some X-Face resources
+* [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]]

@@ Line 144: / Line 144: @@
 * {{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://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.

@@ Line 149: / Line 149: @@
 * [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.
+** [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/SAKUDA Yasunori) 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.