A problem that often comes up with extensible formats is that whomever comes along and implements them assumes exactly the test cases they came up with, which can often mean "just the files I have for this project" or "just the output of the encoder I have".

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.

Many formats have stuff like that (like cover art in MP3 ID3 tags), but usually they're used for, well, ancillary purposes.

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.

You could add an "ignorable" zstd-compressed IDAT variant, but that wouldn't give you backwards-compat in any useful way - the zlib-compressed IDAT still has to be present, and unless you fill it full of zeroes or a placeholder image, the overall file is going to be larger.

And yet I have yet to see one in the wild. It's all WebM and Gifs these days.

Most games ship textures in a GPU-friendly format such as DXT to avoid problems like this.

Why not use fpnge?

But most people didn’t move to Mastodon, and a bunch moved to incompatible networks like Bluesky, cohost, etc. Which is really the kind of problem you don’t want to have when you're just posting a photo.

> Mastodon is better in every way

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.

I think idiocy and short-term self-interest is more at play here, than any 4D chess shenanigans.

Embrace, extend, extinguish. Not just for microsoft anymore!

> Mastodon is better in every way, so it's a net win.

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.

Though doesn't that mean the feature is less likely to be implemented in the first place?

Nobody gave a shit about Unicode grapheme clusters until EEMAWDJI came about. Sadly.

Sorry, but did you read my post? It's only backward-compatible in the sense that existing renderers can display SOMETHING -- but it's not the same image.

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".

They should just make a new format. It's not clear if this is an improvement over AVIF either.

We've already got JPEG-XL as a good replacement format, but some feel that jeopardizing its adoption is a sensible cause.

WebP and AVIIF (and, to a much lesser extent, HEIC, which AVIF is basically a rip off of) absolutely suck for color management since they are a) virtually never original source formats, b) are video codecs. WebP technically supports two different color profile techniques (traditional embedded ICC - broken in every mainstream batch image processor I’ve tried - and nlx video-based color profiles). Unlike WebP and all the other image formats, untagged AVIF can’t be assumed to be sRGB (in part because there is no actual sRGB for video, though close variants exist) and every image processor or image editor will open it with a different base color profile assigned. WebP doesn’t even support exif, making it absolutely horrible for “lossless” operations that effectively aren’t lossless since they necessarily destroy metadata.

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.

The worst part about avif support in edge is it was added as an optional feature flag ~8 months ago but it still isn't enabled as a default. Nearly every other browser supports avif by default these days.

https://winaero.com/avif-support-is-now-available-in-microso...

What about mozjpeg?

They're simple, but they're nowhere near as widely supported as PNG (or BMP)

This is true, but BMP became a bit of a kitchen-sink format, supporting all sorts of pixel formats, and optionally, compression.

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.

I thought that too, but then the "LogoFAIL" vulnerabilities came out.[1]

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

Many PNG compressors allow you to specify the zlib compression level, where 0 = no compression. This will effectively give you an uncompressed image, perhaps with some format overhead.

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).

There's no need to take anyone else's code, emitting uncompressed DEFLATE blocks is trivial. I'm not sure what you mean by garbage?

> 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.

's a joke

WebP's lossless compression mode usually beats PNG by a lot, and even decompresses faster. I consider lossless WebP to completely obsolete PNG. Lossless JXL often beats WebP in compression, but loses in decompression time.

Except for indexed color images. PNG beats WebP on those images. Meanwhile JXL beats PNG on indexed color images.