mirror of
https://git.k-space.ee/arti/vt1200.git
synced 2026-11-02 12:23:17 +02:00
docs(xie): the compression schemes the XIE headers define
DEC XIE 2.3 (what the VT1200 speaks) defines exactly five, in XieAppl.h: XieK_PCM 0, XieK_G31D 1, XieK_G32D 2, XieK_G42D 3, XieK_DCT 4. XieK_DCT is the JPEG/DCT scheme; there is no XieK_JPEG and no TIFF/RLE/LZW constant. Worth recording because it explains the BadValue/BadMatch history: the server's ProcSetTransport allows PCM unconditionally, allows G3/G4 only for a bitonal image outside XieK_Tile mode, and allows DCT only for a NON-bitonal image outside XieK_Tile and outside XieK_BitByPlane -- anything else is BadValue. A bitonal 64x64 photomap in Tile mode therefore admits PCM only, which is what the working client sends. In ProcGetStream/ProcSetStream G31D and G32D are literally "not yet supported", and DCT/G42D are delegated to the DDX hooks DdxEncodeDct_ / DdxEncodeG4_ -- i.e. to the board's accelerator. The X Consortium X11R6.1 lineage (xc/) is a different, larger list: ten Decode/EncodeTechnique values including JPEGBaseline 10, JPEGLossless 12, TIFF2 14 and TIFFPackBits 16. Cross-referenced with DTJ Vol. 3 No. 4 (Fall 1991), "Hardware Accelerators for Bitonal Image Processing": the ASIC described there is a CCITT (G3-1D, G3-2D, G4-2D) decompressor plus scaler and rotator -- the scalution hardware -- while JPEG/DCT is that article's continuous-tone counterpart (citing C-Cube CL550-10, not the bitonal chip). The two map onto XieK_G42D and XieK_DCT.
This commit is contained in:
arti committed
1 parent
d8d54bb990
commit
742501be67
1 file changed
+138
@@ -0,0 +1,138 @@
|
||||
# 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:
|
||||
|
||||
```c
|
||||
/*
|
||||
** 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`):
|
||||
|
||||
```c
|
||||
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:
|
||||
|
||||
```c
|
||||
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:
|
||||
|
||||
```c
|
||||
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`.
|
||||
Reference in new issue
Block a user