upvote
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?

reply
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.

reply
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?
reply
>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.

reply
> 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.

reply
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.

reply
AFAIK that's just a case of choosing how many scans to use at encode time
reply
> 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.

reply
How would that work in an attack?
reply
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.

reply
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
The problem with progressive rendering is that the user never knows when downloading is complete unless you add loaders to each image.
reply