Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CPNG, a backwards compatible fork of PNG

richg42.blogspot.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#41

Post by cycomanic »

solardev wrote: post #38
Dylan16807 wrote: post #31

Earlier quoted context omitted.

If someone edits a png I expect them to output a new file. So if they use the SDR version as a starting point... they use the SDR version, that's it, nothing else breaks. Everyone sees the same output from Sarah. You can have the same kind of issues with baseline png already; not every tool does all colors or editing effects correctly, and if someone uses a worse tool to edit then that's unfortunate.

Right, but not everyone is going to start from the SDR. Some might have the HDR version and not realize they're destroying the info. It gets worse the more forks and features you have. 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…

Sure there is an advantage, I can put a png file everywhere without needing to care if the users system supports the new capability.

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.

Re: CPNG, a backwards compatible fork of PNG

#42

Post by ksec »

fbdab103 wrote: post #9

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.

>What is the modern power ranking on image formats?

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.

Re: CPNG, a backwards compatible fork of PNG

#43

Post by solardev »

cycomanic wrote: post #41
solardev wrote: post #38

Earlier quoted context omitted.

Right, but not everyone is going to start from the SDR. Some might have the HDR version and not realize they're destroying the info. It gets worse the more forks and features you have. 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…

Sure there is an advantage, I can put a png file everywhere without needing to care if the users system supports the new capability. 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…

What you see as a positive I see as potential for implementation details to diverge and cause user issues. We already have issues with WebP and AVIF rendering in some versions of Safari, and those are well established standards, not a lone wolf extension.

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 :/

Re: CPNG, a backwards compatible fork of PNG

#44

Post by summerlight »

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.

Re: CPNG, a backwards compatible fork of PNG

#45

Post by pwg »

Retr0id wrote: post #33

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 impleme…

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

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.

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

Re: CPNG, a backwards compatible fork of PNG

#46

Post by jjcm »

fbdab103 wrote: post #9

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.

As others have mentioned, the pool is webp, avif, and 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

Re: CPNG, a backwards compatible fork of PNG

#47

Post by Sardtok »

sp332 wrote: post #36
chaxor wrote: post #32

Earlier quoted context omitted.

Maybe this is the genius in it. In order to get everyone to move to better formats, you just break everything in the one everyone uses, so they have to move. Like Twitter becoming X to push everyone to mastodon. Mastodon is better in every way, so it's a net win.

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.

Please don't use PNG for photos.

Re: CPNG, a backwards compatible fork of PNG

#48

Post by bawolff »

chaxor wrote: post #32
solardev wrote: post #13

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 PSD…

Maybe this is the genius in it. In order to get everyone to move to better formats, you just break everything in the one everyone uses, so they have to move. Like Twitter becoming X to push everyone to mastodon. Mastodon is better in every way, so it's a net win.

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

Re: CPNG, a backwards compatible fork of PNG

#49

Post by Sardtok »

cycomanic wrote: post #41
solardev wrote: post #38

Earlier quoted context omitted.

Right, but not everyone is going to start from the SDR. Some might have the HDR version and not realize they're destroying the info. It gets worse the more forks and features you have. 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…

Sure there is an advantage, I can put a png file everywhere without needing to care if the users system supports the new capability. 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…

This is built into HTML, where you can supply multiple files in a srcset.

Re: CPNG, a backwards compatible fork of PNG

#50

Post by Retr0id »

colejohnson66 wrote: post #37
Retr0id wrote: post #33

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 impleme…

BMP already exists for uncompressed bitmap data.

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.

Post reply on HN