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

91–100 of 122 posts

Re: CPNG, a backwards compatible fork of PNG

#91

Post by Nyan »

gred wrote: post #73
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…

> 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/o…

Why not use fpnge?

Re: CPNG, a backwards compatible fork of PNG

#92

Post by Nyan »

unconed wrote: post #14
ebb_earl_co wrote: post #2

> Why continue messing with PNG at all? Because if you can figure out how to squeeze new features into PNG in a backwards compatible way, it's instantly compatible with all browsers, OS's, engines, etc. This is valuable What a brilliant paragraph. I wish this developer all the success in the world.

The backwards compatibility is okay, but the author should also plan a more optimal replacement encoding that ditches the legacy compatibility, and require new implementations to support both. Otherwise there is no way to sunset the hacks.

We've already got JPEG-XL as a good replacement format, but some feel that jeopardizing its adoption is a sensible cause.

Re: CPNG, a backwards compatible fork of PNG

#94

Post by RaisingSpear »

doubloon wrote: post #89
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…

ok thats pretty wild, you would take the zlib deflate/inflate code, (for example in a library like lodepng) and then like chunk 95% of it in the garbage? so basically every block would just be uncompressed? kind of funny but it would probably work pretty well and your code size could get down way way smaller than the current typical png code. seems like the downside is that this is "worse than nothing" compression, t…

Many PNG compressors allow you to specify the zlib compression level, where 0 = no compression. This will effectively give you an uncompressed image, perhaps with some format overhead.

Your math is a bit off - a 1024x1024 at 32bpp would be 4MB, ignoring overhead.

I've actually done something like this in the past - create PNGs with 0 compression, then compress it with something stronger than Deflate (like LZMA). Because the PNG filtering is still applied, this allows greater compression relative to PNG by itself (or a BMP compressed with LZMA).

Re: CPNG, a backwards compatible fork of PNG

#95

Post by jezek2 »

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…

You may want to look at my PNG/DEFLATE implementation:

http://public-domain.advel.cz/

It contains various implementations of the compression, from simple uncompresssed to more complex variants and a quite small PNG loader. There is also a minimalistic PNG writer with uncompressed data.

Re: CPNG, a backwards compatible fork of PNG

#96

Post by Too »

sspiff wrote: post #57
solardev wrote: post #24

Earlier quoted context omitted.

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?

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.

Re: CPNG, a backwards compatible fork of PNG

#97

Post by pwdisswordfishc »

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…

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

Don't forget pixel aspect ratio. Oh wait, most viewers still ignore that.

Re: CPNG, a backwards compatible fork of PNG

#98

Post by pwdisswordfishc »

skybrian wrote: post #67
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…

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.

Re: CPNG, a backwards compatible fork of PNG

#99

Post by doophus »

smcameron wrote: post #79
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…

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

Most games ship textures in a GPU-friendly format such as DXT to avoid problems like this.

Re: CPNG, a backwards compatible fork of PNG

#100

Post by Retr0id »

doubloon wrote: post #89
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…

ok thats pretty wild, you would take the zlib deflate/inflate code, (for example in a library like lodepng) and then like chunk 95% of it in the garbage? so basically every block would just be uncompressed? kind of funny but it would probably work pretty well and your code size could get down way way smaller than the current typical png code. seems like the downside is that this is "worse than nothing" compression, t…

There's no need to take anyone else's code, emitting uncompressed DEFLATE blocks is trivial. I'm not sure what you mean by garbage?

> for example 1024x1024x32bit color means 3 megabytes for one image.

You do miss something, that's 4 megabytes, plus any header/format overhead - but you'd get similar performance out of any uncompressed format, that's just the tradeoff.

Post reply on HN