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

The case for JPEG XL

cloudinary.com

Post reply on HN
Print view View original

11–20 of 210 posts

Re: The case for JPEG XL

#11

Post by Nathanba »

eslaught wrote: post #6
sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

I was a little surprised about AVIF, so I looked it up and it doesn't seem to be quite there yet (though it's getting there). macOS Safari requires Ventura, and no support yet on Edge. https://caniuse.com/avif

that looks really nice, very sad that Edge chooses to go another route here. They use chromium code... if Edge starts supporting AVIF I'll start using AVIF.

Re: The case for JPEG XL

#13

Post by lifthrasiir »

Nathanba wrote: post #7

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Pers…

Chromium is an extremely large C++ code base and I don't think they would reject libjxl only for that reason. That said, as an author of the first significant reimplementation of JPEG XL format (J40), I think a Rust decoder would be a good addition to the format and has a long-term plan to make one [1].

[1] https://github.com/lifthrasiir/j40/issues/10

Re: The case for JPEG XL

#14

Post by hypothesis »

Nathanba wrote: post #7

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Pers…

This is a valid argument, but which of the contenders are using Rust or similar security minded languages?

WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…

Re: The case for JPEG XL

#15

Post by gardaani »

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding.

Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

Re: The case for JPEG XL

#17

Post by nine_k »

The scoop: a JPEG XL developer explains how JPEG XL is uniquely better than AVIF, webP, and PNG, and laments the Chrome team's decision to drop the experimental support for it.

AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.

Re: The case for JPEG XL

#19

Post by hypothesis »

On one hand numbers do not mean much, but I think that releasing a 1.0 version of official library would at least help with morale and signal some completeness.

I’m sure there are reasons making fresh 0.x releases even after creating a standard format, but it was a bit disappointing after years of waiting, even before this blow by certain browser maker.

Re: The case for JPEG XL

#20

Post by nine_k »

plantain wrote: post #4
sedatk wrote: post #3

Browser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all

JPEG-XL is already implemented in ~95% of browsers in the wild (Chrome, Edge, Opera and Firefox), just only behind a flag.

The point of the article is that Chrome removes the experimental, behind-a-flag support of JPEG XL, which dramatically decreases the reach of JPEG XL, so yo say.
Post reply on HN