CPNG, a backwards compatible fork of PNG
richg42.blogspot.com
richg42.blogspot.com
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?
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".
That was not my read. When discussing HDR it’s clear that ONLY the extra bits are stored in a new data structure and are applied to the base image at display time.
So that gets you a bit-for-bit compatible image on old systems and HDR on new systems without duplicating data.
I believe that pattern applies throughout: a baseline, standard PNG image plus extra instructions and data for adding information to it.
But functionally, this means that two renderers would have different outputs for the same file. It's not so bad when it's just HDR, but if this continues to grow, it WILL get bad. We've seen it many, many times before with hacked-on file extensions.
If it were Microsoft doing this (it's not), it would be just yet another embrace-extend-extinguish effort. But it's not. I have no doubt this author has good intentions, and this is a cool hack, but I think it will lead to confusion and poor outcomes in widespread usage.
It's really not great when an image format looks "somewhat" the same between renderers. In fact, I think that's worse than it not working at all. From experience, it leads to these situations where the same image can fragment over time just by virtue of being worked on by different people in different environments (apps, OSes, browsers, devices), and there's not really a clear way to tell which is which without extensively analyzing the metadata.
If Joe starts work on a HDR version, sends it to Sarah, Sarah adds a bunch of new edits but then saves it in an app that recompresses the image and overwrites the HDR, Joe might never know. And then if the format continues to expand, maybe a bit later Jane and Janet each add mutually incompatible extensions to the file without knowing it. The "base" image might look the same to all of these people, but each had specific edits in mind that the others might not have known about, because their renderers LOOKED like it was rendering the same image when it wasn't.
This isn't a hypothetical... it happened a lot when PNG first came out, and with PSD (Photoshop files) for a good decade or two until the subscription model came out.
There's a reason why JPEG and PNG are so popular: because they ARE stable and unchanging, in a world of failed adoption for APNG, WebP, HVEC, JPEG 2000, JPEG XL, AVIF, etc.
For image formats, broad compatibility is way way way more important than small gains in codec performance and filesize.
----
Edit: From memory, this is something we learned the hard way back in the 90s and early 2000s, when image (and other) formats saw very rapid development and bandwidth was still hard to get. PNG was a huge improvement over GIF, and that mattered a lot over 56k modems. But the road to its adoption was very difficult, with many features only partially supported for years in different apps.
When WebP launched, it was objectively better in most ways compared to both PNG and JPEG, but it still saw limited uptake. Part of that was the titans fighting amongst themselves (other tech companies didn't want to adopt a Google format), but also by that point both JPEG and PNG were good enough and connections & CPUs were good enough. The incremental improvement it offered rarely justified it sometimes not working for some users on some browsers.
It's a similar situation for many other formats: H.264 in a MP4 is good enough, MP3s are still good enough, etc. On the other hand, PDFs and DOC/DOCX have different features depending on what reader you use (such as PDF forms, JS validation, accessibility, or DOCX not rendering the same on different readers), and it's a mess.
It was not. Optimised JPEG was on par or sometimes better than WebP.
And either format could be manually optimized even more.
PNG is on version 1.2
There's just no advantage in overloading an old graphics format for something like this in a world where WebP and AVIF already exist.
As for editing tools, at least they're targeting the same baseline format (maybe with bugs). This is purposefully introducing new features that can only be used in some places, outside of the agreed standard.
For a (made up) example let's say Firefox supports hdr, but Chrome doesn't, if I want to include an HDR image into a website, but display a SDR image if the browser can't display it, I need to implement a test for the browser to serve decide if I serve a WebP or PNG. That is a real cost.
In theory an extended hacked PNG would have perfect backward compatibility, but the complexities of codecs more likely means it's going to appear as bugs in several implementations. Best case it falls back to SDR, but it's also possible some broken implementation leads to HDR content being displayed in a SDR setup and everything getting all washed out.
Having the same file format/extension actually host several different versions never works well. Graphic artists and support teams have to deal with rendering quirks like this all the time because some developer thought their hack was a genius overload :/
And webp doesn’t support HDR at all.
cHRM - Primary chromaticities and white point
gAMA - Image gamma
iCCP - Embedded ICC profile
Single-threaded decoding of large PNGs is enough of a bottleneck that Apple has their own version of PNG with multithreading support.
I suspect the big thing these days would be to support brotli and zstd.
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.
We've been rendering images in SDR forever, and most people don't have HDR capable hardware or software yet, so I don't know how you could consider it as broken to render the image without the HDR data?
I’ve seen countless of issues where you place a PNG logo on top of a css background:#123456 and expect the colors to match, so the logo blends in seamlessly to the whole page.
On your machine it does and everything looks beautiful. On the customer machine with Internet explorer they don’t, so the logo has an ugly square around it.
95%+ of humans won't even notice HDR being missing. Everyone with eyes will notice a black or white square.
For this particular use case, yes, transparency is more suitable than trying to match.
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.
Note that PNG also "build[s] over a container", since it's a descendant of IFF.
Like Twitter becoming X to push everyone to mastodon. Mastodon is better in every way, so it's a net win.
Joint Photographic Experts Group
vs
Portable Network Graphics
Photos have lots of noise anyway, so a good jpeg is not going to be the limiting factor. Due to jpeg being lossy, the file size is much smaller for the type of images that pictures are (I don't know a formal definition, perhaps something with some amount of random noise? Or that there's lots of gradients with nonlinear slopes or so?).
PNGs are lossless, and encoding photos in a lossless way takes a relatively large amount of space. On the other hand, the quality degradation of running text through a jpeg encoder is noticeable even when tuning the jpeg compressor for it, so a screenshot with text is always PNG. For designed things such as icons or logos or so, the file size is small enough to be a no-brainer for getting PNG's lossless quality.
Vector, such as SVG, is the ultimate format: the highest possible quality and also the smallest! This only works when you've got access to the source (screenshots already don't work because you're capturing a blend of objects rendered as an array of pixels), and especially not suitable/possible when you're reading from a sensor such as a digital camera. This format doesn't describe pixel patterns, but rather shapes such as "draw a red line from coordinates 3,94 to 1920,1027". Because you can't always use it (you can always render an SVG as a grid of pixels and turn it into a PNG or anything else, but not the other way around), support is a bit lower and you'll see them less often, but imo it's always worth striving for when the platform allows
Vectors are good for things that can be mathematically described/simplified without significant loss of information (such as curves, shapes, some gradients, etc., and compositions of those) Many logos and fonts fall into this category, for example, and some clip-art do as well. For the appropriate graphics, vectors can give you higher quality and smaller file sizes. But it's not necessarily the right choice for everything. Real pixels do hold data, and vectorizing them will typically cause some data loss. You COULD vectorize photos and illustrations (vectormagic.com is a good one for that). But you just end up with a poorer approximation of the original raster data, ending up with a bunch of pixel-like polygons, because there's not really a better approximation of that high-resolution pixel data that can be easily described in shapes and lines.
Rasters are still superior not only for photographs, but for other uses outside of basic image redistribution, such as GIS data layers (where sensor data IS what's important), bump maps and terrain maps for games, 3D voxel images for medical imaging, live-action movies (which can interpolate complex scenes between raster frames), astronomy, etc. Even if you could vectorize the sensor data in those situations, you often wouldn't/shouldn't.
Chickens and eggs. If you have vector data already, it's better to distribute the raw vectors than to rasterize them. If you only have raster data, distribute the rasters (where viable) instead of trying to trace them. Lossy operations are lossy.
Vectors are largely preferable to rasters, but that doesn't mean you can reproduce them if you only have the rasters. Just like distributing source code is usually preferable to compiled binaries, but that doesn't mean that we just pump everything through Ghidra and call it a day.
Not for continuous tone images like photographs, they're not. They are excellent however for line art.
For browsers, there are extensions that can create SVG screenshots. They work by either copying or inlining CSS into the SVG. They don't work all the time, but worth giving a try first.
For Firefox, see https://addons.mozilla.org/en-US/firefox/addon/svg-screensho..., it worked relatively well for me.
The author also wrote the accompanying library, dom-to-svg: https://github.com/felixfbecker/dom-to-svg
It seems to capture the HTML and convert each element to a similar one on SVG. I'm still not sure how it handles raster images (does it just embed them? Vectorize them somehow?) but it's a really cool project. Thanks for sharing!
For sharing masters/originals, it just depends on your team's needs. Probably saving the camera RAW is a good idea, but usually there's been edits done to it, so some Photoshop or Lightroom native format, for example, or at least a TIFF if you need broader compatibility.
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.
Fun fact: APNG is better supported than JSON.stringify
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...
Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
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)
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).
https://winaero.com/avif-support-is-now-available-in-microso...
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.
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.
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.
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.
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).
In such a case, you could also skip the PNG filtering as well (whilst for my case, you wouldn't want to).
I think it'd make more sense to go with BMP for a 'simple as possible' image format, that has wide support, than with PNG. PNG is definitely more geared towards a compressed image (as well as all sorts of other features you may not care about).
> 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.
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
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.