Google's Jpegli Offers ~35% Compression Improvement For High Quality JPEGs

[lamka02sk]

Useless.
Just use AVIF

If it wasn't so slow...

[Artim]

So Google is trying to bring some Jpeg-XL technologies back to regular Jpeg, after they basically killed Jpeg-XL.

I'd also like to point out that Google's own office suite (Docs, Slides, Sheets, etc..) STILL does not support Google's own WebP format. So you can't even make a lightweight slide presentation using Google's own image format that's been out 6+ years now.

I swear this company has no real direction or guidance. Just seems to be thousands of different teams all doing their own thing, and when one team starts costing Google too much money, they kill it off.

Probably simply due to the fact that Google doesn't believe anyone seriously only uses their Suite to only work in their own file format, but to eventually export to pptx, odp or pdf. And only odp can handle WebP without conversion. Also, their own Suite is like the lowest common denominator you can get away with calling an office Suite.

[lyamc]

one again, "google" is not one entity, JPEG-XL IS a google project too. the top 3/5 devs iirc are google employees for libjxl

I think we all realize that google is not one entity, but it doesn't change the validity of the criticism. If you remember, the reason for removing (not rejecting, REMOVING) jxl support in Chromium was that it didn't provide enough benefits and because it wasn't adopted yet. So what the hell is going on at Google? Did they screw up their initial testing when evaluating jxl in Chromium?

[Quackdoc]

I think we all realize that google is not one entity, but it doesn't change the validity of the criticism. If you remember, the reason for removing (not rejecting, REMOVING) jxl support in Chromium was that it didn't provide enough benefits and because it wasn't adopted yet. So what the hell is going on at Google? Did they screw up their initial testing when evaluating jxl in Chromium?

two completely different teams. Chromium team used bias testing from the av1/avif team when making their decision. It's been implied that there is some cross over between chromium and av1 teams.

[Danny3]

So Google will just try anything to avoid JPEG-XL?
How typical Google...
And of course, fuck JPEG, fuck Google!

[Mathias]

Jpegli is pretty awesome for what it is. Even if browsers supported XL, there are still other formats like PDF and Office formats that don't support anything valuable besides JPEG. (WebP never was better then MozJpeg). So Jpegli is a real improvement. In my tests, the XYB Colorspace mode wasn't 100% compatible though. IIRC the previews in my file manager had wrong colors...

And compared to JpegXL, jpegli is only ~20% worse compression wise. Given how old the Jpeg standard is, this was really alien technology.

I really like JpegXL. But mostly for its feature set. The compression, even compared to jpeg-turbo, is at most 35% better.

And Jpeg compression could be 10% better, if everyone supported arithmetic encoding - the patents are long expired. Jpegli with Arithmetic would be really close to JpegXL compression wise.

(My data is based on a recent cloudinary blogpost about JpegXL. So they showed normal Jpeg is only 20-35% worse then XL.)

[ElectricPrism]

We need a joke on a file format that makes a 0% effort to be compressed -- like __Bitmap Master Race__ except with Alpha and some other features.

Then make the files too large for AI's to process without crashing, and make it harder for 3rd parties to effectively copy the files.

As a added bonus for Chrome being a total boner with JPEG-XL, we should destroy their place in the world as Overlords of the Internet. Anti-trust lawsuits by the EU, a 3rd option browser __not funded by Google__ -- a complete shift of techies away from HTTP/s to GEMINI or some other alternative that busts their balls by design. Whatever it takes.

[AmericanLocomotive]

That's how all large companies work. They are not a monolith although people like to pretend that they are.

We all understand that large companies have different divisions, often embarking in different research projects. But those divisions are usually are usually being driven in the same direction. In Google's case, it seems the different divisions are all over the place, going in all different directions, all the time. Google will kill off a product, and then spin-up a near identical product a couple of months later with a different name and a slightly different feature set.

Remember at one point 4-5 years ago Google had like three different remote-video-conferencing products at the same time? ...and the one they stuck with (Google Meets) had the worst feature set out of all of them.

Apple is equally as huge as Google, but has a much more cohesive software lineup and a clear direction.

Jpegli is pretty awesome for what it is. Even if browsers supported XL, there are still other formats like PDF and Office formats that don't support anything valuable besides JPEG. (WebP never was better then MozJpeg). So Jpegli is a real improvement. In my tests, the XYB Colorspace mode wasn't 100% compatible though. IIRC the previews in my file manager had wrong colors...

And compared to JpegXL, jpegli is only ~20% worse compression wise. Given how old the Jpeg standard is, this was really alien technology.

I really like JpegXL. But mostly for its feature set. The compression, even compared to jpeg-turbo, is at most 35% better.

20-35% better compression ratio is a huge amount - like monumental. Imagine telling someone at Instagram or Imgur that they could essentially increase their bandwidth limits and storage capacity by only 25% for free, without losing any image quality, just by switching to Jpeg-XL.

[JEBjames]

So Google is trying to bring some Jpeg-XL technologies back to regular Jpeg, after they basically killed Jpeg-XL.

I'm not sure I'm understanding this right...

They are using some Jpeg-XL magic under the hood...but only in the encoding. They keep the SAME plain vanilla 100% compatible JPEG format as the output? i.e. better compression/quality like jpeg-xl...but the same jpeg format? Only the compressor part needs to changed?

All existing software jpeg software will be able to open these files because it's "the same old jpeg format"?

Am I totally missing something? This sounds way better than adding yet another file format? What's the down side here?

[spicfoo]

We all understand that large companies have different divisions, often embarking in different research projects. But those divisions are usually are usually being driven in the same direction.

They are not, no. Different teams and individuals within the same company can and do have wildly different and conflicting goals. If you have ever worked for large organizations, you would know not to treat them as a monolith.