vt1200/xie/XIE_COMPRESSION_SCHEMES.md

Compression schemes in the XIE headers

Two different XIE lineages are vendored here, and they do not define the same set. The terminal speaks the first one.

DEC XIE 2.3 — what the VT1200's server implements

docs/dec/xie23/include/dec/extensions/XieAppl.h:151-157 — the complete set, five values, nothing else:

    /*
    **	Compression Schemes
    */
#define XieK_PCM                0     /* uncompressed                        */
#define XieK_G31D               1     /* CCITT Group 3, one-dimensional      */
#define XieK_G32D               2     /* CCITT Group 3, two-dimensional      */
#define XieK_G42D               3     /* CCITT Group 4                       */
#define XieK_DCT                4     /* JPEG - 2D discrete cosine transform */

XieK_DCT is the JPEG scheme: the man page says of the cmpprm argument that it "specifies a parameter required for the DCT compression scheme" (man/XieGetImage.3X:56, man/XieSetStream.3X:68). There is no XieK_JPEG and no TIFF/RLE/LZW/PackBits constant anywhere in the 2.3 headers.

The scheme travels in the SetTransport request as a byte plus a parameter word (XieProto.h:538-548):

typedef struct {
    ...
    CARD32	    compression_parameter;
    CARD8	    compression_scheme;
    CARD8	    mode;
    ...

What the DEC 2.3 server actually accepts

server/xie/XieTransport.c, ProcSetTransport (line 616 onward) validates the scheme per image:

	switch( stuff->compression_scheme )
	    {				    /* verify compression_scheme    */
	case XieK_PCM  : break;
	case XieK_G31D :
	case XieK_G32D :
	case XieK_G42D :
	    MatchOkIf_( IsBitonal_(img) && stuff->mode != XieK_Tile, ...);
	case XieK_DCT  :
	    MatchOkIf_(!IsBitonal_(img) && stuff->mode != XieK_Tile
		       && org != XieK_BitByPlane, ...);
	default: BadValue_(stuff->photo_id);
	    }

So, concretely:

• PCM — always allowed.
• G31D / G32D / G42D — require a bitonal image and a mode other than XieK_Tile (i.e. PutStream/GetStream, not PutTile/Tile).
• DCT (JPEG) — requires a non-bitonal image, a mode other than XieK_Tile, and a component organization other than XieK_BitByPlane.
• Anything else — BadValue.

In the transport implementation (ProcGetStream, line 275 onward) only three schemes are real, and two are stubs:

	case XieK_DCT  : ... s = DdxEncodeDct_( &Udp_(img,p), ... );  break;
	case XieK_G42D : ... s = DdxEncodeG4_( Udp_(img,p), ... );    break;
	case XieK_PCM  : ...                                          break;
	case XieK_G31D :			/* not yet supported	    */
	case XieK_G32D :			/* not yet supported	    */
	default        : s = BadValue;

Same stub pair in ProcSetStream (line 1460). The DCT and G4 work is delegated to the DDX hooks DdxEncodeDct_ / DdxEncodeG4_ — i.e. to the image accelerator on the board, which is why the firmware's DDX render path reports DDX_RENDER: unsupported compression scheme when it cannot service one.

This is why our working client must use XieK_PCM. It sends a bitonal 64x64 photomap in mode = XieK_Tile, and under the rules above that combination admits PCM only — G3/G4 are refused for Tile mode, and DCT is refused for a bitonal image. Requesting anything else returns BadValue, which is the BadValue (integer parameter out of range) seen in the early runs; BadMatch has the same origin, since these are MatchOkIf_ checks.

X Consortium X11R6.1 — a different, larger list

xc/include/extensions/XIE.h:175-206 (the xieperf lineage, not what the VT1200 runs) uses DecodeTechnique / EncodeTechnique enums with ten codecs:

constant	value	meaning
xieValDecodeUncompressedSingle	2	bitonal & grayscale
xieValDecodeUncompressedTriple	3	colour
xieValDecodeG31D	4	FAX
xieValDecodeG32D	6	FAX
xieValDecodeG42D	8	FAX
xieValDecodeJPEGBaseline	10	grayscale & colour
xieValDecodeJPEGLossless	12	grayscale & colour
xieValDecodeTIFF2	14	TIFF modified G31D
xieValDecodeTIFFPackBits	16	TIFF Apple format

So JPEG appears in both lineages — as XieK_DCT (2.3, one value) and as JPEG baseline/lossless (X11R6.1, two values) — but the 2.3 protocol that the terminal speaks has only the single Scheme-4 DCT code, with no baseline/lossless split and no lossless predictor field in the wire struct.

Cross-reference: the DTJ article

docs/dec/DTJ-1991-v03-04-bitonal-image-accelerators.pdf — "Hardware Accelerators for Bitonal Image Processing" (Payson, Cianciolo, Crouse, Winsor; DTJ Vol. 3 No. 4, Fall 1991). Reading it against the headers above:

• The accelerator ASIC it describes is bitonal and is a CCITT decoder: "The decompressor chip acts as a CCITT binary image decoder", converting Huffman codes to fixed-length codes, and it covers G3-1D, G3-2D and G4-2D. The chip set is decompressor + scaler (M:N, 1..127) + rotator — the "scalution" hardware the firmware drives.
• JPEG is discussed in the continuous-tone section of the same article, not as part of that ASIC: "for gray-scale and color images, the Joint Photographic Experts Group (JPEG) standard"; "the JPEG compression method is based on the two-dimensional (2D) discrete cosine transform (DCT)". For hardware it cites C-Cube's CL550-10 JPEG Image Compression Processor, not the bitonal chip.
• The DECimage 1200 terminal (the image-capable sibling of this unit) is described as using this hardware: "The DECimage 1200 can read, transport, decompress, scale, and display an 8.5-by-11-inch bitonal document in 1 to 2 seconds."

So the article's "image board" is the bitonal G3/G4 decompressor, and JPEG/DCT is the scheme XIE defines for the continuous-tone data type that the same protocol carries — the two correspond exactly to XieK_G42D and XieK_DCT.