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?
I suspect the big thing these days would be to support brotli and zstd.
So there will be formats that can reorder the chunks, and those minimum-viable readers will all break when they encounter a file from a different source, because they hardcoded a read order. This leads to an experience on the user's end where they need a "fixer" tool to reorder it to deal with the bad decoder.
There were tons of old binary formats that were like this. It can happen with text, but it's less likely to, because a larger proportion of textual formats build over a container like XML or JSON to offload the text parsing, and then they end up with some pre-structured data.
It's dangerous to use this to change the actual primary output of the file (the image), especially in a way that users and editors can't easily detect.
Fun fact: APNG is better supported than JSON.stringify
The bulk of my game's startup time is spent decoding PNGs via libpng. There are some alternatives to libpng like fpng[1], or alternate image formats like QOI[2]
These both exist because png is slow and/or complicated.
[1] https://github.com/richgel999/fpng [2] https://github.com/phoboslab/qoi (discussed here: https://news.ycombinator.com/item?id=29661498)
Anecdotal, but I'm familiar with a system which spends ~50% of CPU cycles on PNG encoding (most of which is actually spent in zlib compression).
The other approaches I've seen involve creating performance-focused forks of zlib (e.g. zlib-chromium and zlib-cloudflare). This has benefits beyond PNG encode / decode:
https://aws.amazon.com/blogs/opensource/improving-zlib-cloud...
Like Twitter becoming X to push everyone to mastodon. Mastodon is better in every way, so it's a net win.
We might wish this to be true, but it isn't. There are more people on Twitter/X, which is the most important part of a social network.
Making easily disprovable statements is not the way to win people to your side.
Searchability is weaker. Login is all over the map. Links don't work. etc.
These are the standard problems with non-centralized software.
I really don't understand why Mastodon didn't use/create something like the "magnet" links used for torrents. That way, even if you lost the server, as long as you touched something that had the appropriate hashes, you can access the information.
I use Mastodon, but it is not better in every way.
Nobody gave a shit about Unicode grapheme clusters until EEMAWDJI came about. Sadly.
From the article:
> [...] like how color TV was introduced but it still worked on B&W TV's. New features can be added, as long as existing decoders ignore them and return a viewable image
Keyword "ignore them". To my reading, this means that CPNGs will contain several images inside them: A full-featured version with "color" (or HDR, or or whatever) for newer renderers, and a fallback one (in "black and white" in his example) for existing renderers.
It's not really "backward compatible", but more like "fallback-able".
Don't forget pixel aspect ratio. Oh wait, most viewers still ignore that.
What a brilliant paragraph. I wish this developer all the success in the world.
Otherwise there is no way to sunset the hacks.
The world needs more work like this. I’m talking about the thoughtful image format but also that applies to the write up too.
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.
WebP is mature and has more browser support, but AVIF is getting there (notably only lacking Edge support). Both can compress in either a lossy JPEG-like fashion or in a lossless PNG-like fashion.
If you use a image CDN like Imgix, it'll just auto-detect and serve whatever the most optimal format is anyway: https://docs.imgix.com/apis/rendering/auto/auto#format. Cloudinary too: https://cloudinary.com/documentation/image_optimization#how_...
For non-web, there's also JPEG XL to look at, but if you're not doing rendering an image for redistribution, it's probably better to keep it as raw as possible anyway (i.e. camera raw images plus photoshop layers, or whatever).
HEIC is also a video codec at heart but has a default color space that also isn’t sRGB (which is a good thing; it’s about time we moved on), untagged HEIC images can (though often aren’t in any default workflow) be assigned Display P3. Assigning/assuming sRGB will absolutely break your images, of course.
https://winaero.com/avif-support-is-now-available-in-microso...
I will assume this can be outside the web and consider only image format / codec that is state of the art.
>For lossless, what is typically the most efficient size wise? Decompression speed?
In terms of lossless, JPEG-XL is the one to look at. Both in terms of size and decompression speed. You will already see communities from professional photographers using this format.
>For lossy?
That depends on what sort of quality you are looking for. In some edge cases you could have JPEG XL being better at ultra low bit per pixel, like 0.1 bpp. Otherwise in 95% of cases, at 0.1 bpp to 0.5 bpp, it is HEIF / AVIF. HEIF based on VVC / H.266 Encoder likely to be the state of the art. With current reference FVC / H.267 implementation bringing another 10 - 30% improvement.
However the higher the quality you go, i.e 0.8 to 1.5 bpp, the more favourable to JPEG XL.
If you’re building something today, webp likely has the best tradeoff of encoding speed, efficiency, and compatibility.
For pure tiering, here’s how I’d rank them:
*Efficiency:*
Webp: B tier
AVIF: A tier
JXL: S tier
*Encoding Speed:*
Webp: B tier
AVIF: D tier
JXL: A tier
*Compatibility*
Webp: A tier
AVIF: B tier
JXL: D tier
* If you're wondering how that works in a backwards-compatible way, DEFLATE already supports uncompressed blocks.
Look at the NetPBM formats (PPM, PGM, PGM). They are about as simple as they can possibly get (a tiny, ASCII, header, followed by binary bitmap data), and are also uncompressed.
i.e. you'd still want to pick a subset to implement. To be honest, you're probably right - BMP would be more sensible starting point, but I'm interested to see how far PNG can be pushed.
http://public-domain.advel.cz/
It contains various implementations of the compression, from simple uncompresssed to more complex variants and a quite small PNG loader. There is also a minimalistic PNG writer with uncompressed data.
Without Deflate compression, PNG would have no compression at all, as the predictor mechanism gives no savings on its own. TARGA with RLE would be a better choice than PNG-0.
It's possible to define a subset of the deflate bitstream that only does simple RLE compression, and I've done so: https://gist.github.com/DavidBuchanan314/b223bce114ec715a66f...
But, for logo/icon sized bitmaps, you can generally get away without needing compression at all. A 128x128 1bpc image is a mere 2KB.
[1] discussed here https://news.ycombinator.com/item?id=38515571
seems like the downside is that this is "worse than nothing" compression, the image file would be bigger than the original blit of the data. for example 1024x1024x32bit color means 3 megabytes for one image. or do i miss something?
Your math is a bit off - a 1024x1024 at 32bpp would be 4MB, ignoring overhead.
I've actually done something like this in the past - create PNGs with 0 compression, then compress it with something stronger than Deflate (like LZMA). Because the PNG filtering is still applied, this allows greater compression relative to PNG by itself (or a BMP compressed with LZMA).
> for example 1024x1024x32bit color means 3 megabytes for one image.
You do miss something, that's 4 megabytes, plus any header/format overhead - but you'd get similar performance out of any uncompressed format, that's just the tradeoff.
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?
Also speaks to either wise or lucky design of PNG itself, that it can support these kinds of backwards-compatible extensions.
Could you do an image of SBF that falls back to an image of Madoff?
Except for indexed color images. PNG beats WebP on those images. Meanwhile JXL beats PNG on indexed color images.
