Live data from Hacker News

CPNG, a backwards compatible fork of PNG

richg42.blogspot.com

101–110 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#101
post #96
post #57

Earlier quoted context omitted.

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?

This assumes the image is presented in isolation. I’ve seen countless of issues where you place a PNG logo on top of a css background:#123456 and expect the colors to match, so the logo blends in seamlessly to the whole page. On your machine it does and everything looks beautiful. On the customer machine with Internet explorer they don’t, so the logo has an ugly square around it.

The difference in experience for seeing a black or white background instead of a transparant one on the one hand, and missing HDR on the other is pretty big.

95%+ of humans won't even notice HDR being missing. Everyone with eyes will notice a black or white square.

Re: CPNG, a backwards compatible fork of PNG

#103

Earlier quoted context omitted.

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

> Real pixels do hold data, and vectorizing them will typically cause some data loss. Chickens and eggs. If you have vector data already, it's better to distribute the raw vectors than to rasterize them. If you only have raster data, distribute the rasters (where viable) instead of trying to trace them. Lossy operations are lossy. Vectors are largely preferable to rasters, but that doesn't mean you can reproduce them…

> Vectors are largely preferable to rasters

Not for continuous tone images like photographs, they're not. They are excellent however for line art.

Re: CPNG, a backwards compatible fork of PNG

#104
post #102

Earlier quoted context omitted.

If you've seen a video slot machine you've seen APNGs :)

Interesting, why do video slot machines use APNGs?

I don't know for sure but when I used to repair them you could watch them load up the APNGs on boot. The first time I saw them in the wild was around 2007

Re: CPNG, a backwards compatible fork of PNG

#105

Earlier quoted context omitted.

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.

Though doesn't that mean the feature is less likely to be implemented in the first place? Nobody gave a shit about Unicode grapheme clusters until EEMAWDJI came about. Sadly.

What's "EEMAWDJI?" There are no Google search results for that acronym.

Re: CPNG, a backwards compatible fork of PNG

#106
post #101
post #96

Earlier quoted context omitted.

This assumes the image is presented in isolation. I’ve seen countless of issues where you place a PNG logo on top of a css background:#123456 and expect the colors to match, so the logo blends in seamlessly to the whole page. On your machine it does and everything looks beautiful. On the customer machine with Internet explorer they don’t, so the logo has an ugly square around it.

The difference in experience for seeing a black or white background instead of a transparant one on the one hand, and missing HDR on the other is pretty big. 95%+ of humans won't even notice HDR being missing. Everyone with eyes will notice a black or white square.

Nobody said anything about black or white. Try googling for png color problems and you’ll find thousands of questions, in all kinds of tools and browsers. The css color and the png color need to match exactly. Just a slight difference will look off if placed next to each other. The risk of css and png rendering two same hex-codes differently increase when putting semi-supported hdr extensions in the mix.

For this particular use case, yes, transparency is more suitable than trying to match.

Re: CPNG, a backwards compatible fork of PNG

#107
post #103

Earlier quoted context omitted.

> Real pixels do hold data, and vectorizing them will typically cause some data loss. Chickens and eggs. If you have vector data already, it's better to distribute the raw vectors than to rasterize them. If you only have raster data, distribute the rasters (where viable) instead of trying to trace them. Lossy operations are lossy. Vectors are largely preferable to rasters, but that doesn't mean you can reproduce them…

> Vectors are largely preferable to rasters Not for continuous tone images like photographs, they're not. They are excellent however for line art.

If you have vector data already.

Re: CPNG, a backwards compatible fork of PNG

#108
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 would think that something like a bootloader would have fixed input and be able to rely on that, with signing if necessary, rather than the robustness of the decoder. Otherwise, someone who could replace the image would probably be able to replace the code as well.

Without Deflate compression, PNG would have no compression at all, as the predictor mechanism gives no savings on its own. TARGA with RLE would be a better choice than PNG-0.

Re: CPNG, a backwards compatible fork of PNG

#109
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 would think that something like a bootloader would have fixed input and be able to rely on that, with signing if necessary, rather than the robustness of the decoder. Otherwise, someone who could replace the image would probably be able to replace the code as well. Without Deflate compression, PNG would have no compression at all, as the predictor mechanism gives no savings on its own. TARGA with RLE would be a bet…

I thought that too, but then the "LogoFAIL" vulnerabilities came out.[1]

It's possible to define a subset of the deflate bitstream that only does simple RLE compression, and I've done so: https://gist.github.com/DavidBuchanan314/b223bce114ec715a66f...

But, for logo/icon sized bitmaps, you can generally get away without needing compression at all. A 128x128 1bpc image is a mere 2KB.

[1] discussed here https://news.ycombinator.com/item?id=38515571

Post reply on HN