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

Google Revisits JPEG XL in Chromium After Earlier Removal

windowsreport.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#81

Post by [deleted] »

oktoberpaard wrote: post #73
fingerlocks wrote: post #55

Earlier quoted context omitted.

I never mentioned a file format. These operations are performed on the raw buffer, there is no hack. There is no minimum bit depth for HDR (except for maybe 2) that’s just silly. High dynamic range images just remap the physical light waves to match human perception, but collecting those waves can be done at any resolution or bit depth. I wrote camera firmware. I’ve implemented HDR on the both the firmware level, and…

What you are taking about is also called HDR, but has nothing to do with what the other person is talking about. The other person is talking about the still image equivalent of HDR video formats. When displayed on an HDR capable monitor, it will map the brightest parts of the image to the extended headroom of the monitor instead of tone mapping it to be displayed on a standard SDR monitor. So to be even more clear: i…

[deleted]

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#82

Post by fingerlocks »

oktoberpaard wrote: post #73
fingerlocks wrote: post #55

Earlier quoted context omitted.

I never mentioned a file format. These operations are performed on the raw buffer, there is no hack. There is no minimum bit depth for HDR (except for maybe 2) that’s just silly. High dynamic range images just remap the physical light waves to match human perception, but collecting those waves can be done at any resolution or bit depth. I wrote camera firmware. I’ve implemented HDR on the both the firmware level, and…

What you are taking about is also called HDR, but has nothing to do with what the other person is talking about. The other person is talking about the still image equivalent of HDR video formats. When displayed on an HDR capable monitor, it will map the brightest parts of the image to the extended headroom of the monitor instead of tone mapping it to be displayed on a standard SDR monitor. So to be even more clear: i…

Even when HDR tone mapping in real time, such as a game engine or raw video feed, you would still be merging two or four multi-sampled tile memory blocks into a single output image. This is not fundamentally different, just a fancier pipeline on modern GPUs. And it’s completely unrelated to OPs rant about stupid developers preventing them for sharing their HDR images or whatever.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#83

Post by spartanatreyu »

Nanopolygon wrote: post #76
ksec wrote: post #30

While being a big supporter of JPEG-XL on HN, I just want to note AV2 is coming out soon, which should further improve the image compression. ( Edit: Also worth pointing out current JPEG-XL encoder is no where near its maximum potential in terms of quality / compression ratio ) But JPEG-XL is being quite widely used now, from PDF, medical images, camera lossless, as well as being evaluated in different stage of cinem…

AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.

> But AVIF provides better image quality than JXL even at lower settings.

I don't think that's strictly true.

The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings.

However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonisagrista.com/blog/2023/jpegxl-vs-avif/)

Even at the point where AVIF should shine: when low bandwidth is important, JXL supports progressive decoding (AVIF is still trying to add this) so the user will see the images sooner with JXL rather than AVIF.

---

There is one part where AVIF does beat JXL hands down, and that's animation (which makes sense considering AVIF comes from the modern AV1 video codec). However, any time you would want an animation in a file, you're better off just using a video codec anyway.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#84

Post by ksec »

spartanatreyu wrote: post #83
Nanopolygon wrote: post #76

Earlier quoted context omitted.

AVIF/AV1 is a codec that encodes both lossy and lossless files very slowly. JXL is significantly faster than AVIF. But AVIF provides better image quality than JXL even at lower settings. However, AV2 will require much more power and system resources for a small bandwidth gain.

> But AVIF provides better image quality than JXL even at lower settings. I don't think that's strictly true. The conventional reporting has been that JXL works better at regular web sizes, but AVIF starts to edge out at very low quality settings. However, the quality per size between the two is so close that there are comparisons showing JXL winning even where AVIF is supposed to out perform JXL. (e.g. https://tonis…

To be fair, those comparison image size aren't small enough. Had it been 30 - 50% of those tested size AVIF should have the advantage.

But then the question is should we even be presenting this level of quality. Or is it enough. I guess that is a different set of questions.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#85

Post by Ukv »

nothrabannosir wrote: post #71
crazygringo wrote: post #61

Earlier quoted context omitted.

I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more impor…

Legacy. It’s how things used to be done. Just like Unix permissions, shared filesystem, drive letters in the file system root, prefixing urls with the protocol, including security designators in the protocol name… Be careful to ascribe reason to established common practices; it can lead to tunnel vision. Computing is filled with standards which are nothing more than “whatever the first guy came up with”. https://en.w…

If the alternative was putting the information in some hypothetical file attribute with similar or greater level of support/availability (like for filtering across various search engines and file managers) then I'd agree there's no reason to keep it in the file extension in particular, but I feel the alternative here is just not really having it available in such a way at all (instead just an internal tag particular to the JXL format).

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#86

Post by GuB-42 »

JyrkiAlakuijala wrote: post #6
free_bip wrote: post #4

Earlier quoted context omitted.

It's a huge piece for sure, but not the only one. For example, Firefox and Windows both don't support it out of the box currently. Firefox requires nightly or an extension, and on Windows you need to download support from the Microsoft store.

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

Brotli? Is it still relevant now that we have Zstandard?

Zstandard is much faster in just about every benchmark, sometimes Brotli has a small edge when it comes to compression ratio, but if you go for compression ratio over speed, LZMA2 beats them both.

Both Zstandard (zstd) and LZMA2 (xz) are widely supported, I think better supported than Brotli outside of HTTP.

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#87

Post by JyrkiAlakuijala »

GuB-42 wrote: post #86
JyrkiAlakuijala wrote: post #6

Earlier quoted context omitted.

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

Brotli? Is it still relevant now that we have Zstandard? Zstandard is much faster in just about every benchmark, sometimes Brotli has a small edge when it comes to compression ratio, but if you go for compression ratio over speed, LZMA2 beats them both. Both Zstandard (zstd) and LZMA2 (xz) are widely supported, I think better supported than Brotli outside of HTTP.

Brotli decompresses 3-5x faster than LZMA2 and is within 0.6 % of the compression density, and much better for short documents.

ZStandard decompresses ~2x faster than Brotli but is 5 % less dense in compression density, and even less dense for short documents or documents where the static dictionary can be used.

Brotli is not slow to decompress -- generally a little faster then deflate through zlib.

Last time I measured, Brotli had ~2x smaller binary size than zstd (dec+enc).

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#88

Post by alwillis »

jchw wrote: post #7
JyrkiAlakuijala wrote: post #6

Earlier quoted context omitted.

Would PDF 2.0 (which also depends JPEG XL and Brotli) put pressure on Firefox and Windows to add more easy to use support?

I don't think so: JPEG 2000, as far as I know, isn't generally supported for web use in web browsers, but it is supported in PDF.

> I don't think so: JPEG 2000, as far as I know, isn't generally supported for web use in web browsers, but it is supported in PDF.

Safari supported JPEG 2000 since 2010 but removed support last year [1].

[1]: https://bugs.webkit.org/show_bug.cgi?id=178758

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#89

Post by account42 »

crazygringo wrote: post #61
stavros wrote: post #59

Earlier quoted context omitted.

Presumably you can look at the file and tell which mode is used, though why would you care to know from the filename?

I find it incredibly helpful to know that .jpg is lossy and .png is lossless. There are so many reasons why it's almost hard to know where to begin. But it's basically the same reason why it's helpful for some documents to end in .docx and others to end in .xlsx. It tells you what kind of data is inside. And at least for me, for standard 24-bit RGB images, the distinction between lossy and lossless is much more impor…

> .png is lossless

pngquant and similar tools disagree

Re: Google Revisits JPEG XL in Chromium After Earlier Removal

#90

Post by JyrkiAlakuijala »

mirsadm wrote: post #13
jiggawatts wrote: post #11

2026 is nearly upon us, and Google, Microsoft, and Apple remain steadfast in the refusal to ever allow anyone to share wide-gamut or HDR images. Every year, I go on a rant about how my camera can take HDR images natively, but the only way to share these with a wider audience is to convert them to a slideshow and make a Rec.2020 HDR movie that I upload to YouTube. It's absolutely bonkers to me that we've all collectiv…

It is incredibly annoying that instead of adopting JpegXL they decided to use UltraHDR. A giant hack which works very poorly.

JPEG XL supports UltraHDR.

JPEG XL's normal HDR capabilities were not harmed in the process when UltraHDR was added.

It was added for reaching parity with JPEG1 and HEIF/AVIF for the needs of UltraHDR developers and believers.

Post reply on HN