Hacker News new | ask | show | jobs
by lars_thomas 811 days ago
Sorry for perhaps missing it but it states "It provides both a fully interoperable encoder and decoder complying with the original JPEG standard". Does that mean that jpegli-encoded images can be decoded by all jpeg decoders? But it will not have the same quality?
1 comments
lonjil 811 days ago
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.
link
lars_thomas 811 days ago
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?
link
lonjil 811 days ago
> 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.

link
JyrkiAlakuijala 811 days ago
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.

link
01HNNWZ0MV43FF 811 days ago
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
link