Session captures of Jexer-style sixel output are collected here to aid terminal authors wishing to test their sixel implementation. Each capture includes the raw output and a screenshot of what the final result looks like under xterm for comparison.
The input files to Jexer used in this test are:
- cjk.txt - CJK-encoded text file, emitted by the TTerminalWindow as many sixel-encoded images.
- lady-of-shalott.six - A pre-encoded-to-sixel 1000x750 large image file. Here is the same image converted to PNG.
- lemmling_Ladybug.png - A 274x319 image file.
- jexer-test.jar - The Jexer jar compiled with TApplication.imageSupportTest = true. This leaves the terminal in its final state upon exit.
The test itself consists of:
- Running the Jexer test jar via
java -jar jexer-test.jar. - From the pull-down hamburger menu, selecting
Open image...and opening lady-of-shallot.png. - From the pull-down hamburger menu, selecting
Open image...and opening lemmling_Ladybug.png. - Spawning a shell from the pull-down menu, and in that
shell
cat cjk.txt. - Selecting and dragging the windows around the screen.
- Exiting the program via Alt-X.
- The terminal size is 80x24. The sixel palette size is 128,
and is not shared across the images (private color registers is
enabled:
CSI ? 1 0 7 0 h).
A Note on Transparency
None of the images used in the test captures have transparent pixels.
Sixel supports "transparency" in the form of unspecified pixels, and this feature can be used for some really neat effects. Alas, neither img2sixel nor Imagemagick seem capable of generating transparent pixels (at least I could not figure it out). I created two sixel images with missing pixels manually, by adding the "0;1;0" options in the introducer and changing most of the black color characters to "?" within the file that can be used to test images overlapping text:
Jexer git head can also be used to create transparent sixel images, using the jexer.backend.HQSixelEncoder main() function. For example, to convert a PNG called "file.png" to a transparent sixel image called "file.six":
java -cp jexer.jar jexer.backend.HQSixelEncoder file.png > file.six
Many more sixel inputs and outputs from a real hardware terminal have been made available by hackerb9 here, and include images with transparency. The sixel output of Chafa can also generate images with transparency.
If your terminal supports an image format with PNG file support, for example WezTerm, mintty, or iTerm2, then true alpha-blending can also happen, with wonderful effect. See here for an example.
Font size: 12x24 - Sixel
Note that replicating this screenshot also requires 24-bit RGB support in the terminal, which is how the text translucency effect is achieved.
raw capture file (69M)
zip compressed capture file (28M)
Image under xterm:
Font size: 10x22 - iTerm2 Images
Note that replicating this screenshot also requires 24-bit RGB support in the terminal, which is how the text translucency effect is achieved.
raw capture file (91MB)
zip compressed capture file (62M)
A screenshot of xterm is not available. Below is a screenshot using
wezterm.
Terminal Crash Tests
The following tests have caused at least eight different terminals to crash via their image support facility. The terminals were implemented in C, C++, Java, Rust, and Go.
Sixel: Very Large Repeat Counter (CVE-2022-24130)
(Note: Originally discovered by Nick Black (@dankamongmen), see CVE-2022-24130 here.)
This test sends a very large repeat counter to a sixel decoder, which may either cause an overflow and crash the terminal, or exceed memory and crash the terminal. The output is the same as this script. A well-behaved terminal should see nothing on screen.
Sixel: Very Large Image
This test attempts to allocate a massive 100000 x 100000 empty sixel image. A well-behaved terminal should discard the image, since it will clearly be larger than the available screen. In practice, images wider than 1000 pixels in either direction should be discarded, to match the behavior of xterm.
iTerm2: Very Large Image
This test attempts to allocate a massive 100000 x 100000 empty PNG image. A well-behaved terminal should either discard the image or crop it to fit the screen, since it will clearly be larger than the available screen. It is not specified in the iTerm2 image protocol documentation what the terminal should actually do for a very large image.
Fully Supporting Sixel In Your Terminal
For applications to really get the most out of your terminal's sixel or iTerm2 image support, you should also have the following features:
- Sixel (4) reported in the Device Attributes (DA1) response, so that the application knows your terminal has sixel support.
- Support for OSC 11 query and response, so that terminal default background color can be discovered. This is used by lsix.
- Support for OSC 4 query and response, so that ANSI colors can be discovered. This allows more natural-looking integration of partially transparent images with text.
- Support for XTWINOPS 14, 16, and 18 query and response. This allows applications to determine the text cell pixel dimensions, which is critical for integrating images and text.
- Support for XTSMGRAPHICS query and response, so that the number of sixel colors (registers) can be discovered.
- DECSET 1070, so that each image can have its own palette. This allows applications to have much higher image quality -- approaching 20-bit depth if used carefully.
- If you implement Sixel Display Mode (DECSDM) (DECSET 80), please be aware that setting DECSDM disables sixel scrolling and vice versa, which is opposite what xterm documented for several years.
