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

[Delta_44]

yikes, sorry, but i do want to have decent image quality and i am not interested in a mosh of compression artifacts.

Image formats that got ripped out of a video codecs will always be crap. Webp is crap, avif is crap.

If you use shitty settings, then you'll have artifacts.
I do not and spare 9/10 of space.

[Quackdoc]

yikes, sorry, but i do want to have decent image quality and i am not interested in a mosh of compression artifacts.

Image formats that got ripped out of a video codecs will always be crap. Webp is crap, avif is crap.

any lossy encode will give you a range of compression artifacts, AVIF is typically more "pleasing" artifact then JXL has at lower bitrates and even retains more data then libjxl currently due to libjxl being optimized more for "higher" bitrates

[hf_139]

Useless.
Just use AVIF

yikes, sorry, but i do want to have decent image quality and i am not interested in a mosh of compression artifacts.

Image formats that got ripped out of a video codecs will always be crap. Webp is crap, avif is crap.

[Artim]

That's not what I said.

One of the features is 10-bit support through the use of extensions which will still load the 8-bit version in things that don't support it.

Here's the problem. What happens if you were to open that baby up in a image editor and then modify it? Would it not just remove the 10-bit data?

As anything with more than 8 bit, some software won't support it. If you modify it? Depends on the software. My guess would be Gimp could handle it as it can handle ICC color profiles and afaik more than 8 bit color. But either way, the 10 bit data wouldn't be removed, either the ICC profile is or it's just being ignored. In the latter case you could still e.g. crop it, but you wouldn't see a color accurate image in the first place, so color editing wouldn't work.

[lyamc]

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

That's not what I said.

One of the features is 10-bit support through the use of extensions which will still load the 8-bit version in things that don't support it.

Here's the problem. What happens if you were to open that baby up in a image editor and then modify it? Would it not just remove the 10-bit data?

[Quackdoc]

ok do you know better alternatives than JPEG ??

for lossy, Not really outside of jpegxl, JPEG is really good as it is, webp can in cases have better compression then JPEG, AVIF will have better compression then JPEG, but you are loosing out on things like progressive decoding, they take longer to decode and encode. JPEG is still just a really solid format and the only real alternative to it is JPEG-XL. If you only care about file size and fidelity, then AVIF is a good alternative. It supports HDR, high bit depth, Animations and some other nice goodies. but it also has limitations on things like file resolution that kinda hurt for some specific applications.

for lossless anything will beat jpeg. Due to how JPEG was originally designed, it's not "deterministic" different decoders can actually decode a jpeg different ways while still being spec compliant. So even if you were to encode a image losslessly, it's not reliably lossless.

[Artim]

[QUOTE=EphemeralEft;n1455486]

While looking for sources to reply with, I was reminded of SPDY, which was another thing that Google distributed before standardizing.

From a 2012 Chromium blog post:

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web. [...] Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search.

Thanks for proving my point. It was only an internal demo, because obviously you need real world data to find out if you theories actually work. But at no point was anybody outside of Googles own ecosystem using - or even forced to use - SPDY. Sure, maybe other companies that where involved in the standardization process could have done the same. So what? That's exactly how standardization needs to work, otherwise you're only creating standards that look good on paper but have no real world value.

The first revision of the HTTP/2 standard was only posted in 2015, so they started enabling it by default for at least 3 years before that. They did the same thing with QUIC, though; see below.

From a 2015 Chromium blog post:

Last year we announced QUIC, a UDP-based transport protocol for the modern Internet. Over the last quarter, we’ve been increasing the amount of traffic to Google services that is served over QUIC and analyzing QUIC performance at scale. Results so far are positive, with the data showing that QUIC provides a real performance improvement over TCP thanks to QUIC's lower-latency connection establishment, improved congestion control, and better loss recovery.

Thanks again for proving my point and admitting you were wrong.

They were deciding when it should be used; clearly it didn't require user intervention to enable.

Says who? At what point exactly are you proving that Google enabled it by default - for anything other than their own services - and the users didn't opt in by their own free will to see what's cooking and to comment themselves on the RFC?

[EphemeralEft]

They didn't though. It was implemented as an experimental feature behind a flag. Off by default.

While looking for sources to reply with, I was reminded of SPDY, which was another thing that Google distributed before standardizing.

From a 2012 Chromium blog post:

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web. [...] Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search.

The first revision of the HTTP/2 standard was only posted in 2015, so they started enabling it by default for at least 3 years before that. They did the same thing with QUIC, though; see below.

From a 2015 Chromium blog post:

Last year we announced QUIC, a UDP-based transport protocol for the modern Internet. Over the last quarter, we’ve been increasing the amount of traffic to Google services that is served over QUIC and analyzing QUIC performance at scale. Results so far are positive, with the data showing that QUIC provides a real performance improvement over TCP thanks to QUIC's lower-latency connection establishment, improved congestion control, and better loss recovery.

They were deciding when it should be used; clearly it didn't require user intervention to enable. The first revision of QUIC was only posted in 2021, at least 6 years after enabling by default.

[Artim]

Jpeg2000, probably jpegxl-lossless. Lossy compression is mostly useless and niche my industry.
the fact remains, google tried to kill usage of jpeg-xl and they stripped down and changed a few things to come up with a “google” form.
yes it is on jpegxl, they coopted and took over to have a google created, supported, pushed, and branded “better jpegxl than jpegxl”..

not a new story with google.

Please stop spreading lies that have been disproven several times already.

[Artim]

Prezactly. Take-over of committees/committee stuffing is a well-known problem. See Microsoft and ISO 29500.

With the difference that Google obviously doesn't do that, otherwise their proposals would be accepted without any changes.

Ahh - you mean 'watered down'.

Yes, Phoronix is having huge issues in the last days, not loading, being slow and generally sluggish. Maybe that was cut off.