[lonjil]

Jpegli encoded images decode just fine with any JPEG decoder, and will still be of great quality. All the tests were done with libjpeg-turbo as the decoder. Using Jpegli for decoding gives you a bit better quality and potentially higher bit depth.

[lars_thomas]

Thanks, sounds great! Not sure if you are part of the research team but a follow up question nevertheless. Learning from JpegXL, what would it take to develop another widely supported image format? Would the research stage already need to be carried out as a multi-corporate effort?

[lonjil]

> Not sure if you are part of the research team but a follow up question nevertheless.

I am not.

> what would it take to develop another widely supported image format? Would the research stage already need to be carried out as a multi-corporate effort?

I believe JXL will be very successful sooner or later, it already has a lot more support than many other attempts at new image formats.

But in general, the main way to get fast adoption on the web is to have Chromium's codec team be the main developers.

[JyrkiAlakuijala]

Multi-corporate effort would likely need to start by first agreeing what is image quality.

Image quality folks are more cautious and tradition-centric than codec devs, so quite an initial effort would be needed to use something as advanced and risky as butteraugli, ssimulacra or XYB. With traditional objective metrics it would be very difficult to make a competing format as they would start with a 10–15 % disadvantage.

So, I think it is not easy and would need substantial investment.

[01HNNWZ0MV43FF]

Sort of like the quality vs. speed settings on libx264, I suppose jpegli aims to push the Pareto boundary on both quality and speed without changing the decode spec