Live data from Hacker News

CPNG, a backwards compatible fork of PNG

richg42.blogspot.com

71–80 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#71
post #47

Earlier quoted context omitted.

Please don't use PNG for photos.

Then what? Jpegs?

For redistribution, JPEG or AVIF or WebP. I'd choose JPEG myself... good enough compression with broad compatibility. You'll almost never run into an issue with it. AVIF and WebP are still full of gotchas, so I wouldn't deploy them without a JPEG fallback.

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.

Re: CPNG, a backwards compatible fork of PNG

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

Minor nitpick, just for clarity: Vectors aren't really the "ultimate" format, they're just a different format for storing a different kind of information.

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.

Re: CPNG, a backwards compatible fork of PNG

#73

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…

> these days, generating or decoding PNGs is the bottleneck almost nowhere

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

Re: CPNG, a backwards compatible fork of PNG

#74

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

And yet I have yet to see one in the wild. It's all WebM and Gifs these days.

Re: CPNG, a backwards compatible fork of PNG

#75
post #61

Earlier quoted context omitted.

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

Wow, you’re really good at squinting!

Re: CPNG, a backwards compatible fork of PNG

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

> screenshots

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.

Re: CPNG, a backwards compatible fork of PNG

#78

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…

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

GIF uses LZW compression which was patented by Unisys.

Re: CPNG, a backwards compatible fork of PNG

#79

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…

> I would bet that these days, generating or decoding PNGs is the bottleneck almost nowhere

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)

Re: CPNG, a backwards compatible fork of PNG

#80
post #8
post #6

How this compares to WebP?

I didn't even realize that WebP had an optional lossless compression mode.

WebP's lossless compression mode usually beats PNG by a lot, and even decompresses faster. I consider lossless WebP to completely obsolete PNG. Lossless JXL often beats WebP in compression, but loses in decompression time.

Except for indexed color images. PNG beats WebP on those images. Meanwhile JXL beats PNG on indexed color images.

Post reply on HN