JPEG XL Test Page • Hacker News Board

Re: JPEG XL Test Page

#101

Post by michaelt » Wed, Jan 21, 2026, 9:18 PM UTC

quentindanjou wrote: post #83

judah wrote: post #51

Earlier quoted context omitted.

Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0]. > "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just s…

I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?

Taking advantage of hardware decoding is generally like pulling teeth.

For video you can't avoid it, as people expect several hours of laptop battery life while playing video. But for static images - I'd avoid the pain.

Re: JPEG XL Test Page

#102

Post by capitainenemo » Wed, Jan 21, 2026, 9:19 PM UTC

capitainenemo wrote: post #82

numbers wrote: post #76

I'm seeing the image on zen which is a firefox fork but not on firefox itself :/ even with `image.jxl.enabled` I don't see it on firefox

Checking the Firefox bugs on this, it seems they decided to replace the C++ libjxl with a rust version which is a WIP, to address security concerns with the implementation. All this started a few months ago. Maybe the zen fork is a bit older and still using the C++ one?

... update. after reading the comments in the rust migration security bug, I saw they mentioned "only building in nightly for now"

I grabbed the nightly firefox, flipped the jxl switch, and it does indeed render fine, so I guess the rust implementation is functioning, just not enabled in stable.

... also, I see no evidence that it was ever enabled in the stable builds, even for the C++ version, so I'm guessing Zen just turned it on. Which... is fine, but maybe not very cautious.

Re: JPEG XL Test Page

#103

Post by Dwedit » Wed, Jan 21, 2026, 10:00 PM UTC

dragonwriter wrote: post #87

Dwedit wrote: post #30

Earlier quoted context omitted.

It has an operation mode where it can losslessly and reversibly compress a JPEG further, and "not a jpeg" wouldn't cover that.

JPEG XL is the thing that makes your JPEG smaller?

JPEG XL is basically 4 codecs in one...

* A new lossy image Codec

* A lossless image codec (lossless modular mode)

* An alternative lossy image codec with different kinds of compression artifacts than those typically seen in JPEG (lossy modular mode)

* JPEG packer

Because it includes a JPEG packer, you can use it as such.

Re: JPEG XL Test Page

#104

Post by awestroke » Wed, Jan 21, 2026, 10:07 PM UTC

capitainenemo wrote: post #102

capitainenemo wrote: post #82

Earlier quoted context omitted.

Checking the Firefox bugs on this, it seems they decided to replace the C++ libjxl with a rust version which is a WIP, to address security concerns with the implementation. All this started a few months ago. Maybe the zen fork is a bit older and still using the C++ one?

... update. after reading the comments in the rust migration security bug, I saw they mentioned "only building in nightly for now" I grabbed the nightly firefox, flipped the jxl switch, and it does indeed render fine, so I guess the rust implementation is functioning, just not enabled in stable. ... also, I see no evidence that it was ever enabled in the stable builds, even for the C++ version, so I'm guessing Zen ju…

zen browser is pretty much vibe coded

Re: JPEG XL Test Page

#105

Post by sanjit » Wed, Jan 21, 2026, 10:16 PM UTC

RicoElectrico wrote: post #39

p_ing wrote: post #2

Orion, and presumably other Webkit-based browsers that are actually up-to-date, can also see the image. Hopefully my photo processor will accept JPEG XL in the near future!

> Hopefully my photo processor will accept JPEG XL in the near future! Aren't print shops, machining shops, other small manufacturers etc. ones that always lag behind with emerging technologies?

Designers might also be hesitant to use an untested file format for print, too.

If there’s a large amount of paper that’s been purchased for a job, I definitely wouldn’t want to be the one who’s responsible for using JPEG XL and – for whatever reason – something going wrong.

Pixels are cheaper than paper or other physical media :)

Re: JPEG XL Test Page

#106

Post by pkulak » Wed, Jan 21, 2026, 10:17 PM UTC

senfiaj wrote: post #95

Starting from v145 Chrome supports JXL. There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...

And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/

Re: JPEG XL Test Page

#107

Post by pkulak » Wed, Jan 21, 2026, 10:22 PM UTC

p_ing wrote: post #2

Orion, and presumably other Webkit-based browsers that are actually up-to-date, can also see the image. Hopefully my photo processor will accept JPEG XL in the near future!

Yup, Gnome Web loads it just fine! Man, it really is a great browser. I try to switch to it every 6 months, but then I remember that it doesn't support extensions at all. I could give up everything, but not 1Password. Nothing is worth copy/pasting credentials and losing passkeys entirely.

Re: JPEG XL Test Page

#108

Post by gcr » Wed, Jan 21, 2026, 10:23 PM UTC

HlessClaudesman wrote: post #42

unglaublich wrote: post #22

I think JPEG XL's naming was unfortunate. People want to associate new image formats with leanness, lightness, efficiency.

Crappy as a .jpg, only bigger. Actually, I remember when JPEG XL came out, and I just thought: cool, file that one away for when I have a really big image I need to display. Which turned out to be never. Names have consequences.

I regularly work with images larger than 65,535px per side.

WEBP can only do 16,383px per side and the AVIF spec can technically do 65,535, but encoders tap out far before then. Even TIFF uses 32-bit file offsets so can't go above 4GB without custom extensions.

Guess which format, true to its name, happens to support 1,073,741,823px per side? :-)

Re: JPEG XL Test Page

#109

Post by dietr1ch » Wed, Jan 21, 2026, 10:27 PM UTC

numbers wrote: post #76

I'm seeing the image on zen which is a firefox fork but not on firefox itself :/ even with `image.jxl.enabled` I don't see it on firefox

Flipping `image.jxl.enabled` made it work for me after refreshing the page. I'm using Librewolf 146.0.1-1, but I guess it works just fine in firefox 146

Re: JPEG XL Test Page

#110

Post by gcr » Wed, Jan 21, 2026, 10:43 PM UTC

One thing I like about JPEG-XL is that it supports all kinds of weird image formats.

For example, I used to work with depth data a lot, which is best expressed as monochrome 16-bit floating point images. Previously, TIFF was the only format that supported this. Many shops would instead save depth images as UINT16 .PNG files, where the raw pixel intensity maps to the camera distance in mm. The problem with this is that pixels more than 65.535 meters away aren't representable. (Hot take: I personally think this is one reason why nobody studies depth estimation for outdoor scenes.)

JPEG-XL supports more weird combinations here, e.g. storing greyscale float32 images (with alpha even! you can store sparse depth maps without needing a separate mask!)

It's like, uniquely suited to these sorts of 3D scene understanding challenges and I really hope people adopt the format for more scientific applications.