3 ms·

Will JPEG XL support return to Chrome? Apple supporting it surely has to be a signal to begin wider adoption!?

by firecall 2y ago

RedShift1 2y ago
Not unless Chrome starts having serious marketshare issues.
jmb99 2y ago
Apple’s supported JPEG2000 for years, but no one else does. I imagine the same will be the case for JPEG XL.
- cpeterso 2y ago
  Safari dropped support for JPEG 2000 in Safari 18 last month: https://webkit.org/blog/15865/webkit-features-in-safari-18-0/#deprecations https://webkit.org/blog/15865/webkit-features-in-safari-18-0...
- dvhh 2y ago
  One issue is that format support detection was iffy, compared to Jpeg XL where people knows to use the accept header to declare support format.
SoothingSorbet 2y ago
I don't know if Google has changed their position, but Mozilla is willing to accept a memory-safe (read: Rust) JXL decoder [1]. If it becomes used in Firefox, maybe there's a chance that Google would see the benefit in picking it up? [1] https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064
- GoblinSlayer 2y ago
  >100,000 lines of multithreaded C++ >potentially introduce memory safety vulnerabilities across the myriad of applications that would eventually need to support it Right, new code, new vulnerabilities.
theandrewbailey 2y ago
I recently wrote a script that encodes an image to fall within a size range[0]. After toying with it, I noticed that smaller AVIF files are completely fine for web use, but identically sized JPEG XL files are not. Given ubiquitous browser support for AVIF[1], unless JPEG XL gets much better at smaller sizes, I reluctantly agree that Chrome's call to drop JPEG XL is the right one. [0] https://gist.github.com/theandrewbailey/4e05e20a229ef2f2c1f9a6d0e326ec2a https://gist.github.com/theandrewbailey/4e05e20a229ef2f2c1f9... [1] https://caniuse.com/avif https://caniuse.com/avif
- chronogram 2y ago
  In what environment do you work where you need such low quality images though? In my web environment I only want the highest quality I can get at a reasonable size and I've never been interested in slightly less awful looking tiny images. In another comment I wrote about using jpegli at its default distance of 1 for everything and being happy with that size, so maybe I work in a completely different environment to you.
  - theandrewbailey 2y ago
    A normal one like everyone else I guess. No need to waste bandwidth and storage if you don't have to. If an image looks good to me, I'll try going lower until it doesn't look good, then go back one step. I've been surprised many times by just how low it can go and still look good. That script I wrote defaults to what I've settled on. (AVIF between 0.5 and 1 bpp at 1 megapixel, increasing or decreasing by square root of total pixels in image, plus JPEG fallback.) If I change my mind, I keep high resolution originals of everything to do it again.

Will JPEG XL support return to Chrome? Apple supporting it surely has to be a signal to begin wider adoption!?

RedShift1 2y ago

Not unless Chrome starts having serious marketshare issues.

jmb99 2y ago

Apple’s supported JPEG2000 for years, but no one else does. I imagine the same will be the case for JPEG XL.

cpeterso 2y ago
Safari dropped support for JPEG 2000 in Safari 18 last month: https://webkit.org/blog/15865/webkit-features-in-safari-18-0/#deprecations https://webkit.org/blog/15865/webkit-features-in-safari-18-0...
dvhh 2y ago
One issue is that format support detection was iffy, compared to Jpeg XL where people knows to use the accept header to declare support format.

SoothingSorbet 2y ago

I don't know if Google has changed their position, but Mozilla is willing to accept a memory-safe (read: Rust) JXL decoder [1]. If it becomes used in Firefox, maybe there's a chance that Google would see the benefit in picking it up? [1] https://github.com/mozilla/standards-positions/pull/1064 https://github.com/mozilla/standards-positions/pull/1064

GoblinSlayer 2y ago
>100,000 lines of multithreaded C++ >potentially introduce memory safety vulnerabilities across the myriad of applications that would eventually need to support it Right, new code, new vulnerabilities.

theandrewbailey 2y ago

I recently wrote a script that encodes an image to fall within a size range[0]. After toying with it, I noticed that smaller AVIF files are completely fine for web use, but identically sized JPEG XL files are not. Given ubiquitous browser support for AVIF[1], unless JPEG XL gets much better at smaller sizes, I reluctantly agree that Chrome's call to drop JPEG XL is the right one. [0] https://gist.github.com/theandrewbailey/4e05e20a229ef2f2c1f9a6d0e326ec2a https://gist.github.com/theandrewbailey/4e05e20a229ef2f2c1f9... [1] https://caniuse.com/avif https://caniuse.com/avif

chronogram 2y ago
In what environment do you work where you need such low quality images though? In my web environment I only want the highest quality I can get at a reasonable size and I've never been interested in slightly less awful looking tiny images. In another comment I wrote about using jpegli at its default distance of 1 for everything and being happy with that size, so maybe I work in a completely different environment to you.
- theandrewbailey 2y ago
  A normal one like everyone else I guess. No need to waste bandwidth and storage if you don't have to. If an image looks good to me, I'll try going lower until it doesn't look good, then go back one step. I've been surprised many times by just how low it can go and still look good. That script I wrote defaults to what I've settled on. (AVIF between 0.5 and 1 bpp at 1 megapixel, increasing or decreasing by square root of total pixels in image, plus JPEG fallback.) If I change my mind, I keep high resolution originals of everything to do it again.