PNG is back!
-
I remember MNG and never understood why APNG wasn't officially recognized. I didn't know it was widely supported already. Why do people still create and use GIF in the internet, if there is a superior format?
wrote last edited by [email protected]At least at one point, GIF89a (animated GIF) support was universal among browsers, whereas animated PNG support was patchy. Could have changed.
I've also seen "GIF" files served up online that are actually, internally, animated PNG files, so some may actually be animated PNGs. No idea why people do that.
-
PNG has terrible compression and It’s lossless unless you crush the colors. Transparency has been pretty much the only reason to use it.
wrote last edited by [email protected]PNG has terrible compression
It's fine if you're using it for what it's intended for, which is images with flat color or an ordered dither.
It's not great for compressing photographs, but then, that wasn't what it was aimed at.
Similarly, JPEG isn't great at storing flat-color lossless images, which is PNG's forte.
Different tools for different jobs.
-
PNG has terrible compression
It's fine if you're using it for what it's intended for, which is images with flat color or an ordered dither.
It's not great for compressing photographs, but then, that wasn't what it was aimed at.
Similarly, JPEG isn't great at storing flat-color lossless images, which is PNG's forte.
Different tools for different jobs.
wrote last edited by [email protected]JPEG isn't great at storing flat-color lossless images, which is PNG's forte.
JPEG isn’t, but JPEG-XL, on the other hand, has come into existence and has great compression while being pixel-perfect lossless as compared to PNG (among a host of other improvements).
If only it got the support it deserves (thanks Google for making that harder)
-
After 20 years, PNG is back with renewed vigor! A new PNG spec was just released.
Possibly the final version. Quite Okay Imaging (QOI) achieved similar compression with none of the complexity. Lossy + difference = lossless formats are surely the better option where performance is not crucial. Even the fact they fffucking finally made APNG official is decades late to replace GIF, since several image formats are now literally video formats.
The future is webp. And telling software patents to burn in hell.
-
Possibly the final version. Quite Okay Imaging (QOI) achieved similar compression with none of the complexity. Lossy + difference = lossless formats are surely the better option where performance is not crucial. Even the fact they fffucking finally made APNG official is decades late to replace GIF, since several image formats are now literally video formats.
The future is webp. And telling software patents to burn in hell.
The future is
webpJPEG XL...And telling software patents to burn in hell.
-
Possibly the final version. Quite Okay Imaging (QOI) achieved similar compression with none of the complexity. Lossy + difference = lossless formats are surely the better option where performance is not crucial. Even the fact they fffucking finally made APNG official is decades late to replace GIF, since several image formats are now literally video formats.
The future is webp. And telling software patents to burn in hell.
As cool and impressive as Qoi is, as long as I can't just send it to someone it's sadly not a replacement for PNG.
-
What's next?
I know you all immediately wondered, better compression?. We're already working on that. And parallel encoding/decoding, too! Just like this update, we want to make sure we do it right.
We expect the next PNG update (Fourth Edition) to be short. It will improve HDR & Standard Dynamic Range (SDR) interoperability. While we work on that, we'll be researching compression updates for PNG Fifth Edition.
One thing I'd like to see from image formats and libraries is better support for very high resolution images. Like, images where you're zooming into and out of a very large, high-resolution image and probably only looking at a small part of the image at any given point.
I was playing around with some high resolution images a bit back, and I was quite surprised to find how poor the situation is. Try viewing a very high resolution PNG in your favorite image-viewing program, and it'll probably choke.
-
At least on Linux, it looks like the standard native image viewers don't do a great job here, and as best I can tell, the norm is to use web-based viewers. These deal with poor image format support support for high resolutions by generating versions of the image at multiple pre-scaled levels and then slicing the image into tiles, saving each tile as a separate image, so that a web browser just pulls down a handful of appropriate tiles from a web server. Viewers and library APIs need to be able to work with the image without having to decode the whole image.
glivused to do very smooth GPU-accelerated panning and zooming --- I'd like to be able to do the same for very high-resolution images, decoding and loading visible data into video memory as required. -
The only image format I could find that seemed to do reasonably well was pyramidal TIFF.
I would guess that better parallel encoding and decoding support is likely associated with solving this, since limiting the portion of the image that one needs to decode is probably necessary both for parallel decoding and for efficient high-resolution processing.
Yeah, I have a couple over 800MB PNGs that I can only get Gimp to open properly. I need to look into pyramidal TIFFs.
-
-
After 20 years, PNG is back with renewed vigor! A new PNG spec was just released.
May webp die a horrible death in its wake!
-
What's next?
I know you all immediately wondered, better compression?. We're already working on that. And parallel encoding/decoding, too! Just like this update, we want to make sure we do it right.
We expect the next PNG update (Fourth Edition) to be short. It will improve HDR & Standard Dynamic Range (SDR) interoperability. While we work on that, we'll be researching compression updates for PNG Fifth Edition.
One thing I'd like to see from image formats and libraries is better support for very high resolution images. Like, images where you're zooming into and out of a very large, high-resolution image and probably only looking at a small part of the image at any given point.
I was playing around with some high resolution images a bit back, and I was quite surprised to find how poor the situation is. Try viewing a very high resolution PNG in your favorite image-viewing program, and it'll probably choke.
-
At least on Linux, it looks like the standard native image viewers don't do a great job here, and as best I can tell, the norm is to use web-based viewers. These deal with poor image format support support for high resolutions by generating versions of the image at multiple pre-scaled levels and then slicing the image into tiles, saving each tile as a separate image, so that a web browser just pulls down a handful of appropriate tiles from a web server. Viewers and library APIs need to be able to work with the image without having to decode the whole image.
glivused to do very smooth GPU-accelerated panning and zooming --- I'd like to be able to do the same for very high-resolution images, decoding and loading visible data into video memory as required. -
The only image format I could find that seemed to do reasonably well was pyramidal TIFF.
I would guess that better parallel encoding and decoding support is likely associated with solving this, since limiting the portion of the image that one needs to decode is probably necessary both for parallel decoding and for efficient high-resolution processing.
There is a reason why TIFF is one of the most popular formats for raster geographic datasets
-
-
The future is
webpJPEG XL...And telling software patents to burn in hell.
wrote last edited by [email protected]Never saw even one piece of your "future" in the wild...
-
There is a reason why TIFF is one of the most popular formats for raster geographic datasets
-
What's next?
I know you all immediately wondered, better compression?. We're already working on that. And parallel encoding/decoding, too! Just like this update, we want to make sure we do it right.
We expect the next PNG update (Fourth Edition) to be short. It will improve HDR & Standard Dynamic Range (SDR) interoperability. While we work on that, we'll be researching compression updates for PNG Fifth Edition.
One thing I'd like to see from image formats and libraries is better support for very high resolution images. Like, images where you're zooming into and out of a very large, high-resolution image and probably only looking at a small part of the image at any given point.
I was playing around with some high resolution images a bit back, and I was quite surprised to find how poor the situation is. Try viewing a very high resolution PNG in your favorite image-viewing program, and it'll probably choke.
-
At least on Linux, it looks like the standard native image viewers don't do a great job here, and as best I can tell, the norm is to use web-based viewers. These deal with poor image format support support for high resolutions by generating versions of the image at multiple pre-scaled levels and then slicing the image into tiles, saving each tile as a separate image, so that a web browser just pulls down a handful of appropriate tiles from a web server. Viewers and library APIs need to be able to work with the image without having to decode the whole image.
glivused to do very smooth GPU-accelerated panning and zooming --- I'd like to be able to do the same for very high-resolution images, decoding and loading visible data into video memory as required. -
The only image format I could find that seemed to do reasonably well was pyramidal TIFF.
I would guess that better parallel encoding and decoding support is likely associated with solving this, since limiting the portion of the image that one needs to decode is probably necessary both for parallel decoding and for efficient high-resolution processing.
Now we need a image fornat for very high resolutions that does slicing already by itself. Would enable easy parallelization too.
-
-
WebP had been kind of moving in on its turf, based on what I've been seeing websites using.
I've never heard of webP. Looked it up. Not impressed. Sticking with png.
-
Now we need a image fornat for very high resolutions that does slicing already by itself. Would enable easy parallelization too.
Again, that would be TIFF. TIFF images can be encoded either with each line compressed separately or with rectangular tiles compressed separately, and separately compressed blocks can be read and decompressed in parallel. I have some >100GiB TIFFs containing elevation maps for entire countries, and my very old laptop can happily zoom and pan around in them with virtually no delay.
-
After 20 years, PNG is back with renewed vigor! A new PNG spec was just released.
HDR PNG is huge
-
I've never heard of webP. Looked it up. Not impressed. Sticking with png.
The main advantage of webp is that it has good lossy compression, which makes it great for websites that show tens or hundreds of images on a single page
-
May webp die a horrible death in its wake!
WebP was the first widely supported format to support lossy transparency. It's worth it for that alone.
-
Great news! PNG has always been my image format of choice due to its relatively good compression and support for transparency.
Do you remember png? Well now it's back. In pog form!
-
Never saw even one piece of your "future" in the wild...
wrote last edited by [email protected]That's because Google removed the support from chrome after only a few months, and Mozilla never added it to Firefox.
And although there's apparently an extension for both, (lossy) image formats need out of the box browser support to have any chance for any kind adoption. -
As cool and impressive as Qoi is, as long as I can't just send it to someone it's sadly not a replacement for PNG.
Yeah, adoption's not a feature you can design.
The general idea may show up in any extensible format. Like a PNG encoder that only does Sub filter can encounter each pixel once.
... wait, PNG filtering is byte-level? It doesn't change with bit depth? Christ.
