MadameMinty

Joined 3 years ago

Karma

105

Submissions

Member since

Jul 26

View on Hacker News

Recent submissions

Comment · 7 hours ago

Actually I tested it in practical (for me) conditions and that's not necessarily true. Definitely dependent on the content and target environment. https://gist.github.com/MadameMinty/9d2e9a481e955ea55c1bae18...

WebP timing turned out to be true on a few years old tablet, but not on a newer phone nor desktop; the number of large cores determines that time for JXL. The CPU time is probably lower for WebP, didn't measure that. But wall clock tells a different story, and the encode times and size bury WebP.

AVIF is a strange format since its lossy compression can _improve_ when you add a smaller layer; it's smaller than WEBP in the normal modes (s6; s>=7 switches to real-time mode which sucks and s3 takes centuries), sure. But even it decodes faster than WebP in favorable chip conditions. And JXL via Jixel just eats both for breakfast with plenty of room to spare.

Comment · 2 days ago

JXL decoding can still be optimized and had significantly less time for it, so let's not be so sure if that statement holds. Last update brought much improvement at just the area you mention.

And AVIF compression ratio beats JXL only conditionally. E.g. my photo library had AVIF at 29% and JXL at 25% the input size at the same perceptual quality (SSIM2=83). Sometimes it's on par. Sometimes AVIF wins. JXL wins almost always. Not to mention you can losslessly, reversibly transcode lossy JPG files to JXL, getting significant size reduction for free.

Comment · 2 days ago

I hope so, but I disagree with the size of the "except": JXL performs better than APNG and GIF, and still supports transparency and lossless encode. Video codecs struggle here. So even with animation it still depends!

There's also a case for AVIF in some use cases (for this image it performs poorly). But if I had to choose one, I'd choose JXL.

Comment · 2 days ago

For completeness, my background job of the highest imaginable PNG compression yielded optimized: 528313 bytes. Took only several minutes...

Comment · 2 days ago

av1_nvenc exists therefore it's mainstream :)

Comment · 2 days ago

Yes, it's very disheartening. We're approaching two decades of WebP, after all. At this point it's not even worth implementing its support because JXL is superior in every use case.

Comment · 2 days ago

Worth pointing out that PNG is also just awful and should probably die like BMP died. WebP was already available at the time this article was written:

PNG: 1039993 bytes - baseline