Articles about the merits of JPEG XL come up with some regularity on Hacker News, as if to ask, "why aren't we all using this yet?"<p>This one has a section on animation and cinemagraphs, saying that video formats like AV1 and HEVC are better suited, which makes sense. Here's my somewhat off-topic question: is there a video format that requires support for looping, like GIFs? GIF is a pretty shoddy format for video compared to a modern video codec, but if a GIF loops, you can expect it to loop seamlessly in any decent viewer.<p>With videos it seems you have to hope that the video player has an option to loop, and oftentimes there's a brief delay at the end of the video before playback resumes at the beginning. It would be nice if there were a video format that included seamless looping as part of the spec -- but as far as I can tell, there isn't one. Why not? Is it just assumed that anyone who wants looping video will configure their player to do it?
JPEG XL is three different codecs in one.<p>There is a lossless ultra-packer for existing JPEG files. It's completely reversible, you can get byte-for-byte identical JPEGs back.<p>Then there is "VarDCT" mode, which acts like JPEG, lossy Webp, or video codecs.<p>Then there is "Modular Mode", a completely different kind of codec that has different kinds of compression artifacts than JPEG-like codecs. The compression artifacts you see tend to be more like sections becoming more pixelated, or slight color differences. Strong edges don't have ringing artifacts. Modular mode mainly is used for lossless compression, but also allows lossy compression.
I believe JPEG XL is now supported in macOS 15 and iOS18.<p>edit: previous discussion about it
<a href="https://news.ycombinator.com/item?id=41598170">https://news.ycombinator.com/item?id=41598170</a>
This article is from 2020. I think so far it has aged reasonably well.
But you might be interested in my more recent articles too. You can find those here: <a href="https://cloudinary.com/blog/author/jon_sneyers" rel="nofollow">https://cloudinary.com/blog/author/jon_sneyers</a>
I found this interesting note in the article:<p>> HEIC and AVIF can handle larger [than 35MP, 8MP respectively] images but not directly in a single code stream. You must decompose the image into a grid of independently encoded tiles, which could cause discontinuities at the grid boundaries. [demo image follows].<p>The newest Fujifilm X cameras have HEIC support but also added 40MP sensors--does this mean they are having to split their HEIC outputs into two encoding grids?<p>It seems like the iPhone avoided this, as 48MP output is only available as a "ProRAW" i.e. RAW+JPEG, which previously used regular JPEG and now JPEG-XL, but never HEIC.
JPEG XL is supposed to be a progressive mode. Can you read a lower resolution from the file by reading only part of the file, as you can with JPEG 2000? Is there a header which tells you how much file to read for the desired resolution?
Something seems wrong im this article.
The side-by-side comparison shows 4 formats:<p><pre><code> · Original PNG image (2.6 MB)
· Name "high_fidelity.png", but in fact 298.840 bytes and format: JPEG
· JPEG XL (default settings, 53 KB): indistinguishable from the original
· Name "high_fidelity.png.jxl.png", but in fact 3.801.830 bytes and format: PNG
· WebP (53 KB): some mild but noticeable color banding along with blurry text
· Name "high_fidelity_webp.png", but in fact 289.605 bytes and format PNG
· JPEG (53 KB): strong color banding, halos around the text, small text hard to read
· Name "jpeg_high_fidelity.jpg", but in fact 52.911 bytes and format JPEG
</code></pre>
The comparison does not make any sense,
everything is just wrong. Also when encoding the large original PNG image to AVIF, it has only 20.341 Bytes with no visual change, see: <a href="http://intercity-vpn.de/files/2024-10-27/upload/" rel="nofollow">http://intercity-vpn.de/files/2024-10-27/upload/</a>
JPEG XL is seeing strong industrial adoption where image quality matters: professional and prosumer image acquisition (as a replacement, with huge benefits, of traditional raw imaging in iPhone 16 Pro) and processing and storage reduction with Digital Negative, ProRAW and medical imaging with DICOM. Clinics with archiving and telemedicine needs benefit massively.
Few realise that JPEG was designed for flickery low resolution analogue CRTs and slow CPUs. Nowadays we have digital high resolution screens and fast CPUs.<p>JPEG XL has been coming soon for as long as I can remember.<p>Nowadays I like to serve webP from a CDN with the filenames being .jpg even though it is a .webp. This means listening to the request headers and serving what is supported.<p>If someone right clicks and downloads then they get a genuine JPEG, not a webp. Same if they do a 'wget'. This is because the headers are different, with webp not supported.<p>Browsers do not care about filename extensions. Hence you can serve a webP as 'example.jpg'.<p>The benefits of doing this, and having the CDN send the request headers to the origin server (for it to encode webp on the fly) is that the rest of the team, including those that upload images can work entirely in the JPG space they know.<p>The mozjpeg encoder is really neat but all browsers support webp these days. Mozjpeg is JPEG for digital hi-res screens and fast CPUs. Brilliant, but too late.<p>What I am interested in now is larger colour spaces than sRGB. This requires a whole toolchain that supports P3 (or whatever) too.<p>I tried AVIF but in practical testing, webP was simply better.<p>JPEGLI from Google is what I want for the toolchain with the CDN supplying webp. Nobody cares about your images in the vast majority of applications and it is just best to go for highly compressed webp with artefacts just about to cut in. You also have retina nowadays, so using all those pixels, typically 1.5x, is better than 1x. More pixels is a better trade off.
I investigated using JPEG XL for high speed applications but encoding time was much slower than JPEG with libturbojpeg even if you reduce encoder complexity to a minimum
> The JPEG XL reference encoder (cjpegxl) produces, by default, a well-compressed image that is indistinguishable from (or, in some cases, identical to) the original. In contrast, other image formats typically have an encoder with which you can select a quality setting, where quality is not really defined perceptually.<p>We are the best, so fuck the rest. /s<p>Using vague language to claim superiority is not a sign of inteligence.