Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

[flagged]


First, this is work by the team that co-designed JPEG XL.

Second, as far as I can tell this is a JPEG encoding library, producing JPEG files that any existing JPEG decoder will be able to read. Nobody is being asked to support or maintain anything new.


Not to mention that it's 35% more efficient than existing encoders, and can support 10+ bits per component encoding while remaining compatible with existing decoders. That's pretty amazing.


It would still be nice to see a comparison to JPEG XL.


https://giannirosato.com/blog/post/jpegli/

Note that that's from almost a year ago, don't know if anything changed.


Yeah, this is just that. They took JPEG XL denoising and deartifacting algorithms and front loaded them into a 10-bit JPEG encoder.

There's more to it, of course, but it's essentially just an improved encoder versus a new format.


No denoising or deartifacting was used. They are an option for future improvements at low quality JPEG decoding.


The sourcecode is on jxl's main repo. I'm confused to say the least


What's so confusing about it?

This team did a lot of work to create JPEG XL. For whatever reason, Chrome is not agreeing to ship it, which will make it a lot harder for it to be widely adopted. So they're now applying the same techniques to classic JPEG, where the work they did can provide value immediately and not be subject to a pocket veto by Chrome.


The confusing part is that the code is in the jxl repository. Is it Google's code, JXL's, JXL's people under Google?


All the developers involved are part of the JXL team at Google Zürich, as far as I can tell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: