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

51–60 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#51

Post by Retr0id »

pwg wrote: post #45
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 bit…

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

Re: CPNG, a backwards compatible fork of PNG

#52

Post by namrog84 »

Sardtok wrote: post #47
sp332 wrote: post #36

Earlier quoted context omitted.

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.

Then what? Jpegs?

Re: CPNG, a backwards compatible fork of PNG

#54

Post by cortesoft »

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.

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

Re: CPNG, a backwards compatible fork of PNG

#55

Post by eyegor »

solardev wrote: post #19
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.

AVIF and WebP, two modern replacements for both JPEG and GIF on the web, both support lossy and lossless encoding. 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 anyw…

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

Re: CPNG, a backwards compatible fork of PNG

#56

Post by crq-yml »

hinkley wrote: post #22
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…

PNG was always set up for extension. In particular, it has a clever way of allowing ancillary data sections to be marked as unimportant, so a decoder knows whether it can skip them or report the file as unreadable. I suspect the big thing these days would be to support brotli and zstd.

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.

Re: CPNG, a backwards compatible fork of PNG

#57

Post by sspiff »

solardev wrote: post #24
hinkley wrote: post #22

Earlier quoted context omitted.

PNG was always set up for extension. In particular, it has a clever way of allowing ancillary data sections to be marked as unimportant, so a decoder knows whether it can skip them or report the file as unreadable. I suspect the big thing these days would be to support brotli and zstd.

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.

I would say at least in the context of extra data to extend the bit depth for HDR, that data could be considered ancillary?

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?

Re: CPNG, a backwards compatible fork of PNG

#58

Post by eyegor »

jjcm wrote: post #46
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

What about mozjpeg?

Re: CPNG, a backwards compatible fork of PNG

#60

Post by sroussey »

Sardtok wrote: post #49
cycomanic wrote: post #41

Earlier quoted context omitted.

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.

Does srcset have a mechanism for SDR vs HDR?
Post reply on HN