from Hacker News

CPNG, a backwards compatible fork of PNG

by dirkf on 12/7/23, 8:47 AM with 120 comments

• by solardev on 12/9/23, 5:42 PM

  What happens if this actually picks up steam, and suddenly PNG is no longer one format, but a bunch of incompatible ones that look somewhat similar, whose fidelity depends on your renderer?

  Early in PNG's history, we already had this issue with alpha channels, progressive rendering, and hit-or-miss support for APNG (animated PNGs, meant to replace GIFs but never happened).

  It was also an issue for a long time for PSDs and SVGs, where the same file never looked the same on two browsers/devices/apps/versions.

  I would bet that these days, generating or decoding PNGs is the bottleneck almost nowhere, but extending the format would cause problems everywhere in real-world usage. Apps and companies can no longer tell whether there's something wrong with their image or if somewhere in the pipeline, some new graphics designer decided to use a bleeding-edge version of a 30-year-old graphics format that nobody else accounted for, and it looks "broken" in half the browsers now. A format can still look broken even if it's "backward compatible", just by virtue of having some features (like HDR) that are only displayable in some renderers but not others.

  Why not just make a new format instead and have browsers & devices fall back as necessary, like we already do with webp and srcsets?

• by ebb_earl_co on 12/9/23, 4:07 PM

  > Why continue messing with PNG at all? Because if you can figure out how to squeeze new features into PNG in a backwards compatible way, it's instantly compatible with all browsers, OS's, engines, etc. This is valuable

  What a brilliant paragraph. I wish this developer all the success in the world.

• by Voultapher on 12/9/23, 4:37 PM

  That's really cool! I stumbled across libpng being 10+x slower to encode than jpg and tiff at work. The LOGLUV32 part is very clever. I particularly like the tonemapped fallback and general idea to build on top instead of reinventing. That said I hope these format extensions don't end up in compatibility hell, where viewing the full info image is hit or miss between different CPNG decoders.

• by gumby on 12/9/23, 5:33 PM

  I loved reading this even though I personally have zero need myself. I enjoyed the rationale and he engineering.

  The world needs more work like this. I’m talking about the thoughtful image format but also that applies to the write up too.

• by fbdab103 on 12/9/23, 5:29 PM

  What is the modern power ranking on image formats?

  For lossless, what is typically the most efficient size wise? Decompression speed?

  For lossy?

  I am not in a situation where these micro-optimizations mean much to me, and always default to png, but curious to know where the state of the art is today.

• by summerlight on 12/9/23, 8:10 PM

  What does it exactly mean by "100% backward compatible"? It looks like some optimizations could be backported to the existing encoder/decoder without breaking the format but this is more of an optimization. My impression is that this is backward compatible in a way similar to APNG (it will return some reasonable images if the file is using a new functionality), but I'm not sure if I understand it correctly.

• by Retr0id on 12/9/23, 6:35 PM

  I've also been pondering a backwards-compatible fork of PNG - but rather than a fork, mine would be a subset. Specifically, it would be an as-simple-as-possible uncompressed* bitmap format, suitable for use in low-complexity embedded systems etc. (e.g. bootloaders, wink wink). By being backwards compatible, you get the added benefit of retaining compatibility with existing image viewers, but without having to implement "all of PNG" in decoders and encoders. Now, the base PNG spec isn't even that big, but the more you constrain the spec, the easier it is to be sure you've implemented it securely.

  * If you're wondering how that works in a backwards-compatible way, DEFLATE already supports uncompressed blocks.

• by tedunangst on 12/9/23, 9:45 PM

  No mention of JPEG XT or JPEG-HDR?

  https://en.wikipedia.org/wiki/JPEG_XT

• by notfed on 12/9/23, 5:00 PM

  This sounds pretty amazing.

  For CPNG-aware libraries, the performance improvements sound impressive.

  For old (CPNG-unaware) libraries: should I expect any performance drop reading a CPNG image compared to if the image had remained PNG? Similarly, how much larger will a CPNG be than a PNG?

• by TheFuzzball on 12/9/23, 6:12 PM

  Maybe next we'll get eXtensible Compatible Network Graphics: XCPNG

• by brookst on 12/9/23, 4:18 PM

  Very cool, and I hope it sees adoption.

  Also speaks to either wise or lucky design of PNG itself, that it can support these kinds of backwards-compatible extensions.

• by ericskiff on 12/9/23, 4:15 PM

  This is wonderful. What a great way to continue innovation without facing the adoption hurdles of a new format

• by jancsika on 12/9/23, 6:16 PM

  How different can the fallback be?

  Could you do an image of SBF that falls back to an image of Madoff?

• by ComputerGuru on 12/10/23, 4:57 AM

  There’s no mention of what effect these changes have on file size. It seems to me all the non-HDR changes will blow up file sizes for all but the largest of images.

• by snshn on 12/10/23, 3:02 AM

  If APNG couldn't pick up steam and get widespread adoption, not sure how this will. But hopefully I'm wrong.

• by vzaliva on 12/9/23, 4:54 PM

  How this compares to WebP?

• by jbverschoor on 12/9/23, 6:04 PM

  Why not just invest in jxl

• by Exoristos on 12/10/23, 6:32 AM

  Seeping?

• by topsycatt on 12/9/23, 5:33 PM

  If only it was called GNP...

• by phront on 12/10/23, 12:30 AM

  meet a new bunch of security holes