PNG compression is an absolute joke so that’s not worth anything - JPEG-XL and WebP Lossless beat PNG by a longshot. PNG also requires intense optimization to be truly compressed, and I’m not sure to what extent they tried to optimize their PNG results. As an example, the lossless comparison chart I uploaded was 380KB initially, and I was able to optimize it to 280KB using OxiPNG. The PNGs in the lossless comparison chart were properly optimized.
Beating FLAC is interesting, but FLAC compression hasn’t really been updated in a long time TMK - I wonder if there’s traditional gains left on the table with modern compression techniques?
Yeah, PNG is overly complex, slow to encode/decode, and despite all that, it atill doesn’t compress the picture very well
I think i heard that one of the creators of the format said he didn’t have any experience with compression, and they more or less just threw things at the wall to see what stuck
If you want the mediocre compression level of PNG, but waaaay faster, i can recommend QOI
QOI should actually be worse than JPEG-XL in both speed and size, if you turn JPEG-XL’s effort level down to a speed-oriented level like -e 1. I wrote a quick script to compare them, and this is the output from 10 random (fully-optimized) PNGs I had: https://pastebin.com/raw/nSkBSePB
I have a lot of cores on my CPU so you probably want to be looking at the user time metric, but consider that parallelization is a strong and intentional benefit to JPEG-XL.
The results are not exactly scientific since I only picked 10 PNGs, but it shows a general trend.
Not sure if I made it clear but the real time metric is equivalent to time passing in real life, and user time is the total CPU time spent by the application, e.g. 2 seconds of user time across 4 cores might be 0.5 seconds of real time. Parallelization is really good for end users (browsers loading an image, someone saving a file from GIMP, etc), but single-threaded performance can still be very important for enterprise applications where you’re converting a ton of images all the time, and you can just give every conversion its own thread instead. I mainly focused on user time when looking at the difference between JXL and QOI, since that’s more indicative of the total amount of work being done in a CPU-agnostic way.
PNG compression is an absolute joke so that’s not worth anything - JPEG-XL and WebP Lossless beat PNG by a longshot. PNG also requires intense optimization to be truly compressed, and I’m not sure to what extent they tried to optimize their PNG results. As an example, the lossless comparison chart I uploaded was 380KB initially, and I was able to optimize it to 280KB using OxiPNG. The PNGs in the lossless comparison chart were properly optimized.
Beating FLAC is interesting, but FLAC compression hasn’t really been updated in a long time TMK - I wonder if there’s traditional gains left on the table with modern compression techniques?
A copy of the original paper can be found here.
Yeah, PNG is overly complex, slow to encode/decode, and despite all that, it atill doesn’t compress the picture very well
I think i heard that one of the creators of the format said he didn’t have any experience with compression, and they more or less just threw things at the wall to see what stuck
If you want the mediocre compression level of PNG, but waaaay faster, i can recommend QOI
QOI should actually be worse than JPEG-XL in both speed and size, if you turn JPEG-XL’s effort level down to a speed-oriented level like
-e 1. I wrote a quick script to compare them, and this is the output from 10 random (fully-optimized) PNGs I had: https://pastebin.com/raw/nSkBSePBI have a lot of cores on my CPU so you probably want to be looking at the
usertime metric, but consider that parallelization is a strong and intentional benefit to JPEG-XL.The results are not exactly scientific since I only picked 10 PNGs, but it shows a general trend.
Ooh, i didn’t take parallelization into consideration, that’s very interesting, thank you
Not sure if I made it clear but the
realtime metric is equivalent to time passing in real life, andusertime is the total CPU time spent by the application, e.g. 2 seconds ofusertime across 4 cores might be 0.5 seconds of real time. Parallelization is really good for end users (browsers loading an image, someone saving a file from GIMP, etc), but single-threaded performance can still be very important for enterprise applications where you’re converting a ton of images all the time, and you can just give every conversion its own thread instead. I mainly focused onusertime when looking at the difference between JXL and QOI, since that’s more indicative of the total amount of work being done in a CPU-agnostic way.