I don't see a reason to break an important feature of an image format just because some small amount of users might have slightly less battery life if they browse special sites serving a lot of lossless images. The vast majority of sites and CDN's deliver lossy images to users, they have a far greater incentive to deliver lossy images, as that's far more efficient for both them and the users, there is no good reason to assume this will meaningfully impact the average user at all. There is no reason to assume JXL lossless optimization won't dramatically improve, while you can consider the lossy encoding well optimized, lossless has not yet received as thorough of an optimization, and optimization for both is still not as mature as codecs like WebP which have been around for 15+ years, and have far more users. I personally have a great use of JXL lossless images as I have huge archives of lossless images on my personal home server, but considering I like to view most of those images in browsers on my devices, I have been blocked from converting my archive, and have been waiting for several years for Chrome to add JXL support, especially lossless. I would be heartbroken to still not be able to use JXL's excellent lossless compression, after all these years of waiting.
On Wednesday, August 26, 2026 at 5:18:15 PM UTC+2 Sergey Davidoff wrote: > It is not clear if significant further optimization is even possible. > libjxl, the original highly optimized C++ implementation, was also 20x > slower to decode than WebP in my measurements. This indicates that we're > more likely than not in the realm of diminishing returns already. Rushing > the stabilization in hopes that further *dramatic* optimizations *might* > be possible seems reckless. > > ср, 26 авг. 2026 г. в 10:32, Philip Jägenstedt <[email protected]>: > >> I think this is a real risk, but we should expect adoption to ramp up >> quite slowly, and that there will be time to optimize. The usage can be >> seen at https://webstatus.dev/features/jpegxl or >> https://chromestatus.com/metrics/webfeature/timeline/popularity/418 >> (same underlying data) and should start rizing from ~0 only after this >> reaches stable. >> >> On Tue, Aug 25, 2026 at 10:04 PM Sergey Davidoff <[email protected]> >> wrote: >> >>> What I am concerned about is CDNs using lossless JPEG XL to cut their >>> network costs, and externalize those costs by degrading battery life for >>> all users with recent enough browsers. They are financially incentivized to >>> do so, and that is why I am so concerned about giving them the opportunity. >>> >>> вт, 25 авг. 2026 г. в 20:16, Birk Hirdman <[email protected]>: >>> >>>> Moreover, the encoder can be configured to prioritize decoding speed >>>> over maximum compression -- for example, setting --faster_decoding 1 does >>>> not change the compressed size significantly, but doubles decoding speed. >>>> >>>> >>>> Then perhaps only fast-decoding lossless mode should be supported in >>>> web browsers. A 7.5x slowdown instead of 15x might be excusable, depending >>>> on the use case. >>>> >>>> >>>> Surely websites can select compression options that fit their use >>>> cases? Perhaps all that is needed is to change the default in libjxl's CLI >>>> tool to use faster_decoding=1. >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9d691ac0-6084-4340-9e7f-af183c2ecf6fn%40chromium.org.
