Skip to content

Entropy-coded decoders allocate the pixel buffer from the header before validating the file #670

Description

@lenamonj

Sibling of #669, filed as an issue rather than a pull request because the change alters what the CLI accepts.

The entropy-coded decoders size their pixel buffer from the image header before any pixel data is validated: load_png_with_wuffs allocates from the IHDR dimensions, and load_image_with_stb lets stb_image allocate from the header. A PNG of a few hundred bytes declaring 32768x32768 commits 2 GB of resident memory; a truncated TGA or BMP decodes to an image zero-filled from data the file never held and the CLI exits 0.

A draft patch is on lenamonj/astc-encoder branch decoder-size-bound (applies on top of #669): one helper, image_dimensions_are_credible(filename, file_bytes, dim_x, dim_y), called by the wuffs loader before its allocation and by the stb loader after a header-only stbi_info and before decoding. The bound is 1032 * 8 texels per byte of file, DEFLATE's maximum expansion applied to a 1-bit PNG, the loosest ratio any supported input can reach; baseline JPEG stays under roughly 170, run-length TGA and Radiance HDR under roughly 100, uncompressed payloads at exactly 1. An all-zero 8000x8000 1-bit PNG (7852 bytes) sits one percent inside the bound and loads.

Peak RSS on the crafted files drops from 2.0 GB to about 5 MB, and the truncated TGA and BMP cases exit non-zero instead of producing an image. The change rejects inputs the CLI used to accept, so I would rather you decide whether that bound belongs in astcenc before I open it as a pull request.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions