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

191–200 of 210 posts

Re: The case for JPEG XL

#191

Post by JyrkiAlakuijala »

sureglymop wrote: post #186
JyrkiAlakuijala wrote: post #86

Earlier quoted context omitted.

The journey to JPEG XL started with guetzli (which started with butteraugli to guide loss in JPEG encoding) and brunsli. Guetzli is a great (but very very slow) JPEG encoder. Brunsli is a classic JPEG1 recompressor. We mixed those and got the first version of PIK. We added some forced format-level progression, adaptive quantization, filtering, larger DCTs, integerated HUIF as lossless/super-progressive coder, and ado…

As a swiss person, all these names of common christmas cookies here are making me hungry.

others are real Swiss cookies, but butteraugli is a made up Pseudo-Swiss word based on voisilmäpulla, a Finnish sweet bread

Re: The case for JPEG XL

#192

Post by JyrkiAlakuijala »

pornel wrote: post #185
ocdtrekkie wrote: post #184

Earlier quoted context omitted.

I don't think there was ever a good case for WebP, but JPEG XL sounds promising. The problem of course, is the monopoly browser developer made WebP, and the monopoly browser developer sees JPEG XL as a competitor to their in-house format.

That's a bizarre and unfounded accusation. Author of WebP worked on JPEG XL, and Google has shipped AVIF which includes tech from Mozilla, Nokia, and many others.

I consider that WebP lossy was fixed to usable quality level around 2015, five years after the launch. For the first five years it had a tendency to make 4x4 pixel lego-block representations of smooth gradients and lose highly saturated colors.

8-bits per channel and YUV420 only were caused by hurrying it.

With JPEG XL we have the opposing mistake. We had a great format already in 2017, and spent 5 years more for improving it further.

Re: The case for JPEG XL

#193

Post by JyrkiAlakuijala »

nigeltao wrote: post #183
jonsneyers wrote: post #111

Earlier quoted context omitted.

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 th…

> Did you compile fjxl with or without SIMD? I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected. https://github.com/nigeltao/qoir/commit/c2fec840 > If existing deployments need to be replaced anyway, you can just as well use a new format altogether. There's still an operational difference between rolling out multi-threaded…

PNG is ok if you don't care about the 60 % more bytes to transmit and keep around and legacy is important for you.

If you care about speed or transmission cost, then you try to look elsewhere.

WebP lossless already is quite a big improvement, and JPEG XL gives some more (not yet in decoding speed, though).

Re: The case for JPEG XL

#194

Post by JyrkiAlakuijala »

pornel wrote: post #172
JyrkiAlakuijala wrote: post #154

Earlier quoted context omitted.

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win.…

JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.

Re: The case for JPEG XL

#196

Post by gruturo »

JyrkiAlakuijala wrote: post #140
gruturo wrote: post #77

Earlier quoted context omitted.

And which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.

JPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.

And it addresses a very, very real use case of recompressing JPEGs without generation loss. Considering that a vast majority of all pictures being taken even today begin their life as JPEGs, that's very relevant.

Re: The case for JPEG XL

#197

Post by vanderZwan »

derf_ wrote: post #178
vanderZwan wrote: post #100

Earlier quoted context omitted.

You're technically correct, but: > Several variants of the coding procedure Asymmetric Numerical Systems (ANS) may be found in most modern codecs, such as AV1, Z-Standard compression, or even rANS in JPEG XL. ... this is hardly the fault of the JPEG XL developers though, that's the US patent system being ridiculous. Also, in the current discussion context that patent screws over any new compression format, not JPEG X…

AV1 does not use rANS in any form. The quoted sentence is simply incorrect. However, any necessary patent claims owned by Microsoft, an AOM member, would be freely licensed to everyone for use in AV1 implementations if it actually did use rANS. Which it doesn't.

The quote doesn't state that AV1 uses rANS, it states that it uses a variant of ANS. JPEG XL uses rANS.

Re: The case for JPEG XL

#198

Post by pornel »

JyrkiAlakuijala wrote: post #194
pornel wrote: post #172

Earlier quoted context omitted.

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win.…

JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.

The major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.

Re: The case for JPEG XL

#199

Post by LoganDark »

jimis wrote: post #160
cesarb wrote: post #119

Earlier quoted context omitted.

> 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 co…

> after paying more money than it would cost to buy a basic laptop No need to be imprecise, unless you are trying to push some agenda. The cost is CHF 198, which is around USD 195.

Yeah, a lot of things cost more than a basic laptop. Last I checked, you can get Chromebooks on the order of $20 or so per machine. That metric isn't useful to anybody.

Re: The case for JPEG XL

#200

Post by jonsneyers »

derf_ wrote: post #177
jonsneyers wrote: post #165

Earlier quoted context omitted.

That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but participating in the standardization process costs about as much as a nice car. I don't really like either model, but I don't think I particularly prefer AOM's model.

We created avenues for open source / community participation in AOM that did not require people to pay any money. Specifically, Mozilla sponsored the membership of VideoLAN, which in theory anyone could join, and a number of people did and do participate through that organization.

That's good to know, and nice that Mozilla did that!
Post reply on HN