6 ms·

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 fidel

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 PSDs and SVGs, where the same file never looked the same on two browsers/devices/apps/versions. I would bet that these days, generating or decoding PNGs is the bottleneck almost nowhere, but extending the format would cause problems everywhere in real-world usage. Apps and companies can no longer tell whether there's something wrong with their image or if somewhere in the pipeline, some new graphics designer decided to use a bleeding-edge version of a 30-year-old graphics format that nobody else accounted for, and it looks "broken" in half the browsers now. A format can still look broken even if it's "backward compatible", just by virtue of having some features (like HDR) that are only displayable in some renderers but not others. Why not just make a new format instead and have browsers & devices fall back as necessary, like we already do with webp and srcsets?

zimbatm 3y ago
He said that it would be backwards-compatible. It's in the name of the project.
- solardev 3y ago
  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 several images inside them: A full-featured version with "color" (or HDR, or or whatever) for newer renderers, and a fallback one (in "black and white" in his example) for existing renderers. It's not really "backward compatible", but more like "fallback-able".
  - brookst 3y ago
    > 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 instructions and data for adding information to it.
    - solardev 3y ago
      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 times before with hacked-on file extensions. If it were Microsoft doing this (it's not), it would be just yet another embrace-extend-extinguish effort. But it's not. I have no doubt this author has good intentions, and this is a cool hack, but I think it will lead to confusion and poor outcomes in widespread usage. It's really not great when an image format looks "somewhat" the same between renderers. In fact, I think that's worse than it not working at all. From experience, it leads to these situations where the same image can fragment over time just by virtue of being worked on by different people in different environments (apps, OSes, browsers, devices), and there's not really a clear way to tell which is which without extensively analyzing the metadata. If Joe starts work on a HDR version, sends it to Sarah, Sarah adds a bunch of new edits but then saves it in an app that recompresses the image and overwrites the HDR, Joe might never know. And then if the format continues to expand, maybe a bit later Jane and Janet each add mutually incompatible extensions to the file without knowing it. The "base" image might look the same to all of these people, but each had specific edits in mind that the others might not have known about, because their renderers LOOKED like it was rendering the same image when it wasn't. This isn't a hypothetical... it happened a lot when PNG first came out, and with PSD (Photoshop files) for a good decade or two until the subscription model came out.
hinkley 3y ago
PNG was always set up for extension. In particular, it has a clever way of allowing ancillary data sections to be marked as unimportant, so a decoder knows whether it can skip them or report the file as unreadable. I suspect the big thing these days would be to support brotli and zstd.
- solardev 3y ago
  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.
  - sspiff 3y ago
    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?
    - Too 3y ago
      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.
      - sspiff 3y ago
        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.
chaxor 3y ago
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.
- tetris11 3y ago
  I think idiocy and short-term self-interest is more at play here, than any 4D chess shenanigans.
- sp332 3y ago
  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.
  - Sardtok 3y ago
    Please don't use PNG for photos.
    - namrog84 3y ago
      Then what? Jpegs?
      - pavlov 3y ago
        The clue about the use case is in the naming: Joint Photographic Experts Group vs Portable Network Graphics
      - Aachen 3y ago
        (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
skybrian 3y ago
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.
- pwdisswordfishc 3y ago
  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.
  - skybrian 3y ago
    What's "EEMAWDJI?" There are no Google search results for that acronym.
    - solardev 3y ago
      Just a weirdly spelled "emoji".
mmastrac 3y ago
APNG is extremely well-supported these days: https://caniuse.com/apng https://caniuse.com/apng Fun fact: APNG is better supported than JSON.stringify
- Andrex 3y ago
  And yet I have yet to see one in the wild. It's all WebM and Gifs these days.
  - keep_reading 3y ago
    If you've seen a video slot machine you've seen APNGs :)
    - Hasnep 3y ago
      Interesting, why do video slot machines use APNGs?
      - keep_reading 3y ago
        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
        marpstar 3y ago
        You sure it wasn't PRNG? https://en.wikipedia.org/wiki/Pseudorandom_number_generator https://en.wikipedia.org/wiki/Pseudorandom_number_generator
gred 3y ago
> 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-cloudflare-and-comparing-performance-with-other-zlib-forks/ https://aws.amazon.com/blogs/opensource/improving-zlib-cloud...
- Nyan 3y ago
  Why not use fpnge?
  - gred 3y ago
    It's a Java system, so not quite so simple. Maybe it's worthwhile to create some Java bindings? Recent JDKs make it feasible to swap out the underlying zlib implementation, so swapping out zlib-madler with zlib-cloudflare or zlib-ng might provide the best cost/benefit.
    - Nyan 3y ago
      Someone made this: https://github.com/manticore-projects/fpng-java https://github.com/manticore-projects/fpng-java Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
      - gred 3y ago
        Very cool, thanks for the pointer! We might be able to run an internal test to check performance vs. a zlib replacement, but I think that AGPL license is going to be a showstopper for anything else...
smcameron 3y ago
> 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 https://github.com/richgel999/fpng [2] https://github.com/phoboslab/qoi https://github.com/phoboslab/qoi (discussed here: https://news.ycombinator.com/item?id=29661498 https://news.ycombinator.com/item?id=29661498)
- doophus 3y ago
  Most games ship textures in a GPU-friendly format such as DXT to avoid problems like this.
pwdisswordfishc 3y ago
> 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.

zimbatm 3y ago

He said that it would be backwards-compatible. It's in the name of the project.

solardev 3y ago
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 several images inside them: A full-featured version with "color" (or HDR, or or whatever) for newer renderers, and a fallback one (in "black and white" in his example) for existing renderers. It's not really "backward compatible", but more like "fallback-able".
- brookst 3y ago
  > 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 instructions and data for adding information to it.
  - solardev 3y ago
    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 times before with hacked-on file extensions. If it were Microsoft doing this (it's not), it would be just yet another embrace-extend-extinguish effort. But it's not. I have no doubt this author has good intentions, and this is a cool hack, but I think it will lead to confusion and poor outcomes in widespread usage. It's really not great when an image format looks "somewhat" the same between renderers. In fact, I think that's worse than it not working at all. From experience, it leads to these situations where the same image can fragment over time just by virtue of being worked on by different people in different environments (apps, OSes, browsers, devices), and there's not really a clear way to tell which is which without extensively analyzing the metadata. If Joe starts work on a HDR version, sends it to Sarah, Sarah adds a bunch of new edits but then saves it in an app that recompresses the image and overwrites the HDR, Joe might never know. And then if the format continues to expand, maybe a bit later Jane and Janet each add mutually incompatible extensions to the file without knowing it. The "base" image might look the same to all of these people, but each had specific edits in mind that the others might not have known about, because their renderers LOOKED like it was rendering the same image when it wasn't. This isn't a hypothetical... it happened a lot when PNG first came out, and with PSD (Photoshop files) for a good decade or two until the subscription model came out.

hinkley 3y ago

PNG was always set up for extension. In particular, it has a clever way of allowing ancillary data sections to be marked as unimportant, so a decoder knows whether it can skip them or report the file as unreadable. I suspect the big thing these days would be to support brotli and zstd.

solardev 3y ago
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.
- sspiff 3y ago
  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?
  - Too 3y ago
    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.
    - sspiff 3y ago
      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.

chaxor 3y ago

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.

tetris11 3y ago
I think idiocy and short-term self-interest is more at play here, than any 4D chess shenanigans.
sp332 3y ago
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.
- Sardtok 3y ago
  Please don't use PNG for photos.
  - namrog84 3y ago
    Then what? Jpegs?
    - pavlov 3y ago
      The clue about the use case is in the naming: Joint Photographic Experts Group vs Portable Network Graphics
    - Aachen 3y ago
      (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

skybrian 3y ago

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.

pwdisswordfishc 3y ago
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.
- skybrian 3y ago
  What's "EEMAWDJI?" There are no Google search results for that acronym.
  - solardev 3y ago
    Just a weirdly spelled "emoji".

mmastrac 3y ago

APNG is extremely well-supported these days: https://caniuse.com/apng https://caniuse.com/apng Fun fact: APNG is better supported than JSON.stringify

Andrex 3y ago
And yet I have yet to see one in the wild. It's all WebM and Gifs these days.
- keep_reading 3y ago
  If you've seen a video slot machine you've seen APNGs :)
  - Hasnep 3y ago
    Interesting, why do video slot machines use APNGs?
    - keep_reading 3y ago
      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
      - marpstar 3y ago
        You sure it wasn't PRNG? https://en.wikipedia.org/wiki/Pseudorandom_number_generator https://en.wikipedia.org/wiki/Pseudorandom_number_generator

gred 3y ago

> 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-cloudflare-and-comparing-performance-with-other-zlib-forks/ https://aws.amazon.com/blogs/opensource/improving-zlib-cloud...

Nyan 3y ago
Why not use fpnge?
- gred 3y ago
  It's a Java system, so not quite so simple. Maybe it's worthwhile to create some Java bindings? Recent JDKs make it feasible to swap out the underlying zlib implementation, so swapping out zlib-madler with zlib-cloudflare or zlib-ng might provide the best cost/benefit.
  - Nyan 3y ago
    Someone made this: https://github.com/manticore-projects/fpng-java https://github.com/manticore-projects/fpng-java Replacing zlib might give you a few percentage points' worth of difference, whilst fpnge would likely be several times faster.
    - gred 3y ago
      Very cool, thanks for the pointer! We might be able to run an internal test to check performance vs. a zlib replacement, but I think that AGPL license is going to be a showstopper for anything else...

smcameron 3y ago

> 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 https://github.com/richgel999/fpng [2] https://github.com/phoboslab/qoi https://github.com/phoboslab/qoi (discussed here: https://news.ycombinator.com/item?id=29661498 https://news.ycombinator.com/item?id=29661498)

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

pwdisswordfishc 3y ago

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