computerbuster

blog: https://halide.cx/blog/fmetrics/

I think these conversations are directed by the parties funding the efforts. Example: "we (large company) want a fast AV2 decoder" -> they pay a specialized team to do it -> this team works in C for the most part, so it is done in C. If there were financial incentives to do it in Rust, they'd pay more for a Rust decoder.

Congratulations to the team, I've been on Zed exclusively for a couple of years and it has been nothing but great on macOS and Linux.

JPEG XL is mainly based on unique image-specific research, but you're right to say a lot of the techniques are compatible with videos in theory (the XYB color space comes to mind). AVIF is an AV1 OBU in an image-specific container, and required a lot of image-specific engineering to make AV1's tools useful for images; see libaom's tune "iq", and the same in SVT-AV1. The compression gains translated when engineering effort went into creating bespoke implementations, and the same may happen for LLMs if I had to guess.

Quick follow-up from the original SSIMULACRA2 author:

The error will be much smaller than the error between ssimu2 and actual subjective quality, so I wouldn't worry about it.

Existing tools really just need to do a better job keeping up.

Very cool use case! 4:4:4 support + 10-bit color make AVIF very compelling here.

I'm a big fan of JPEG XL, but even its most dedicated fans have given up the argument that it is the best for compression efficiency. AVIF's generational leap took place in August 2024 with Tune Still Picture in SVT-AV1-PSY, so much so that Google integrated it into their own encoder and has done very impressive work optimizing it further for the human visual system. JPEG XL's strongest quality is its featureset; lossless JPEG recompression, for example, is really incredible

Hi, author here – the README covers this in the Performance section: https://github.com/gianni-rosato/fssimu2?tab=readme-ov-file#...

If you run the `validate.py` script available in the repo, you should see correlation numbers similar to what I've pre-tested & made available in the README: fssimu2 achieves 99.97% linear correlation with the reference implementation's scores.

fssimu2 is still missing some functionality (like ICC profile reading) but the goal was to produce a production-oriented implementation that is just as useful while being much faster (example: lower memory footprint and speed improvements make fssimu2 a lot more useful in a target quality loop). For research-oriented use cases where the exact SSIMULACRA2 score is desirable, the reference implementation is a better choice. It is worth evaluating whether or not this is your use case; an implementation that is 99.97% accurate is likely just as useful to you if you are doing quality benchmarks, target quality, or something else where SSIMULACRA2's correlation to subjective human ratings is more important than the exactness of the implementation to the reference.

The past two years have seen significant advancements in video and image compression, particularly with the maturation of the SVT-AV1 video encoder and improvements to AVIF image compression. These developments, coupled with faster and more accessible developer tools, have made it easier to produce high-quality compressed media. I have a lot of optimism for the future with AV2 and the potential for further community-driven innovation in open-source compression technology.

This is an incredibly robust solution to a really pressing problem for a lot of individuals/orgs who want to use/deploy reasonably powerful LLMs without paying through the nose for hardware. Others have mentioned the hyperscalers have solutions that make some amount of sense (Azure confidential computing, AWS nitro enclaves) but if you read a bit more about Tinfoil, it is clear they want to operate with far less explicit user trust (and thus much better security). This team is setting the standard for provably private LLM inference, and to me, it makes other solutions seem half-baked by comparison. Props to this talented group of people.

Another resource on the same topic: https://blogs.gnome.org/rbultje/2017/07/14/writing-x86-simd-...

As I'm seeing in the comments here, the usefulness of handwritten SIMD ranges from "totally unclear" to "mission critical". I'm seeing a lot on the "totally unclear" side, but not as much on the "mission critical", so I'll talk a bit about that.

FFmpeg is a pretty clear use case because of how often it is used, but I think it is easier to quantify the impact of handwriting SIMD with something like dav1d, the universal production AV1 video decoder.

dav1d is used pretty much everywhere, from major browsers to the Android operating system (superseding libgav1). A massive element of dav1d's success is its incredible speed, which is largely due to how much of the codebase is handwritten SIMD.

While I think it is a good thing that languages like Zig have built-in SIMD support, there are some use cases where it becomes necessary to do things by hand because even a potential performance delta is important to investigate. There are lines of code in dav1d that will be run trillions of times in a single day, and they need to be as fast as possible. The difference between handwritten & compiler-generated SIMD can be up to 50% in some cases, so it is important.

I happen to be somewhat involved in similar use cases, where things I write will run a lot of times. To make sure these skills stay alive, resources like the FFmpeg school of assembly language are pretty important, in my opinion.

AvifHash leverages the power of AVIF to create image placeholders that are both compact and efficient.

This Proof of Concept shows promising results: at 27 characters, AvifHash outperforms BlurHash https://blurha.sh/ (using 4x3 components) in quality and detail retention. At a similar quality, BlurHash needs 54 (5x5) to 76 characters (6x6 components).

Given that AVIF decoding is done by the web engine, AvifHash is very small: the entire demo page (including parsing and re-hydration code) is only 2.3 kB gzipped.

A deep dive into programming a freestanding QOI encoder using the Zig programming language.

I just started C and Zig at the same time in October. While Zig was not easy to learn right away, in my opinion, it has become a joy to work with as I've become more familiar with it. This isn't to say learning C is a useless exercise in futility, but I think people not understanding why Zig is cool might need to remember they may be more experienced and more accustomed to things about C that are hard to get used to as a beginner.

This blog post on the Codec Wiki by encoder Trix presents extensive benchmarking of SVT-AV1 1.8.0 on animated content using both objective metrics and subjective image comparisons (the subjective part is coming soon). Short high-quality anime clips were encoded directly with SVT-AV1 across a range of settings. SSIMULACRA2 visual quality scores and encoding speeds were measured for each encode, along with bits per pixel to calculate encoding efficiency. The results are presented through graphs showing metric scores and speed, alongside comparison images enabling subjective evaluation of visual quality (again, comparison images coming soon for subjective analysis). This rigorous testing methodology provides insightful analysis of how SVT-AV1 performs when encoding animation.

Apple really gave JXL the boost it needed. A part of me deep inside hopes that Apple switches to JXL & leapfrogs the whole gain map JPEG thing going on in Android land currently, then Android OEMs can switch to JXL too. HEIC is not & will never be compatible enough, and the royalties ruin it.

Like tests that compare an image codec's size to its visual quality, these tests plot time vs. compressed size, allowing you to compare the various compression steps of lossless data compression algorithms relative to the time taken to compress/decompress. It compares ZIP, XZ, 7zip, Brotli, ZPAQ, & Zstandard.

If you mean to say they share the same architecture, you're correct. I misunderstood your phrasing

And they are all not competitive with Apple Silicon. What's your point?

No it isn't. It is M2 based

mozjpeg automatically handles chroma subsampling, scaling up from 4:2:0 to 4:2:2 & then 4:4:4. WebP is 4:2:0 only, AVIF is 4:4:4 only (as tested) & I believe JXL doesn't subsample at all.

How does the new cjpegli encoder using the XYB color space stack up compared to the competition?

From libjpeg to libjpeg-turbo, then mozjpeg, and now jpegli, is this another great leap forward in coding efficiency? Jpegli compared to mozjpeg, WebP, AVIF & JXL.

It can be, but not perfectly.

Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/?utm_sour...

Chrome: https://chrome.google.com/webstore/detail/add-jxl-support/kh...

https://giannirosato.com/blog/post/nvenc-v-qsv/ This site has WASM-decoded JXL images using JXL.js. Native support would be much faster, & trying to decode much larger images with JXL.js doesn’t work very well.

You're right, I should look into this. Thanks for linking.

Using SSIMULACRA2, I've compared Intel's QuickSync Video to Nvidia's NVENC encoder across Linux & Windows. They compete against other dedicated encoding hardware for different codecs across different GPUs, including an Intel iGPU.

I think the most interesting takeaway here is that while JXL continues to face unfair treatment from web browser vendors, jpegli is a really fascinating development that performs very closely to AVIF at high quality in the dataset. I'd like to test jpegli with the XYB colorspace in the future to see how much better it is compared to RGB, but even with the RGB handicap it still looks very promising.

As I mentioned in the article, Thorium is a Chromium-based browser that fully supports JPEG-XL. Here's the libjxl patch that can be ported to other Chromium-based browsers: https://github.com/Alex313031/thorium-libjxl