Hacker News Reader

Comment by pmarreck | Hacker News Reader

JPEG-XL is not particularly patent-laden and its license is correct for the use-case.

Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.

It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.

And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)

iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).

View on HN

I think the bigger driver is that, due to it being the next PDF image format, most platforms will already be forced to add some form of support to it.

When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.

> you just truncate the output stream at the right proportion of pixel data

Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?

That doesn’t seem related to the codec itself but rather how you fetch said image.

Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.

Yes, but figuring out the "5% of the file or whatever" is the hard part!

Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.

If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.

This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.

I’ll be honest, I don’t know the ins and outs of the protocol, maybe the breakpoints are annotated in a way that would be trivial for the server to generate a proper srcset, but that is still a worst case implementation IMO: since the browser would likely redownload the initial bytes during viewport changes and when expanding a image from a thumbnail because all it can see is a different URL so “it is a different file”.

I believe it would be useful to have some browser API so that in the end users could even dial how much resolution they want from images (just because one has a retina display doesn’t mean one wants to pay the bandwidth price).

Knowing where to truncate before you get there is related to the codec itself. Can I figure out where the quarter resolution data ends from the header alone?

> due to it being the next PDF image format

Oh, they finally ratified that? Excellent. This is news to me. You have a link?

JPEG XL decoder complexity is propaganda.

JPEG XL decoder is smaller in kloc than zlib+libpng. About 35 kloc vs 20+20 kloc.

>JPEG-XL is not particularly patent-laden and its license is correct for the use-case.

The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.

> Apple refused to support it because they wanted to patent-laden alternative to thrive.

Where do people get this stuff?

Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.

Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.

WebP is ubiquitous now, not the case in 2010 when it was released.

It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.

Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.

> it doesn't support wide gamut color

That's wrong, you declare this with an ICC profile, done.

Lossy WebP has an important limitation in being YUV 4:2:0. And it's strictly 8-bit. That is the actual reason it doesn't replace JPEG, which is rarely even implemented to a greater extent.

Lossless WebP replaces GIF. Despite much better compression, it doesn't replace PNG, which supports 16 bits, and has stronger metadata support.

WebP is limited to 8 bits per pixel, a total of 16,777,216 colors; adding a ICC profile doesn’t change that.

JPEG XL and the other modern formats can support at least 10-bits per pixel, that's over a billion colors.

AVIF supports 12-bits per pixel; JPEG XL [1] can support up to 32-bits per pixel.

[1]: https://en.wikipedia.org/wiki/Comparison_of_graphics_file_fo...

.webm is a video standard. Its completely different than webp

Can progressive loading be made less fine-grained? With too many levels you don't know, if image is still loading or is just low-res.

Loading vs loaded difference needs to be clear.

AFAIK that's just a case of choosing how many scans to use at encode time

Thanks! This may be the solution I'm looking for.

The problem with progressive rendering is that the user never knows when downloading is complete unless you add loaders to each image.

> you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)

It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.

How would that work in an attack?

For serious, general purpose programs when thumbnails are shown people expect them to correspond to the full images, and not something else. Windows explorer, android gallery, gnome file picker etc can't show made-up thumbnails, or people would send or delete the wrong images, or would have no idea what images do they actually have.

png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.

I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.

I believe the image would need to be present in the full size image, so I think that would limit to some extent the attack vector, but I don't know how far you could push it.

Reply on news.ycombinator.com