3 ms·
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
by jsnell 3y ago
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.
- deleted 3y ago[deleted]
- CharlesW 3y agoNot 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.
- amluto 3y agoIt would still be nice to see a comparison to JPEG XL.
- edflsafoiewq 3y agohttps://giannirosato.com/blog/post/jpegli/ https://giannirosato.com/blog/post/jpegli/ Note that that's from almost a year ago, don't know if anything changed.
- deaddodo 3y agoYeah, 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.
- JyrkiAlakuijala 3y agoNo denoising or deartifacting was used. They are an option for future improvements at low quality JPEG decoding.
- jbverschoor 3y agoThe sourcecode is on jxl's main repo. I'm confused to say the least
- jsnell 3y agoWhat'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.
- jbverschoor 3y agoThe confusing part is that the code is in the jxl repository. Is it Google's code, JXL's, JXL's people under Google?
- lonjil 3y agoAll the developers involved are part of the JXL team at Google Zürich, as far as I can tell.