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

111–120 of 210 posts

Re: The case for JPEG XL

#111

Post by jonsneyers »

nigeltao wrote: post #65
jonsneyers wrote: post #56

Earlier quoted context omitted.

Lossless encoding can be done with various trade-offs between speed and compression density. At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?... . This is an extremely fast lossless jxl encoder, which is about 100 times faster than PNG encoding (libpng) and compresses about 10% better. At the other extreme, there are the slowest settings of the reference encoder libjx…

fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster. If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways. I believe that Apple have an unofficial PNG extension that facilitates multi-threaded dec…

Did you compile fjxl with or without SIMD? That makes a big difference.

And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice.

The problem with PNG extensions for multi-threading is that it only works if you control the encode side too — most existing encoders will not use such an extension. If existing deployments need to be replaced anyway, you can just as well use a new format altogether.

Re: The case for JPEG XL

#112

Post by aabhay »

This is really sad. I was sincerely hoping for jxl to become a widespread standard. Especially things like formats for 3D materials that have both high but depth color information as well as depth information, we could have a single format that could encode the entire texture easily. Also space-saving storage, etc.

We’re still pretty committed to using jxl as an internal standard for many things.

Re: The case for JPEG XL

#113

Post by JyrkiAlakuijala »

nigeltao wrote: post #47

From the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG…

I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.

Re: The case for JPEG XL

#114

Post by Semaphor »

jonsneyers wrote: post #109
Semaphor wrote: post #88

Earlier quoted context omitted.

Also not sure if this is a Twitter issue (wait, another reason not to use twitter? So why do people keep using it for something it’s bad at? /rant), but I got a different result. I can clearly see the differences between the encodings (I shuffled the images and sorted them by perceived quality), and I disagree that JXL looks better / is less racist. For both sides, the AVIF version looks significantly better, but esp…

It was probably a bad idea to put such examples on twitter, since twitter recompression is quite aggressive and makes a big difference. I don't have the original decoded images nearby but it is best to do these kinds of comparisons without any recompression.

I’d happily look at them again in their actual versions

Re: The case for JPEG XL

#115

Post by rocqua »

jokabrink wrote: post #52

I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place. Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also…

Personally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".

Re: The case for JPEG XL

#117

Post by crazytalk »

mastax wrote: post #38

I had regarded the lossless re-compression as an interesting parlor trick, but I get it now. Coincidentally today I was testing how much we can shrink our archived videos. We have lots of videos recorded with the Intel hardware encoder in H264, so not even the state of the art of H264. I figured: pop it into handbrake, change the codec to H265 (X.265), and boom 30%+ reduction. No, the H265 file got 3X larger. Well th…

Most online video uses crazily overspecified h.264 bit rates for low complexity content. It's often possible to get 1080p well under 2 Mbit/s with little to no quality loss, and even lower by using 2 pass encoding where that's available. I'm not sure how things are with h.265 in a production setting, but at least for home use it seems to have much of the same flexibility

Re: The case for JPEG XL

#118

Post by account42 »

Another argument: JXL actually supports losless compression of RGB bitmaps and cjxl (the JXL reference encoder) actually supports color spaces correctly when converting from PNG unlike Google's WEBP, which only supports losless YUV compression and the conversion from RGB to YUV is not entirely lossless and cwebp (Google's WEBP reference encoder) doesn't support all the ways color spaces can be encoded in PNGs, resulting in washed out images in some cases.

And what could also be an advantage for JXL is animation. WEBP does have animation support implemented in browsers but it came after the freature was enabled and doesn't have a separate mime type so you can't do fallback to .gif without user agent checks. If JXL support either ships with animations enabled or animated JXL gets a separate mime type in browsers it could make it actually useful.

Re: The case for JPEG XL

#119

Post by cesarb »

janwas wrote: post #48
mastax wrote: post #44

> One final significant benefit of JPEG XL is that it has a broad scope: while it is a great format for web delivery, this is not the only use case it was designed for. JPEG XL can also be used as a capture format, where it can play a role similar to current camera raw formats: high precision, high dynamic range, lossless or minimal lossy compression. It can also be used as an authoring format, supporting named layer…

Disclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf , 101 for https://www.iso.org/standard/77977.html . Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Feat…

> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf, 101 for https://www.iso.org/standard/77977.html.

And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would cost to buy a basic laptop.

Re: The case for JPEG XL

#120

Post by formerly_proven »

crazytalk wrote: post #117
mastax wrote: post #38

I had regarded the lossless re-compression as an interesting parlor trick, but I get it now. Coincidentally today I was testing how much we can shrink our archived videos. We have lots of videos recorded with the Intel hardware encoder in H264, so not even the state of the art of H264. I figured: pop it into handbrake, change the codec to H265 (X.265), and boom 30%+ reduction. No, the H265 file got 3X larger. Well th…

Most online video uses crazily overspecified h.264 bit rates for low complexity content. It's often possible to get 1080p well under 2 Mbit/s with little to no quality loss, and even lower by using 2 pass encoding where that's available. I'm not sure how things are with h.265 in a production setting, but at least for home use it seems to have much of the same flexibility

Do you work for Amazon Video or Netflix?
Post reply on HN