Hacker News new | ask | show | jobs
by jjcm 1329 days ago
One caution here, as I'm just recently was working on automated image encoding for user submitted images - be careful of AVIF/JXL's encoding time.

I ran some benchmarks with a raw 48mp iPhone 14 dng file (converted to png to start with since jxl had issues going from dng directly) with imagemagick to illustrate.

jpg conversion: 1.74s

webp conversion: 3.77s

avif conversion: 67.96s

jxl conversion: 42.74s

Of course there's ways to optimize these, but still it's worth considering that these newer formats require an order of magnitude (if not more) increase in time to encode. If you're doing this for your own static site, it's worth doing. If you're dealing with user submitted images, make sure you understand the tradeoffs.

4 comments

I don't know much about AVIF (I guess the same concern applies though), but for JPEG XL there are actually two knobs for compression: distance or quality (`-quality` in ImageMagick) and effort (`-define jxl:effort`).

Distance is the target perceptual metric (Butteraugli), while effort controls a variance of the perceptual metric of the encoded image---which can be never accurate. Higher effort means more consistent quality but more computation as well. The default for cjxl, and probably also ImageMagick, is 7 ("squirrel"), which is very high and very slow as you noted. This is much like Brotli defaulting to the highest setting (-11) because both assume that you can spend much more time in compression. If it's not your assumption you should change that.

I do feel that this aspect of JPEG XL is not well communicated. Normally you have a single knob (quality) and increasing quality means more time spent for compression, but in JPEG XL this can be easily decoupled---very useful concept but also relatively alien one. A common mistake is to set the highest effort (9, nicknamed quite appropriately, "tortoise") for speed benchmark, which suggests that there will be people doing this in the production and complaining that JPEG XL compression is very slow, not realizing they can live with much lower efforts.

Yep, we do about 30TB of user images a month, looked into converting to avif for storage savings, but the processing time basically stopped that. Ended up on webp.
> avif conversion: 67.96s > jxl conversion: 42.74s

Holy shit-balls? Also I thought that quad bayer would come down to 12MP for the output?

I am using sharp to transform jpeg to avif images. The conversion also takes very long, for my images about 45s each.