Talk:JPEG XL

Why XL?

Is there a reason for the XL in the name, or this just an arbitrary choice of two letters? --Zundark (talk) 14:55, 27 February 2021 (UTC)

See the new section Name. --Avayak (talk) 22:50, 27 February 2021 (UTC)

Thanks! --Zundark (talk) 08:28, 28 February 2021 (UTC)

"Proposed support"

This is such a vague term for wikipedia article. What are the criteria? Is an issue opened in a bug tracker enough? It's my opinion that we should only list software with support for JPEG XL either announced or implemented. TPFNoob (talk) 16:40, 29 April 2021 (UTC)

An issue opened in a bug tracker seems like it should be enough. It's useful to list these so that we can keep track of them. But the list doesn't need to be in the article - we could move it to the Talk page. --Zundark (talk) 20:37, 29 April 2021 (UTC)

I would keep it as it is. Sooner or later the software will support the format (or if the developers decide not to, we can remove the item from the article). --Avayak (talk) 09:06, 30 April 2021 (UTC)

I agree with TPFNoob, this is a completely useless section with no proper criteria defined for inclusion. For example, there was IrfanView, with the ref link simply leading to a forum discussion where a bunch of users wish to know whether the program will support the format or not. The same thread states that the developer never reads forum posts, and the last bit of news is that someone has supposedly mailed the developer in his native tongue and now they're all waiting with bated breath for him to hopefully read the mail and reply some day. Is this meant to be a joke, or someone trolling Wikipedia? Should we start listing the names of every single program just because some user somewhere has simply asked whether said program will support JPEG XL, even if no developer has ever cared to even acknowledge the request, leave alone reply in the affirmative?

It's clear that this section is being included and padded simply to try and fool readers into thinking that the format is more popular than it actually is at present.

Strong arguments. OK, I removed that section. --Avayak (talk) 12:19, 7 May 2021 (UTC)

Ambiguous statement

Animated (multi-frame) images do not perform advanced inter-frame prediction, though some rudimentary inter-frame coding tools are available:

• frames can update only parts of the canvas;

This is ambiguous. I think it means that a frame can update either the entire canvas or a selected part, but it could be interpreted as meaning only parts and not the whole canvas can be updated. I would appreciate it if someone who knows for certain what is meant could amend the article to remove the ambiguity. -- Q Chris (talk) 15:28, 30 September 2021 (UTC)

23 24 25 notes duplicated

to fix Frial456 (talk) 19:33, 27 September 2022 (UTC)

Fixed Frial456 (talk) 17:34, 17 October 2022 (UTC)

Patents

The article conspicuously lacks any mention of plans for patent management. There are some articles calling it royalty-free, but it's not clear on what basis (and the term is often abused anyway). The only concrete information I could find is Google's patent grant for the reference implementation, but I didn't find any information of an open patent pool or other arrangement between the promoters/inventors. Nemo 07:01, 11 February 2023 (UTC)

Discontinued

See https://arstechnica.com/gadgets/2023/04/free-software-group-decries-google-dropping-space-saving-jpeg-xl-format/

The format's probably dead now. Google killed it. 66.209.34.245 (talk) 18:04, 17 April 2023 (UTC)

Thanks, but the dropping of Chrome support that Ars Technica just got around to covering was added to the Wiki article over 5 months ago -- https://en.wiki.x.io/w/index.php?title=JPEG_XL&diff=prev&oldid=1118865764&diffmode=visual

KelleyCook (talk) 15:24, 18 April 2023 (UTC)

Section explaining chromium's pull of support should be moved to history section

Originally i couldn't find it there, and i added a clarify to a bit which referred to it, but it seems that it was explained in a paragraph.

That bit should probably be moved and rewritten in the history section. Shadowjonathan (talk) 15:09, 26 September 2023 (UTC)

Vandalism on "Software Support" section

Starting from September 2023, there is an edit war going on, with either section removed completely or random items, with no rhyme or reason which are removed and which are left, with sometimes childish comments via edit reasons. Section should be reverted to state it was in August 2023. If you want to make article neater, please actually discuss changes beforehand to reach consensus. 91.207.7.126 (talk) 00:41, 7 March 2024 (UTC)

Efficient encoding and decoding

One of the features listed is fast encoding and decoding, it's claimed that JPEG XL is about as fast as old JPEG and an order of magnitude faster than x265. Reference is made to a blog post by one of the developers of JPEG XL, that is writen like an advertisement, not an objective investigative article. The claims made in the article are poorly supported, some with a single example and some without any. What software was used is unclear, however at one point the reference implementation, libjxl, is mentioned. I think this poorly supported, misleading claim and the reference to that blog post should be removed. From my own experience with libjxl (x86-64, from the repository of Devuan 5.0 Daedalus) I can tell that JPEG XL is everything other than fast, it is much slower than any of the other compression methods mentioned, one to two orders of magnitude slower than JPEG Turbo and it uses a vast amount of memory, more than any other codec. 2A02:A461:E1E:1:21B:FCFF:FE75:6ADE (talk) 11:48, 31 March 2024 (UTC)

Thank you for pointing that out. I have added the reference that the figures in the post come from. More details can be found there. Spidermario (talk) 21:56, 31 March 2024 (UTC)

Recent versions now use less memory for encoding, except for transcoding plain JPEG. The CPU use can be adjusted with the Effort settting where -e 3 provides a good balance. This also improves decompression speed compared to default -e 7. I think it's a cheat to use multiple cores for one format but not another. Old PCs don't have many cores. JXL is a balanced format, better than some past technologies. Overall I would say plain JPEG, EXR and JPEG-LS are still better because they are the fastest to encode.

Here are relative decompression times at maximum bitrate or lossless in IrfanView or XnView (EXR, JXR). At lower bitrates lossy formats are faster. JPEG linear scan: 100%; JPEG progressive: 240%; JPEG prog arithmetic: 1,000%; PNG: 100%; OpenEXR PIZ: 250%; JPEG-XR/HDPhoto: 300%; JPEG-LS: 350%; JPEG-XL Effort 3: 530%; JPEG-XL Effort 7: 860%, JPEG-2000: 1,200%. -- J7n (talk) 15:35, 6 May 2024 (UTC)