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

▲

crote 3 hours ago | parent | next [-]

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?

	▲	yangm97 2 hours ago \| parent [-]
		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.

▲

weberer 3 hours ago | parent | prev | next [-]

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

	▲	alwillis 37 minutes ago \| parent [-]
		> 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.

▲

bmacho 42 minutes ago | parent | prev | next [-]

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

▲

zigzag312 an hour ago | parent | prev | next [-]

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.

	▲	youngtaff 42 minutes ago \| parent [-]
		AFAIK that's just a case of choosing how many scans to use at encode time

▲

esafak an hour ago | parent | prev [-]

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