Jokes aside, this is exciting news. PNG is back to its former glory after its progress stalled for over two decades. Did you know the U.S. Library of Congress, Library and Archives Canada, and the National Archives of Australia recommend PNG? It is important that we keep PNG current and competitive. After 20 years of stagnation, PNG is back with renewed vigor!
[…]With these titans behind it, the image format is back with full momentum. Work has already begun on the next two PNG spec updates.
↫ Chris Blume
The new PNG specification update adds proper HDR support, which is probably its most important new features. Chris Lilly, one of the original creators of PNG and actively involved in these new updates as well, has a detailed blog post diving into how HDR in PNG works. Other changes include officially adding Mozilla’s animated PNG implementation to PNG, support for EXIF data, and a ton of smaller changes and cleanups.
I don’t care if it’s official now. APNG is still banned from my stuff.
I think https://www.w3.org/TR/PNG-Rationale.html made the right call on specifying that the PNG magic number indicates a single image frame. Still images and animations, never the twain shall meet.
Not even MNG ?
https://en.wikipedia.org/wiki/Multiple-image_Network_Graphics
I have nothing against MNG. My issue is with allowing the same file extension and magic number to represent both static and animated content, so you need to actually parse the bleeping thing to tell which it is in the presence of potentially very long frame delay values and you need to reprocess user content to enforce site policy in the absence of something like
img { animate: never; }
Then you might hate SVG 🙂
In relevant contexts, SVG is either disallowed or treated as source code, not an image file.
Still a better option than GIF, no?
In the sense that it’s better to have to parse a potentially malicious file with an alpha channel and true color support so you can ban animation, rather than having to parse a potentially malicious file with a 1-bit transparency mask and a 256-color palette so you can ban animation?
Yes. In that sense, APNG is better than GIF… they both suck for forcing me to increase my hacker attack surface to protect against trolls.
This is quite nice and needed.
Maybe most people did not realize, however our sRGB space was extremely limited. So much so, it cannot even reproduce the SDTV signal from NTSC. (It covers 35?% or 72% depending on how you measure it).
https://www.panadisplay.com/news/color-gamut-value-of-a-display-10668449.html
This is essentially terrible, and very limiting. Especially for pro work. Some “extended gamut” display standards like Adobe RGB wanted to fix this. Yet even that was lacking.
Now we have actual modern color spaces, like Rec.2020, which is pretty much standard. That is why when you look at a modern OLED TV, you’d see colors you cannot ever possibly see on an older LED television set (maybe some emulation with dithering, but won’t be same).
And… it brings us to modern formats and desktop operating systems. Unfortunately most of our UI is designed for the RGBA [256, 256, 256, 256] color descriptions. If you download anything from an older BMP file to a modern JPEG it is most likely RGB or RGBA (3 or 4 channels of 8 bits) and assumes sRGB. If you display them on a modern display, the entire color space will not be used.
(Why not expand the color space automatically? Because things will look “off”. Now you will have greens and purples that were not part of the original image (or maybe they were, but clipped).
In any case, this breaks modern UI.
Again why?
The modern UI with older elements, which means HDR mixed with SDR causes massive tonal “shifts” on the screen. Some elements will be vibrant, highly detailed, and brighter, while others will be dull and dim.
Yes, this also affects light intensity, The older sRGB was 80 to 120 nits, while new content could be up to 2,000 nits easily. though most TVs will clamp at 1,200-ish.
So, your SAVE button could be very bright, while the PNG next to it is extremely dim and dull (or vice versa.
So, where does this take us?
There are no easy solutions. There are only compromises. Shifting the range from SDR from HDR can be done, but it will be extra work. Either manually, or using ML algorithms. For instance, Microsoft has AutoHDR, first on the Xbox, later on the PC using pretrained ML “color space” upscaler:
https://support.microsoft.com/en-us/windows/use-auto-hdr-for-better-gaming-in-windows-0cce8402-3de5-4512-a742-e027ca7aa79c.
But does not work on the desktop.
If you don’t scale the ranges, and just mix, it really looks bad.
So much so, some will claim “SDR looks better”
https://www.reddit.com/r/OLED_Gaming/comments/1c3n0ur/pg32ucdm_why_does_sdr_look_so_much_better_than_hdr/
(yes it might… with wrong settings)
Back to topic:
It is nice to see this finally happen, but we are entering a “uncanny valley” period for a while.
sukru,
I remember the outrage over apple advertising “millions of colors” on it’s laptops and displays that physically used 6 bit TN panels with dithering (circa 2009). I wouldn’t be surprised if analog CRTs from a decade earlier had better color reproduction.
https://discussions.apple.com/thread/2068556
We needed a new TV recently. I read that even though plasma fell out of favor, no technology since has matched the response and range that plasma had. A hisense TV we ordered was just awful with so much smearing in motion shots and dark scenes that we had to return it. The samgsung TV we ended up buying doesn’t have the best view angle, and it wasn’t the brightest, but at least it was pleasant to watch without scaling artifacts and smearing. (It is tarnished by operating system “smart features”, but that’s a different discussion).
As far as I know jpeg doesn’t support alpha, which it’s one of the reasons I use PNG. I tested this in GIMP just to be sure and it doesn’t save the alpha channel.
Yeah, you only mention this as a hypothetical, but I think it’s actually a problem we have in practice with real panels. There are different color profiles and then some manufacturers try to artificially emulate new profiles different from the hardware, making true calibration even worse. Apparently apple do this and it drives some pros a bit nuts…
https://lightillusion.com/grading_displays.html
https://hub.displaycal.net/forums/topic/mac-and-pc-producing-different-colour-with-same-display-p3-profile/
It’s problematic to have software/OS assumptions about using the monitor’s brightest output level for “standard white” and using completely wrong gamma curves. Ideally all images would record the captured brightness (in nits or something similar) so the software could scale the requested brightness to the display. This would work well to the extent that it was done consistently, but the fact is pre-existing software does not do it. Maybe there needs to be an OS defined “standard white” limit applied to all applications by default, with a new API to explicitly unlock brighter colors? I’m out of the loop on this though so maybe there are HDR OS APIs that do this already?
Algorithms can try to “invent HDR data from SDR source”, but I don’t think it’s necessary for most game engines that already have light data in game. It just needs to be calibrated. Ideally the color profile would be set just once in the operating system and shared by all applications. In practice though…hmm. It’s not likely to be set correctly and most developers can’t be bothered to use it. Games just end up getting whatever values looked best for developers.
Well, I’d say that of course the ranges need to be scaled appropriately. In practice, we fail to do it and getting the intended brightness and color without any calibration may be dumb luck.
Not even JNG ?
https://www.libpng.org/pub/mng/spec/jng.html
Kochise,
I see it’s from 1999 and was designed for MNG to support lossy compression. This is the first I hear of it. Gimp doesn’t show support either.
I just checked and apparently JPEG 2000 supports an alpha channel.
https://en.wikipedia.org/wiki/JPEG_2000
I’ve dealt with this format for work because employees using iphones were uploading them to a portal. So I guess it’s used on iphones, but I needed to convert them all to standard jpeg because web browsers don’t support the jp2 format. Gimp only supports the format for reading.
Long ago before PNG we used to use GIFs as the format of choice for transparent pixels, but now I use only PNG because we’re not limited to GIF’s 8 bit color palette. Sometimes I wish PNG had a lossy option for situations where file size matters more than exact pixels. But I guess it’s easier to have separate specialized formats than one format that handles everything.
Well, sadly MNG and JNG never took off, despite being image format solving the problems of the time.
– MNG was a better animated GIF (it’s the underlying format of Animation Shop, the animation software that comes with early Paint Shop Pro versions)
– JNG, just JPEG with an additional alpha layer.
You can test them here :
https://www.libpng.org/pub/mng/mngpics.html
The original NTSC color gamut defined in 1953 was never used in practice, since it proved impossible to reproduce by CRT TVs of the era while maintaining acceptable brightness. Actual NTSC content uses a color gamut of sRGB/Rec709 or Rec601 (which is very similar to sRGB/Rec709).
Now about the UI stuff, realistically you need two versions of the UI: One for sRGB/Rec709 and one for Rec2020, with legacy content such as JPGs being up converted. Also keep in mind that Rec2020 usually comes together with HDR which in turn comes with new brightness values, since SDR tops put at 200nits or so (officially 100nits, but the SDR standard has been hacked) while HDR can go as high as 10000 nIts and will need tone-mapping. In plain English, RGB[1024, 1024, 1024] doesn’t need tone-mapping if it encodes 10-bit SDR but does if it encodes HDR, since in the first case it represents 200nits at most (that every display can reproduce) while in the second case it may represent anywhere from 1000nits to 10000 nits.
Personally, I don’t trust everyone involved to get this right, so I’d rather have my desktop at SDR and sRGB/Rec709 and only enable HDR and Rec2020 in full screen mode for HDR content.
Finally, APNG is standardized. Took them freaking long enough. 😀
I’m not surprised it “took them long enough”. Previous versions of the PNG spec explicitly and intentionally made the promise that the PNG header indicates a file containing a single frame.
(Phrased in the form of a PNG file containing one or more versions of a single abstract image, achieved through a specified list of transformations.)
That’s why upstream libpng could never support APNG. It’s the reference implementation and, thus, must implement the spec, not violate it.
How does PNG compare to lossless compression with Webp, Avif and JPEG XL? I think it was on par with Avif (despite being much, much older) but significantly worse than Webp and JPEG XL lossless compression. Would it be technically possible to add these improvements to the old PNG spec in a backward-compatible way? Because what makes PNG so great is that just based on the file extension you already know it’s lossless and it will stay that way.
PNG currently works by running the image data through one of a predefined set of filters to make it more compressible, and then applying the same DEFLATE compression Zip files use.
Applying a new compression algorithm would result in that situation Zip’s been going through where certain unzipping tools can’t unzip certain Zips because WinZIP 12 added new algorithm flags for things like bzip2, PPMd, and LZMA2.
(The Zip format also already had this mechanism because, before DEFLATE took over the zipping world with WinZIP 2.x, the options were STORE (no compression), Shrink, Reduce, and Implode.)
If you want to improve the compression ratio in a compatible way, either use 7zip’s strongest mode (since 7zip has a smarter DEFLATE implementation, sort of like how Mozilla cooked up a better JPEG-writing library) or use AdvanceCOMP or Zopfli to repack an existing archive.
(AdvanceCOMP uses 7zip’s implementation and Zopfli is a separate one and the speed vs. effectiveness runs from 7zip to AdvanceCOMP to Zopfli… Zopfli takes FOREVER because it’s meant for packing small website subresources like gzipped CSS or JS files once and then making the time back by serving them millions of times.)
j0scher,
Yes.
Not in a way that an existing PNG decoder would read it.
Maybe you could implement a new format that is a subset of the old format by embedding extra unused data segments. An old PNG decoder might see a reduced resolution image, while a new PNG decoder could get the full image.
Wait, here’s another idea: find an exploit in the old decoder, then you can write a format that loads it’s own bootloader to decode itself. I call it the png-ploit format 🙂