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

Chrome Jpegxl Issue Reopened

issues.chromium.org

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#51

Post by mort96 »

magicalhippo wrote: post #42
mort96 wrote: post #27

Earlier quoted context omitted.

HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level. I want JXL in web browsers, but without HDR support.

There's nothing stopping browsers from tone mapping[1] those HDR images using your tone mapping preference. [1]: https://en.wikipedia.org/wiki/Tone_mapping

What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect?

Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)

Re: Chrome Jpegxl Issue Reopened

#52

Post by fsflover »

claudiojulio wrote: post #3

[flagged]

This comment is of course breaking the HN Guidelines as a shallow dismissal, but the parent is right: After Google killed Ublock Origin and turned Android into a nanny OS, I have no idea why anyone would stick to anything from them. Also Firefox is better in almost every way.

Re: Chrome Jpegxl Issue Reopened

#53

Post by 12_throw_away »

wizee wrote: post #4

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support J…

> performant and memory safe decoder (in Rust?).

Isn't this exactly the case that wuffs [1] is built for? I had the vague (and, looking into it now, probably incorrect) impression that Google was going to start building all their decoders with that.

[1] https://github.com/google/wuffs

Re: Chrome Jpegxl Issue Reopened

#54

Post by greenavocado »

homebrewer wrote: post #13
wizee wrote: post #4

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support J…

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

"Marginal Gains"

Generation Loss – JPEG, WebP, JPEG XL, AVIF : https://www.youtube.com/watch?v=w7UDJUCMTng

Re: Chrome Jpegxl Issue Reopened

#55

Post by infinet »

magicalhippo wrote: post #46
homebrewer wrote: post #13

Earlier quoted context omitted.

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

> Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains On a slightly related note, I wanted to have a HDR background image in Windows 11. Should be a breeze in 2025 right? Well, Windows 11 only supports JPEG XR[1] for HDR background images. And my commonly used tools did either not support JPEG XR (Gimp fex) or they did not work correctly (ImageMagick). So I had a look at the J…

Another JPEG XR user is Zeiss. It saves both grayscale and color microscope images with JPEG XR compression in a container format. Zeiss also released a C++ library (libczi) using the reference JPEG XR implementation to read/write these images. Somehow Zeiss is moving away from JPEG XR - its newer version of microscope control software saves with zstd compression by default.

Re: Chrome Jpegxl Issue Reopened

#56

Post by bawolff »

lonjil wrote: post #31
homebrewer wrote: post #13

Earlier quoted context omitted.

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards-positions/pull/1064 avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). You also get it for basically free because it's just a…

I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported. Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web. > avif is just b…

> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported.

Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.

Re: Chrome Jpegxl Issue Reopened

#57

Post by [deleted] »

wizee wrote: post #4

JPEG-XL provides the best migration path for image conversion from JPEG, with lossless recompression. It also supports arbitrary HDR bit depths (up to 32 bits per channel) unlike AVIF, and generally its HDR support is much better than AVIF. Other operating systems and applications were making strides towards adopting this format, but Google was up till now stubbornly holding the web back in their refusal to support J…

[deleted]

Re: Chrome Jpegxl Issue Reopened

#58

Post by lonjil »

bigbuppo wrote: post #50
markdog12 wrote: post #2

"Yes, re-opening.". > Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

LOL. Google, the "yeah that thing we bought six months ago, we're killing it off 30 days for 4 weeks ago" company demanding "long-term" anything.

long term support is actually being provided by google...

just a different team in a different country :D

most jxl devs are at google research in zurich, and already pledged to handle long tetm support

Re: Chrome Jpegxl Issue Reopened

#59

Post by lonjil »

bawolff wrote: post #56
lonjil wrote: post #31

Earlier quoted context omitted.

I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported. Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web. > avif is just b…

> I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported. Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.

> If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it.

That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.

Re: Chrome Jpegxl Issue Reopened

#60

Post by lonjil »

hirako2000 wrote: post #45
bananalychee wrote: post #38

Earlier quoted context omitted.

Even though AVIF decoding support is fairly widespread by now, it is still not ubiquitous like JPEG/PNG/GIF. So typically services will store or generate the same image in multiple formats including AVIF for bandwidth optimization and JPEG for universal client support. Browser headers help to determine compatibility, but it's still fairly complicated to implement, and users also end up having to deal with different p…

Even Google photo does not support avif. It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.

Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.
Post reply on HN