Yes, Highway is pretty nice but also quite elaborate when it comes to dealing with multiple vectorized versions and dispatch. The macros burn my eyes still.
I'd absolutely still use Highway, and do. My experience is that even two separate implementations diverge over time and I'd have low confidence in bringing the same updates and improvements to all, even with LLM assistance.
Our programming model is 1) an agent+human to generate the algorithmic approach, 2) a C++ library (Highway) to translate to intrinsics, while filling in gaps + allowing customization, 3) a compiler to generate the actual code with some optimizations.
Asking the compiler to do #1 is a pipe dream: compiler friends tell me they are not going to devise new shuffles/data layouts (like what VQSort does). Conflating #2 and #3 means a custom compiler/IR which has high engineering costs (ABI boundaries, hard to debug/profile/sanitize).
And doing #3 at runtime (JIT), or moving fusions into #3 (MLIR), vastly complicates the compiler. We can still get runtime adaptability thanks to Highway's multi-target support. Fusion has been much easier to implement manually for LLMs than to construct a general fusion infrastructure. Templates hide most data type differences and we see 2-5x speedup vs llama.cpp for 128k prefill+batch decode on Zen5.
Instead of requiring a compiler to do heroic transforms at runtime, and get it right every time, we can do all kinds of agentic exploration, then verify the result/approach, check in the source code, then we 'just' have a C++ compiler afterwards. And if/when something breaks, it's easy to update centrally, in code we can modify directly, rather than indirectly via updating a compiler.
several years ago, using 6 threads and vectorized C++, we saw about 240-270 MP/s decode speed. Hence this should be possible in < 100ms. Not sure how the current implementation differs from that state :)
CPU power is proportional to frequency^2. Running on 4-6 little/efficiency cores (which are widespread on mobile) is likely faster than one big core, and uses less energy.
There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles.
Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images.
JPEG XL ensures this information is always available.
- Upload the problematic image to the AOM analyzer
- Press 'L' to show tiles view
- How many tiles (yellow rectangles) do you count?
- Are artifacts actually at those tile borders?
I was even more surprised & disappointed to see this dismissed as an ad for my company. Think about how fantastic JPEG XL would be for my company: an image codec with tons of fans and an extremely weak reference encoder? Sign me up. I'm writing this as someone who wants a better Internet.
If you're sensitive to tiling artifacts, you must deeply dislike the way JPEG XL images look. Every block of a JPEG XL image is effectively a small tile, because there is no deblocking loop filter (I talk about this in the article).
JPEG XL has two filters that are pretty much equivalents of what AVIF has, while AVIF has three; plus, tile boundaries are handled by the DLF. Your point doesn't really stand on two legs if it means to come to JPEG XL's defense here.
By "small", it's meant in a relative sense. JXL's coded blocks can be as big as 64x64, and block boundaries can create visible seams. Example: https://juliobbv.com/pics/photo.jxl
These seams are especially noticeable in the background, and align with coded block edges. You can tell the encoder is trying to conceal them as best as it can, but this cannot be properly mitigated without a proper deblocking filter.
For comparison, AV1 tiles normatively go through the deblocking filter.
I participated in the design of those filters, so no, I do not deeply dislike the way they look.
This gaslighting is not convincing. No matter how many filters AVIF has, I distinctly remember tile artifacts being particularly disturbing. More so than individual blocks, whose size and border effects differ; tiles are a straight line through the entire image.
JPEG XL does not have this problem because the design and codestream enables parallel decoding (thanks to per-group offsets encoded in the 'TOC'), hence does not require separate tiles.
I find it misleading to call AVIF's "up to four passes" "very flexible".
It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
> I find it misleading to call AVIF's "up to four passes" "very flexible".
Wow, what a way to misquote me. Let me repeat what I actually said:
> Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
So, I re-iterate progressive AVIF is flexible, because:
- Intermediate passes in AVIF can look as sharp or blurry as desired -- you don't have that kind of control with JXL
- Intermediate passes in AVIF can semantically be different from the final pass -- very useful if you want to add a "loading" mark to the non-final passes to inform the user the image is still loading
- The four pass limit is A GOOD THING, as you want an image format to have a reasonable worst-case upper bound on energy consumption due to sum of partial decoding + display refresh updates -- there's such a thing as having "too many passes", and uncapping the limit would be irresponsible
- You can absolutely do saliency encoding in AVIF, as AV1's inter-frame encoding naturally allows for it efficiently
Ah, an accusation of misquoting. I actually quoted your exact words minus "is" and "it supports".
I think we disagree on the degree of flexibility, for sure.
A cap on layers (under user/browser) absolutely makes sense, but 4 at the format level is quite limiting, especially if you want to spend some of them on salient regions.
I agree that's possible, but not that it's efficient. You'd waste a few KiB on encoding skip blocks - AVIF layers represent the whole image, whereas JPEG XL can efficiently encode and update at group level.
How flexible did Jake find AVIF progressive in 2025? [1]
"it seems pretty limited. Only particular scaling values are allowed, and 1/8 is the smallest. Supposedly, additional layers are possible[..], but whenever I tried this, the encoder would error out, or explode the file size to ~400 kB, even at lowest quality. I guess that's why it's marked 'experimental'."
> Intermediate passes in AVIF can semantically be different from the final pass
I'm not sure if you're aware of this or not but juliobbv is the developer that fixed progressive AVIF, he is fully aware of how it works and how AV1 works in general.
"You'd waste a few KiB on encoding skip blocks"
This tells me you don't know how codecs work... skip blocks are not expensive to code, they are very cheap.
Jake's blog post is outdated by the way, the progressive functionality is much more advanced than it was at that point in time because Julio worked on it.
My conservative estimate is that a few-MP image with all but a smallish region encoded using skip blocks will spend a few KiB on that. This is very expensive compared to sending only a bounding box, hence it is unattractive for purposes of updating small regions with a whole-image layer.
I am glad to hear AVIF progressive has improved. But note that my original comment was: I find it misleading to call AVIF's "up to four passes" "very flexible". I believe that stands: contrasting the flexibility of (purpose-built) JPEG XL vs. the fairly strict limitations (inherited from video) of AVIF, I am astonished anyone would still call the latter "very flexible" by comparison.
Hi, I'm the author of the article you're quoting. AVIF was limited at the time of writing, but has since seen massive improvements, including progressive support.
Sounds like some strong assumptions here, particularly a stable and non-metered connection.
Imagine fast scroll across an image gallery on a slow connection (including cell handovers).
Or range requests, where a service worker only downloads the header+preview portion, and when clicking on the image, no need to re-download that.
Or even a browser that truncates all images, to protect users who might visit a page with huge background images that blows through their prepaid data plan.
JPEG XL anticipated, and accommodates, these use cases.
reply