What is still missing?

Render the canvas by default.

Current companion and remaining target: The public companion renders known composited packed images with canvas orientation and required color through Renderer::new(storage).render_first(&mut images). Raw layers use explicit collection selection; the renderer refuses unsupported composition. Default rendering through every codec entry point is not implemented yet. Planar video, HDR display mapping, resizing and complete workspace admission remain separate gates.

The current OpenRequest::new(view, discovery_attempts) requires a view. ImageRequest::new() asks for the whole selected image; in a raw view that may exceed the presentation canvas. Placement::visible() returns matching sample and canvas rectangles but does not change pixels. Native tests include a 1024×576 JXL layer with only a 188×202 visible intersection.

Clipping must happen at the appropriate composition stage, without destroying data required by later references. A smaller layer still renders onto the complete canvas; a fully off-canvas layer is valid, not EOF. Orientation can change the final width and height. Video crop and display resize are separate operations. An output crop must not evade admission of larger coded dependencies.

The naming concern is concrete: ImageGeometry::canvas_width describes the selected image’s local full width, while Placement::canvas is its presentation canvas. Also, with_pixels means packed access; it does not establish display readiness. Track default rendering and its adversarial tests in issue 170.

impl Placement {
    pub fn visible(
        self,
        geometry: ImageGeometry,
    ) -> Result<Option<PlacementOverlap>, PlacementError>;
}

pub struct ImageInterpretation {
    /// Returned stored extent within the selected canvas.
    pub geometry: ImageGeometry,
    /// Selected composited or raw-layer view, when established by the adapter.
    /// The checked collection binds this before publication. `None` makes no
    /// claim; packed storage, placement and dimensions cannot establish it.
    /// Composited samples can still require orientation and color conversion.
    pub composition: Option<crate::collection::Composition>,
    /// Placement on a separate presentation canvas, before orientation.
    /// None means this adapter establishes no separate placement contract.
    /// This does not describe blending or permit discarding off-canvas samples.
    pub placement: Option<Placement>,
    /// None means that this adapter does not establish an orientation contract.
    pub orientation: Option<Orientation>,
    /// Retains native component roles, code depth, siting, crop, color and epoch.
    pub signal: Option<Arc<FrameInterpretation>>,
    /// Original component interpretation after explicit conversion to packed
    /// color. This never describes current packed samples or retains pixels.
    /// Keep it when cloning interpretation for a later crop/color transform;
    /// current geometry, descriptor and context describe the transformed output.
    pub source_frame: Option<Arc<FrameInterpretation>>,
    /// Presentation timing, when established; never inferred from item order.
    pub timing: Option<FrameTiming>,
    /// Native temporal presentation facts, if supplied by a frame adapter.
    pub presentation: Option<Presentation>,
    /// Unmodified source facts, not instructions for interpreting transformed
    /// output and not permission to copy opaque metadata into a derivative.
    pub source_details: crate::Extensions,
}

Canvas geometry now executes in the shared renderer.

The shared zencodec_render::geometry::project implementation accepts a known composited output, applies orientation and selects a display-coordinate region. Omitting the region requests the whole oriented canvas. It refuses raw layers, unknown interpretation and missing source samples before returning an output. Pixels retain their sample bits; the geometry stage does not convert color.

Native TIFF cases cover all eight orientations, Classic TIFF/BigTIFF, partial source regions, RGBA8 and floating-point payloads. Native JXL cases include an independent libjxl orientation comparison and oversized raw-layer refusals. Cancellation, admission failure and unwind controls check that unpublished payload charges are released. Read the qualification receipt.

pub fn project(
    image: &ImageOutput,
    region: Option<Rect>,
    storage: &StorageBudget,
    pulse: Option<&dyn zencodec::Pulse>,
) -> Result<ImageOutput, Cause>;

pub enum AuxiliaryGrid {
    /// Registration has not been established. Equal dimensions do not change it.
    #[default]
    Unknown,
    /// Each auxiliary sample has the same center as the color sample at the
    /// same row and column, throughout the selected stored region. Dimensions
    /// must match color. This describes emitted samples, including any native
    /// upsampling; it does not authorize changing their numerical values.
    ColorSamples,
}

impl<'a> ValueSlice<'a> {
    pub fn new(
        bytes: &'a [u8],
        width: u32,
        height: u32,
        stride: usize,
        channel: ChannelType,
    ) -> Result<Self, At<OutputError>>;

    pub fn with_grid(mut self, grid: AuxiliaryGrid) -> Self;

    pub fn grid(&self) -> AuxiliaryGrid;

    pub fn as_strided_bytes(&self) -> &'a [u8];
}

Requirements from the TIFF parity work

The experiment pins image-tiff main at 10a3b6b2. The spatial gate now passes 136 tests with strict lint, including native old-JPEG consumption controls. Those controls qualify two pinned JPEG layouts and a generated predictor case; they do not establish support for every TIFF variant. Read the native evidence.

The shared walker now follows external JPEG tables (519–521) under scan and extent budgets. Rules::jpeg_table defaults to Unknown, independently of strip and JPEG-stream fate. In a real external-table file, all three table families are read and changing them changes decoded samples. Predictor 65535 is ignored for uncompressed samples but returns UnknownPredictor with LZW.

Read does not mean necessary or private-data-free. A zero-length JPEG stream declaration made the native decoder read an appended opaque tail without changing any pixels. The private adapter can describe that range with Count::ToEnd; it keeps its fate unknown. Whole-stream resource admission and complete zentiff consumer rules remain open. Issue 171 tracks their integration.

pub trait Rules {
    fn jpeg_table(&self, _w: &Walk<'_>, _ifd: &Ifd, _tag: u16) -> Fate;

    fn extents(&self, w: &Walk<'_>, ifd: &Ifd) -> Vec<ExtentRule>;
}

pub enum Count {
    /// Byte counts in this tag, one per offset.
    Tag(u16),
    /// One extent from the first offset to the end of the TIFF.
    ToEnd,
    /// One extent of this many bytes from the first offset.
    Bytes(u64),
    /// A 64-byte old-style JPEG quantization table at each nonzero offset.
    /// Zero means no separate table; repeated offsets may share a table.
    JpegQuantization,
    /// An old-style JPEG Huffman table at each nonzero offset: 16 code-count
    /// bytes followed by their sum in symbol bytes. Reading the counts uses
    /// the walk's scan budget. Zero means no separate table.
    JpegHuffman,
}

Remaining contracts by API

Names below exist today. The final column describes missing behavior, not proposed methods disguised as an implemented API.

Compile time

The measurements below identify their own source revisions. The latest core measurement includes coupled frame conversion and the lossless preference correction. It excludes the TIFF/JXL adapters, codecs and zenpixels-convert, whose complete application build costs remain unqualified.

Exploratory cold-build observations, 2026-10-27. A minimal consumer re-exports zencodec; this does not build codecs, CMS, tests or the site. Each target directory is new, dependencies are prefetched and the OS file cache is warm. Rust 1.99.1, Ryzen 9 7900X, two Cargo jobs, incremental off.

Not a confirmed performance comparison. Zenbench completed 60 interleaved builds with A/A controls and verified uniform CPU-class placement. CPU-load observations exceeded 5% in all 60; 17 had heavy-process observations. No samples were discarded or acceptance gates changed. These medians do not predict a complete application build or incremental rebuild.

Cargo’s zencodec unit median changed from 0.69 to 1.08 s in debug and from 1.25 to 1.98 s in release between main and the review revision. The common dependencies resolve identically; main adds how-far relative to published, and review adds spin. Identifying which APIs account for compiler work still needs profiling.

Resource wrapper: rc=0, 180 s, peak RSS 0.30 GiB, minimum available 11360 MiB, peak load 1.98. This is the whole compile experiment, not codec memory. Method, evidence and reproduction.

Earlier observation and its source revisions.

Core plus I/O and media companions

The newer experiment includes zencodec-io and zencodec-media at review ec5d5089. It still excludes codecs, rendering/CMS and application monomorphization. Main media has no std feature; the review std case includes its new output/staging drivers. This measures the expanded surface rather than identical supported operations.

Exploratory only: 45 interleaved builds with A/A controls; all 45 had CPU-load observations above 5%, and six had heavy-process observations. No observations were discarded. Resource wrapper: rc=0, 157 s, peak RSS 0.30 GiB, minimum available 12552 MiB, peak load 1.56. These are compilation observations, not runtime or codec memory bounds. Complete method, unit timings and retained evidence.