CPNG, a backwards compatible fork of PNG

Original Article ↗ Hacker News Discussion ↗

A proposed “compatible” fork of the PNG image format, CPNG, aims to add features like faster encoding/decoding and HDR support while remaining fully viewable in existing PNG decoders. Commenters praise the backwards-compatible approach for instant ecosystem support but question whether extending a 30-year-old format risks fragmentation, subtle rendering differences, and new security issues. Many compare CPNG to modern formats such as WebP, AVIF, and JPEG XL, debating whether incremental improvements to PNG are worthwhile versus investing in newer, more efficient standards.

Motivation and Concept of CPNG

  • Many commenters like the idea of extending PNG in a fully backward-compatible way so existing browsers and OSes can display at least a baseline image.
  • CPNG is described as reinterpreting PNG when certain conditions are met, leveraging PNG’s chunk-based, extensible design.
  • Some see this as a smart, pragmatic way to innovate without the deployment issues of a brand‑new format.

Backward Compatibility vs. Fragmentation

  • One debate centers on what “100% backward compatible” really means:
    • Supporters: old decoders still see a valid PNG; newer decoders can add HDR or other features using extra data.
    • Skeptics: output images may differ between decoders (e.g., HDR vs SDR), which they see as “fallback” rather than true compatibility.
  • Concern: over time this could create a “family” of PNG variants where images look different across tools and platforms, echoing early PNG alpha issues, APNG, PSD/SVG inconsistencies.
  • Others counter that PNG already has optional chunks (gamma, ICC profiles, etc.) that decoders may ignore, and that evolution of formats is inevitable.

Performance and Compression

  • Several comments highlight that PNG encode/decode (especially zlib/DEFLATE) can be a real CPU bottleneck in games and servers.
  • CPNG’s constrained DEFLATE and multithreaded decoding are seen as valuable optimizations; questions remain about file size impact and read performance on legacy decoders (left mostly unanswered).
  • Related discussion touches on alternatives and optimizations: fpng, QOI, zlib forks (Cloudflare, chromium), and GPU‑friendly texture formats.

Comparison to Other Image Formats

  • Some ask why not just use newer formats like WebP, AVIF, or especially JPEG XL, which multiple commenters rank highly for lossless compression and/or efficiency.
  • One summary ranking:
    • Efficiency: WebP (B), AVIF (A), JXL (S).
    • Encoding speed: WebP (B), AVIF (D), JXL (A).
    • Compatibility: WebP (A), AVIF (B), JXL (D).
  • Color management and metadata problems with WebP/AVIF/HEIC are highlighted; PNG remains attractive for reliability.

Alternative “Backwards-Compatible” Ideas and Security

  • Some propose a restricted or uncompressed subset of PNG for simple or embedded systems, using only uncompressed DEFLATE blocks; others suggest BMP or NetPBM as simpler baselines.
  • There is a brief warning that more complexity in PNG‑like formats can introduce new security vulnerabilities (e.g., boot logo issues such as “LogoFAIL”).

Adoption Prospects

  • Opinions are split: some doubt CPNG will gain traction if APNG struggled; others note APNG is actually widely supported now, even if rarely used.
  • Overall, the thread mixes strong enthusiasm for the hack with substantial concern about long‑term ecosystem complexity.