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

31–40 of 144 posts

Re: Chrome Jpegxl Issue Reopened

#31

Post by lonjil »

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…

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 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).

AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that.

And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.

Re: Chrome Jpegxl Issue Reopened

#32

Post by robertoandred »

crote wrote: post #26
asadotzler wrote: post #25

Earlier quoted context omitted.

If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.

People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG. Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.

> Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.

That’s a function of the website, not the browser.

Re: Chrome Jpegxl Issue Reopened

#33

Post by lonjil »

kllrnohj wrote: post #14
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…

> 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.

Re: Chrome Jpegxl Issue Reopened

#34

Post by lonjil »

Dwedit wrote: post #24
F3nd0 wrote: post #21

Earlier quoted context omitted.

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…

Having a PNG go from 164.5K to 127.1K as lossless WEBP is not what I'd call "marginal". An improvement of over 20% is huge for lossless compression. Going from lossless WEBP to lossless JXL is marginal though, and is not worth the big decode performance loss.

Since the person you replied to mentioned MozJPEG, I have to assume they meant that WebP's lossy capabilities were a marginal improvement.

Re: Chrome Jpegxl Issue Reopened

#35

Post by wizee »

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…

I disagree about the image quality at typical sizes - I find JPEG-XL is generally similar or better than AVIF at any reasonable compression ratios for web images. See this for example: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/

AVIF only comes out as superior at extreme compression ratios at much lower bit rates than are typically used for web images, and the images generally look like smothered messes at those extreme ratios.

Re: Chrome Jpegxl Issue Reopened

#36

Post by nandomrumber »

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?

Maybe more like a heading bug:

https://aviation.stackexchange.com/questions/23166/what-is-t...

Re: Chrome Jpegxl Issue Reopened

#37

Post by jyoung8607 »

robertoandred wrote: post #32
crote wrote: post #26

Earlier quoted context omitted.

People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG. Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.

> Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular. That’s a function of the website, not the browser.

> That’s a function of the website, not the browser.

That's hand-waving away quite a lot. The task changes from serving a copy of a file on disk, as every other image format in common use, to needing a transcoding pipeline more akin to sites like YouTube. Technically possible, but lots of extra complexity in return for what gain?

Re: Chrome Jpegxl Issue Reopened

#38

Post by bananalychee »

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…

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 platforms supporting different formats when they are served WebP or AVIF and want to reupload an image somewhere else that does not like those formats. As far as I can tell, JXL solves that issue for most websites since it is backwards-compatible and can be decoded into JPEG when a client does not support JXL. I would happily give up a few percent in compression efficiency to get back to a single all-purpose lossy image format.

Re: Chrome Jpegxl Issue Reopened

#39

Post by tempest_ »

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.

Re: Chrome Jpegxl Issue Reopened

#40

Post by [deleted] »

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…

[deleted]
Post reply on HN