Image Format and Safety

The `csk.lispex-image/v1` format turns bounded source bytes into one canonical PNG or a canonical ZIP of ordered PNG pages. The decoder returns source only after every structural, integrity, parity, and regeneration check succeeds.

This page describes v1.13. Verify whether it is the current manual at /version.json

How to reason about it

  • The format pins its image, inspection, profile, and codebook tags; 1304-pixel width; palette; page geometry; fixed-Huffman PNG encoding; stored ZIP grammar; page order; and manifest bytes.
  • Inputs are bounded to 1 MiB of source, 16,384 reader nodes, reader depth 256, and 32 pages; malformed length and offset fields are rejected before unsafe allocation.
  • Inspection exposes format/profile identifiers, page count, exact source length and identity, plus projection, Core, payload, page-set, and per-page commitments.
  • Reed–Solomon parity detects changed payload symbols but performs no repair. A valid payload must also regenerate to exactly the supplied PNG or ZIP bytes.
  • The round-trip laws are decode(encode(source)) = source and encode(decode(image)) = image for every accepted image.

A common mistake

Canonicality proves only that the bytes are one exact Lispex Image representation. Source identity, signatures, trust policy, request binding, Native re-execution, and a local gate remain separate boundaries.

Current boundaries

  • Do not infer watermarking, steganography resistance, visual robustness, error correction, confidentiality, authorship, or malicious-code safety from a valid image.

Keep going

Use this page while writing code. For a guided explanation, return to the syntax map or the corresponding manual.

Syntax at a Glance · Learning Path