-
Notifications
You must be signed in to change notification settings - Fork 591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PNG (and probably AVIF) encoding with compression too slow #2248
Comments
The slowness of AVIF is expected. It's a complex codec. The underlying library rav1e has speed settings, but the faster it goes the less advantage it has over other formats (you can make it as fast as webp, but files will have similar filesize/quality as webp too). PNG file sizes are not comparable to HEIC or AVIF. PNG is lossless, and the other ones are lossy. These are entirely different requirements. It's especially terrible when you take a lossy file and encode it in PNG, because all the cut corners and distortions that made the file small before are now alien noise that PNG is told to preserve exactly, and that costs even more to encode. As a result you get lots of data to encode, a huge PNG, and that's going to be slow too. |
If you want to compress images well, tolerate the slowness of AVIF. If you have lossy images and you want to save them quickly, use JPEG. |
@kornelski Thank you for taking a look at this. Let's ignore the PNG for now, the only reason I started lookign at PNG compression levels was because I could not get AVIF encoded within reasonable amount of time. If we update the example I've originally provided to encode the image as AVIF:
then encoding takes 274 seconds on my machine. The produced image is small, 732Kb worth of AVIF vs 2.1Mb in the original HEIC. The encodign has also held 10 CPU cores saturated for the entire encoding period:
Is this really how expensive AVIF encoding is? |
How large is the image in pixels? Are you sure you're building in release mode? |
You likely also want to enable the |
cool, looks like it was another case of courage and stupidity. I was experimenting with image-rs from unit tests which are compiled with optlevel 0. I have just tried the example above in release mode, encoding the example image (which is 3024 × 4032 by the way) now takes 17 seconds instead of 274 seconds like it used to. Thanks everyone involved for looking at this. |
Hi there, it's a bit of a saga, but the gist is that it looks like compression is taking way too long on MacOS (over a minute on M1 for PNG).
Check this code:
This uses 'libheif-rs = "1.0.2"' for reading HEIC image (attached) and then tries to write it as PNG. Reading is quick enough, writing takes much longer. If I change the compression to
CompressionType::Fast
, it becomes much quicker. The resulting image is much larger than the original HEIC (~10Mb for CompressionType::Best, and ~26Mb for CompressionType::Fast).The reason I have actually started looking at this is because I want AVIF rather than PNG, but writing AVIF was taking absolutely forever and I came to using PNGs as an investigatory step. It seems from readme that AVIFs are "lossy-only", therefore I am assuming there is some common processing that is related to compression slowing things down.
This is happening on MacOS, M1 chip, Rust 1.77.2, stable.
P.S.
sorry about the zip, even Github does not like HEIC
IMG_6974.HEIC.zip
The text was updated successfully, but these errors were encountered: