Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JPEG XL Test Page

tildeweb.nl

Post reply on HN
Print view View original

81–90 of 170 posts

Re: JPEG XL Test Page

#81

Post by notatoad »

dylan604 wrote: post #66
flexagoon wrote: post #26

Earlier quoted context omitted.

I feel like "jpeg" has generally become a shorthand for "low quality compressed digital picture"

I feel like you need to find better places on the internet. It's no longer 1997 downloading from dial up.

What makes jpeg compression bad isn’t low bandwidth. It’s really good at compressing an image for that.

What makes jpeg bad is that the compression artifacts multiply when a jpeg gets screen captured and then re-encoded as a jpeg, or automatically resized and recompressed by a social media platform. And that definitely isn’t a problem that has gone away since dialup, people do that more than ever.

Re: JPEG XL Test Page

#82

Post by capitainenemo »

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?

Re: JPEG XL Test Page

#83

Post by quentindanjou »

judah wrote: post #51
uyzstvqs wrote: post #36

JPEG XL is also good, but why not use AVIF? It's widely supported by browsers, and rivals JPEG XL in being the best lossy image format.

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?

Re: JPEG XL Test Page

#84

Post by bigbuppo »

unglaublich wrote: post #22

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

And yet WEBP decided to associate itself with urine, which google then forced on everyone using their monopoly power.

Re: JPEG XL Test Page

#86

Post by bigbuppo »

flexagoon wrote: post #26
snowram wrote: post #25

Earlier quoted context omitted.

Considering "jpeg" has become the shorthand for "digital picture", it would be a shame not to capitalise on it.

I feel like "jpeg" has generally become a shorthand for "low quality compressed digital picture"

Nah, that's WEBP, the most hated file format.

Re: JPEG XL Test Page

#87

Post by dragonwriter »

Dwedit wrote: post #30
bobmcnamara wrote: post #27

Earlier quoted context omitted.

I found it unfortunate because it's not a JPEG.

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?

Re: JPEG XL Test Page

#88

Post by cubefox »

According to CanIUse, no browser implementation currently supports progressive decoding [1]. This is unfortunate, since progressive decoding theoretically is a major advantage of JPEG XL over AVIF, which doesn't allow it in principle, even though ordinary JPEG allows it. But apparently even a default (non-progressive) JPEG XL allows some limited form of progressive decoding [2]. It's unclear whether browsers support it though.

1: https://caniuse.com/jpegxl

2: https://youtube.com/watch?v=inQxEBn831w

Re: JPEG XL Test Page

#90

Post by kps »

amarant wrote: post #75
wmwragg wrote: post #65

Earlier quoted context omitted.

You probably want the JPEG XL Info[1] site then. A nice site outlining what JPEG XL actually is. [1] https://jpegxl.info/

While I get why, it bugs me that they have comparison images between jxl and other formats, yet it doesn't actually use jxl, as evidenced by all images displaying correctly on my chrome browser.

It uses jxl if the browser supports it, using ¹.

¹ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Post reply on HN