open-standards/wai/wai-rs/tests/vectors/jpegai/README.md

# JPEG AI reference codestream and configuration vectors

`test256.bin` (367 bytes, SHA-256
`99840e5f472423f5a1261c9ec219d12dc910e9623d752672555dfea69ea4a097`) is the output
of the ISO/IEC 6048-1 reference software's encoder (BSD-3) at its default operating
point, for a 256×256 synthetic RGB test image (gradients and blocks). Segment layout:
PIH 49 bytes, TON 63, RDI 1, SORP 97, SORS 47, SOZ 83.

It is the configuration the float decode path implements, and one of those
`wai::jpegai_decode` implements, so the unit tests in `src/jpegai_decode.rs` use it to check
the decoder's scope guard: the unmodified codestream is accepted, and copies with a single
header field changed (β inside and past the encoder's range, `model_id`, the colour
transform, an LSBS flag, display cropping) are accepted or refused as the field asks.
Decoding it to pixels needs the sink-supplied weight bundle, which is not committed;
see `tests/jpegai_e2e_full.rs`.

## `configs/`

The configuration vectors (`tests/jpegai_configs.rs`): synthetic pictures, made from a seed
by `tools/wai_jpegai_make_vectors.py`, coded by the reference software's encoder (its tree at
b0f832cde85bd873fbfa995668b7d7c8d0b0c2fe, BSD licence, Copyright (c) 2010-2022, ITU/ISO/IEC)
at one configuration each with its rate search off, and a few header edits of them, each
named as such. `made.json` says how each was made; `manifest.json`, which
`tools/wai_jpegai_configs.py` writes, gives each one's SHA-256, its scope from the second
header reader (`tools/wai_jpegai_header.py`), and what the exact decoder does with it with the
`jpegai/v1` bundle: the digest and size of the RGB8 it decodes to, or the refusal. Each vector
in scope carries the reference decoder's picture (`<name>.ref.png`, written by the reference
decoder; for no colour transform, the picture it decodes rounded to 8 bits, because its file
writer converts that picture again, [decisions](../../../../decisions.md) D74), and the
manifest how far the exact decode is from it (`apart`). Vectors prefixed `n-` code the same
configurations with eICCI off, because the reference encoder chooses eICCI's model per
picture and the bundle carries one pair; `e-` vectors are header edits. `x-` vectors are
refusal fixtures, header edits of `test256` each setting one field where the decoder stops, so
that every condition of its scope a codestream can fail is caught by a vector
(`wai_jpegai_configs.py --weakened` leaves each condition out of the second reader in turn: 28
of its 29 are caught; the 29th, display cropping removing the whole picture, no codestream in
scope can fail, its sides being at least 128 and the cropping at most 63).

## Decode time, one host's reading

2026-11-12, 09:15 UTC: macOS arm64, a 28-core build host (one-minute load 12.6 at the start,
17.2 at the end), rustc 1.99.1, a release build, `tests/jpegai_configs.rs` with the bundle
loaded once and each picture decoded through the integer operator set on the host's threads,
milliseconds a picture. With eICCI on its three planes, 256 × 256: 931 to 992 (`test256`, the
cropped, colour-0 and eICCI-subset edits of it; on one plane, 973 to 988); with eICCI off,
256 × 256: 319 to 331 (each β, LSBS, RVS, GRFS, post-filter and colour vector), 327 with it on
no plane; 256 × 192 and 192 × 256: 239 and 248 (254 cropped); 192 × 192: 194; 128 × 256 and
256 × 128: 189 and 179; 128 × 128: 106; eICCI on one plane at 192 × 192 and 256 × 192: 541 and
717. The eICCI network, in float, is about two thirds of a 256 × 256 decode. No comparison is
made with any other decoder.