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

31–40 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#31

Post by Dylan16807 »

solardev wrote: post #21
brookst wrote: post #20

Earlier quoted context omitted.

> CPNGs will contain several images inside them 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 instruction…

Sorry, I didn't mean in terms of the codec or data deduplication. You're right, it's probably not implemented as actually having different images in the same file. That would be quite silly. Sorry for my ambiguity. 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…

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.

Re: CPNG, a backwards compatible fork of PNG

#32

Post by chaxor »

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.

Re: CPNG, a backwards compatible fork of PNG

#33

Post by Retr0id »

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 implement "all of PNG" in decoders and encoders. Now, the base PNG spec isn't even that big, but the more you constrain the spec, the easier it is to be sure you've implemented it securely.

* If you're wondering how that works in a backwards-compatible way, DEFLATE already supports uncompressed blocks.

Re: CPNG, a backwards compatible fork of PNG

#34

Post by tetris11 »

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.

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

Re: CPNG, a backwards compatible fork of PNG

#35

Post by layer8 »

edflsafoiewq wrote: post #30
solardev wrote: post #16

Earlier quoted context omitted.

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

The first two extensions (constrained deflate, multithreaded encoding/decoding) only present optimization opportunities for the decoder. It is still the same image. Single-threaded decoding of large PNGs is enough of a bottleneck that Apple has their own version of PNG with multithreading support.

It’s also not really a different format then, just a constrained form of PNG.

Re: CPNG, a backwards compatible fork of PNG

#36

Post by sp332 »

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.

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.

Re: CPNG, a backwards compatible fork of PNG

#37

Post by colejohnson66 »

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.

Re: CPNG, a backwards compatible fork of PNG

#38

Post by solardev »

Dylan16807 wrote: post #31
solardev wrote: post #21

Earlier quoted context omitted.

Sorry, I didn't mean in terms of the codec or data deduplication. You're right, it's probably not implemented as actually having different images in the same file. That would be quite silly. Sorry for my ambiguity. 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…

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 purposefully introducing new features that can only be used in some places, outside of the agreed standard.

Re: CPNG, a backwards compatible fork of PNG

#39

Post by ksec »

solardev wrote: post #29
naikrovek wrote: post #26

Earlier quoted context omitted.

so all image formats should be at version 1.0 and never be improved? come on.

Once stable, yes, absolutely! There should be a reference standard that renderers adhere to. Then they should be versioned for future improvement. That doesn't mean there can't be bug and security fixes, but they should be feature-stable. 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 imag…

>When WebP launched, it was objectively better in most ways compared to both PNG and JPEG,

It was not. Optimised JPEG was on par or sometimes better than WebP.

Re: CPNG, a backwards compatible fork of PNG

#40

Post by solardev »

ksec wrote: post #39
solardev wrote: post #29

Earlier quoted context omitted.

Once stable, yes, absolutely! There should be a reference standard that renderers adhere to. Then they should be versioned for future improvement. That doesn't mean there can't be bug and security fixes, but they should be feature-stable. 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 imag…

>When WebP launched, it was objectively better in most ways compared to both PNG and JPEG, It was not. Optimised JPEG was on par or sometimes better than WebP.

For a given image, that's possible, but if memory serves, the good enough defaults usually led to the WebP version being smaller across a library of image samples, statistically speaking. But that may not have been true for an individual image.

And either format could be manually optimized even more.

Post reply on HN