Live data from Hacker News

CPNG, a backwards compatible fork of PNG

richg42.blogspot.com

61–70 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#61
post #47

Earlier quoted context omitted.

Please don't use PNG for photos.

Then what? Jpegs?

(edit: The answer should logically follow from the following, but as a TL;DR: yes, they must have meant jpeg or similar, although I disagree about it being such a "please don't". Feel free to, they'll take more bytes but it's not like you're losing information in the process, so you can always still switch to jpeg.)

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

Re: CPNG, a backwards compatible fork of PNG

#62

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…

GIF had patents from CompuServe, one of the reasons for PNG.

Re: CPNG, a backwards compatible fork of PNG

#64
post #61

Earlier quoted context omitted.

Then what? Jpegs?

(edit: The answer should logically follow from the following, but as a TL;DR: yes, they must have meant jpeg or similar, although I disagree about it being such a "please don't". Feel free to, they'll take more bytes but it's not like you're losing information in the process, so you can always still switch to jpeg.) Photos have lots of noise anyway, so a good jpeg is not going to be the limiting factor. Due to jpeg b…

If I squint hard enough, jpeg starts to look like a very esoteric spin on svg, a quilt of tiny svg-like tiles whose parameters are defined by an encoder analyzing a bitmap rather than a human visualizing a concept.

Re: CPNG, a backwards compatible fork of PNG

#65
post #32

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

Re: CPNG, a backwards compatible fork of PNG

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

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

Less people is actually a very, very good thing in my mind. Twitter is a great example of what happens when too many people are "talking" at once.

Re: CPNG, a backwards compatible fork of PNG

#67

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…

It seems like it’s not going to look broken? Unlike, say, the difference between black & white and color TV, or an animated image that doesn’t animate, it will be a subtle difference that most users won’t notice or care about. Some designers may be annoyed, but it doesn’t seem like that big a deal.

Re: CPNG, a backwards compatible fork of PNG

#68

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…

APNG is extremely well-supported these days: https://caniuse.com/apng

Fun fact: APNG is better supported than JSON.stringify

Re: CPNG, a backwards compatible fork of PNG

#69
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…

I have bad news for you: the existing PNG standard specifies the following optional chunks that compatible renderers are free to follow or ignore, producing different renderings of the same image:

cHRM - Primary chromaticities and white point

gAMA - Image gamma

iCCP - Embedded ICC profile

Post reply on HN