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

41–50 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#41

Post by kllrnohj »

lonjil wrote: post #33
kllrnohj wrote: post #14

Earlier quoted context omitted.

> and generally its HDR support is much better than AVIF Not anymore. JPEG had the best HDR support with ISO 21496-1 weirdly enough, but AVIF also just recently got that capability with 1.2 ( https://aomedia.org/blog%20posts/Libavif-Improves-Support-fo... ). The last discussion in libjxl about this was seemingly taking the stance it wasn't necessary since JXL has "native HDR" which completely fails to understand the…

The JXL spec already has gainmaps... Also, just because there's a spec for using gainmaps with JPEG doesn't mean that it works well. With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding. JXL otoh is completely immune to banding, with or without gainmaps.

> With only 8 bits of precision, it really sucks for HDR, gainmap or no gainmap. You just get too much banding.

This is simply not true. In fact, you get less banding than you do with 10-bit bt2020 PQ.

> JXL otoh is completely immune to banding

Nonsense. It has a lossy mode (which is its primary mode so to speak), so of course it has banding. Only lossless codecs can plausibly be claimed to be "immune to banding".

> The JXL spec already has gainmaps...

Ah looks like they added that sometime last year but decided to call it "JHGM" and also made almost no mention of this in the issue tracker, and didn't bother updating the previous feature requests asking for this that are still open.

Re: Chrome Jpegxl Issue Reopened

#42

Post by magicalhippo »

mort96 wrote: post #27
ansgri wrote: post #18

Earlier quoted context omitted.

Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!

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

Re: Chrome Jpegxl Issue Reopened

#43

Post by halapro »

F3nd0 wrote: post #21
Pxtl wrote: post #10

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and exp…

If I remember correctly, WebP was single-handedly forced into adoption by Chrome, while offering only marginal improvements over existing formats. Mozilla even worked on an improved JPEG encoder, MozJPEG, to show it could compete with WebP very well. Then came HEIF and AVIF, which, like WebP, were just repurposed video codecs. JPEG XL is the first image format in a long while that's been actually designed for images…

You're not being fair. Webp has been the only choice for lossy image compression with alpha layer. Give it some credit.

Re: Chrome Jpegxl Issue Reopened

#44

Post by Pxtl »

tempest_ wrote: post #39
Pxtl wrote: post #10

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and exp…

20% is massive for those storing those social media images though.

I get that there are people who are super excited by this for very good reasons, but for those of us downstream this is just going to be a hassle.

Re: Chrome Jpegxl Issue Reopened

#45

Post by hirako2000 »

bananalychee wrote: post #38
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…

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.

Re: Chrome Jpegxl Issue Reopened

#46

Post by magicalhippo »

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…

> 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 JPEG XR reference implementation, which was hosted on Codeplex but has been mirrored on GitHub[2]. And boy, I sure hope that isn't the code that lives in Windows 11...

Ok most of the gunk is in the encoder/decoder wrapper code, but still, for something that's supposedly still in active use by Microsoft... Though not even hosting their own copy of the reference implementation is telling enough I suppose.

[1]: https://en.wikipedia.org/wiki/JPEG_XR

[2]: https://github.com/4creators/jxrlib

Re: Chrome Jpegxl Issue Reopened

#47

Post by crazygringo »

albert_e wrote: post #20

> Chrome Jpegxl Issue Reopened > (this is the tracking bug for this feature) Is it just me -- or it's confusing to use the terms issue / bug / feature interchangeably?

Not really -- they're all "potential todos" that need to be tracked and prioritized in the same place.

And the difference between a bug and a feature is often in the eye of the beholder. I'll very often title a GitHub issue with "Bug/Feature Request:" since it's often debatable whether the existing behavior was by design or not, and I don't want to presume one way or the other.

So I do consider them all pretty interchangeable at the end of the day, and therefore not really confusing.

Re: Chrome Jpegxl Issue Reopened

#48

Post by 7jjjjjjj »

Pxtl wrote: post #10

> Lossless JPEG recompression (byte-exact JPEG recompression, saving about 20%) for legacy images Lossless recompression is the main interesting thing on offer here compared to other new formats... and honestly with only 20% improvement I can't say I'm super excited by this, compared to the pain of dealing with yet another new image format. For example, ask a normal social media user how they feel about .webp and exp…

I think there's a difference here.

If I right click save and get a webp, it was probably converted from JPG. Very very few images are uploaded in webp. So getting a webp image means you've downloaded an inferior version.

JXL doesn't have this issue because conversion from jpeg is lossless. So you've still gotten the real, fully-quality image.

Re: Chrome Jpegxl Issue Reopened

#50

Post by bigbuppo »

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.
Post reply on HN