I'm not sure why lossless decoding performance is an issue. If I'm on a mobile device I will be more concerned downloading a huge lossless image in the first place, the speed of decoding is irrelevant at this point. I don't believe that it is a realistic scenario that "CDNs will externalise costs". JXL benefits outweigh this imaginary scenario.
On Wednesday, August 26, 2026 at 5:21:16 PM UTC+1 dev null wrote: > 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/3dd44275-67d3-410d-ae92-4216bc4d3132n%40chromium.org.
