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

[hajj_3]

jpegxl vs jpegli benchmarks: https://res.cloudinary.com/cloudinar...to-front-5-png

[Phoronos]

Why not PNG ?
PNG seems better no ?

[Quackdoc]

Why not PNG ?
PNG seems better no ?

PNG doesn't offer any good lossy tech, and its on average larger on JXL for lossless, even when comparing ECTd pngs.

so it doesn't even compete with jpegli, and competes poorly for efficiency with jxl

[JEBjames]

it's more or less just coding stuff that was lifted from libjxl. it's not specific to JXL in anyway. mozjpeg is good, but it's not the best thing in the world. The downside is you gain none of the JXL feature set, things like the lossless encoding (which is actually really good with JXL), XYB under the hood (though you can get some of the benefits using ICC) larger file sizes, many layers, animation, and more and more features. Also it's still not quite as good as jpeg-xl when it comes to compression.

That makes sense. Lossless is better for archiving. Layers and animation is good.

But if plain old-school jpeg can be made better AND still compatible that's still also a win?

[Mathias]

They have though? lame -V 4 (~165 kbps) is nearly transparent. You needed -V 2 (~190 kbps) for that a couple of decades ago, and even then it was a lot better than encoders from a few years prior.

Well LAME 3.99 was released October 2011 with AFAIK hand-tuned psychoacoustic enhancements. I think one of the big improvements in Jpeg li/xl is that it was auto-tuned with a good psy-aware heuristic. (But I think with audio it is even harder to compare different encoders down to the 10% bitrate difference level. Especially since hearing environment is a much bigger part then it is with viewing pictures.)

Anyway. It's just a hunch, maybe I'm wrong. We're unlikely to find out.

[SciK]

They just wanted to tell us about their JPEG-XL. It seems if it's not Google, it doesn't matter.

jpegli was made by a subset of the JPEG XL team. The code lives in the libjxl repo.

[Delta_44]

AVIF is a video codec. I will use it for animations, but for images and photos JPEG XL is better. Ideally with lossless compression.

AV1 is a video codec.
AVIF is AV1 BUT of course it's optimized for images.

Plus, photos are still images.

[Delta_44]

If it wasn't so slow...

Oh for fuck's sake, you must be one of those people that converts 1 trillion of 16k images, complaining about a codec that (DUH) it's slower than the others because you literally have the most efficiently encoded image (see: smaller size, same quality).

Keep using the ancient JPEG I guess.

[lyamc]

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?

You still have to add the extensions for the feature add, and you are still stuck with limitations of jpeg, and now there's going to be files that mostly work until you open/modify them in something that doesn't support those extensions. It's also not a lossless transcode like jxl has.

Or... hear me out...

Add support for jxl and get better lossy, and lossless codec that behaves in ways that are expected in software that supports it. It's in Thorium (Chromium fork) and Mercury (Firefox fork, although it has issues with jxl transparency). The code's already there, so I don't understand why they put in the effort to remove it unless they were trying to sabotage its adoption in order to push avif, which IMO isn't even a direct competitor since avif can't do high resolution images without tiling.

[Quackdoc]

That makes sense. Lossless is better for archiving. Layers and animation is good.

But if plain old-school jpeg can be made better AND still compatible that's still also a win?

correct. Jpeg is still used in most places. and it's still faster to decode then both avif and jxl

AV1 is a video codec.
AVIF is AV1 BUT of course it's optimized for images.

Plus, photos are still images.

Saying it's "optimized" for images is a bit... kinda true? AVIF is just av1 in an mp4 container with additional metadata. That's it. Still AVIF is an av1 I-frame, animated AVIF (avis brand) is a full av1 video, Animated AVIF (avio brand) IIRC is a series of i-frames.

When creating a still avif, there are some optimizations you can tell the encoder to do, but it's not like you are talking about aom vs svtav1 vs rav1e. Though aom is typically used. When creating animated avif, well its just av1 video.

Oh for fuck's sake, you must be one of those people that converts 1 trillion of 16k images, complaining about a codec that (DUH) it's slower than the others because you literally have the most efficiently encoded image (see: smaller size, same quality).

Keep using the ancient JPEG I guess.

it does matter, a lot, for both encode but primarily decoding. Opening a comic of say avif images vs jpeg or jxl images on a low end device like say a phone is the difference between a nice smooth experience and your device stuttering like a the kid in the back corner of the class. It's important to meet a certain baseline of speed for a given task, if you fail to meet it you can cause a really bad experience.

You still have to add the extensions for the feature add, and you are still stuck with limitations of jpeg, and now there's going to be files that mostly work until you open/modify them in something that doesn't support those extensions. It's also not a lossless transcode like jxl has.

This is not true, as the article says it's compatible with old viewers

Jpegli's 10+ bits coding happens in the original 8-bit formalism and the resulting images are fully interoperable with 8-bit viewers.

It will work in your old viewers, it's just that you need a new viewer to benefit from this. now the colorspace bit is a wee bit different as that relies on ICCs and there are plenty of image software that doesn't work with ICC, but thats not really anything new. Jpegs with ICCs already don't display properly in these image viewers, but now it will look more broken. IIRC this is optional? I can't remeber