janwas

This was indeed what the JPEG XL effort started with :) The Butteraugli metric.

We pioneered this in Highway and shared some advice on the API. Great to see this decision taken :D

:) Yeah, those are best copy-pasted from existing code.

I do think we've converged on the best that's possible in C++.

+1 on agents making library/DIY a lot more attractive than bespoke compilers.

In C++, one can also have portable intrinsics plus simpler runtime dispatching using our Highway library :)

(Co-)author here :)

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.

> This tells me you don't know how codecs work

Laughable.

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.

Not at all.

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.

I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot.

As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanced and absolutist if intended to apply to everyone.

When on a train with spotty wifi or frequent tunnels, I would actually prefer to see whatever arrived. Someone on prepaid data might want to truncate at ~100 KB, no matter what the website owner or browser PM thought.

We can agree on wanting a better internet :)

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.