Not a Googler, just chiming in. Yoav had a good point in his 2020 response:
> As it is, I'm not sure if it'd be easier to convince the ecosystem to adopt JPEG-XL as a Content-Encoding or as an image format. In 2026 the ecosystem achieved the latter, so personally I don't see much point to introduce a new content-encoding. On Thursday, February 12, 2026 at 9:16:16 PM UTC+1 [email protected] wrote: > Many apologies in advance, but just double checking if the dialogue on > this topic been moved to another group thread (with all the status changes > around jxl in general) Or is this still going to be the place it's > discussed? 🤔 > > On Wednesday, November 4, 2020 at 4:50:50 PM UTC Jyrki Alakuijala wrote: > >> On Friday, August 21, 2020 at 11:53:13 AM UTC+2 [email protected] wrote: >> >>> On Thu, Aug 20, 2020 at 11:21 PM Yoav Weiss <[email protected]> wrote: >>> >>>> Thanks Jyrki! >>>> >>>> I didn't state these points in particular, as I believe most of them >>>> can be achieved as part of the implementation, regardless if JPXL support >>>> is added as a Content-Encoding or as a full-fledged image format. Please >>>> correct me if I'm wrong on that front. >>>> >>>> On Thu, Aug 20, 2020 at 10:08 PM Jyrki Alakuijala <[email protected]> >>>> wrote: >>>> >>>>> There are some benefits of this approach that may not yet be clear >>>>> from Yoav's mail: >>>>> >>>>> - The experience through content encoding is more similar than with a >>>>> new image codec: >>>>> * The transcoding is lossless, no need for quality experimentation >>>>> to launch it >>>>> * The transcoding allows for progressive or sequential refreshing >>>>> of jpegs, less need for experiments to figure out all the subtleties of >>>>> the >>>>> latency impact >>>>> >>>>> - The lossless transcoding is super-fast, currently in one experiment >>>>> it was found about 10x faster than the fastest new modern image codec >>>>> >>>>> - Once the JPEG is cached in the browser, it is just a JPEG, and it's >>>>> redraws from cache are faster than redisplays for more modern image codecs >>>>> >>>> >>> Talking to +lizeb@, turns out that I'm at least partially wrong and >>> this part cannot be automatically optimized by the cache, as it can result >>> in web-exposed differences when the content is `fetch()`ed (similar to (3) >>> above). >>> At the same time, it's unclear if the 20% extra storage space would be >>> justified by faster decoding speeds. >>> +Josh Karlin may have some intuition here. >>> >>> >>>>> - While I do recommend server side caching of compressed data, one cpu >>>>> can convert jpeg into jpeg xl (as well as jpeg xl into jpeg) losslessly >>>>> at >>>>> 100 mbps >>>>> >>>> >>> Is this 100 mega *bits* or *bytes*? Do you have similar numbers for >>> client-side typical CPU? >>> >> >> 100 mbps is 100 megabits per second on intel. On a single mobile arm core >> it is about 30 mbps. These are compressed numbers and the uncompressed >> speeds are about 15x faster. >> >> >>> >>>> . For a site with a limited storage budget or for images that are not >>>>> 'hot' it may be a good idea to store in the JPEG XL form and convert >>>>> losslessly to legacy JPEG at request time. Storing legacy JPEG photos >>>>> losslessly as JPEG XL saves 22 % in storage budget. (Some sites like >>>>> dropbox have chosen to do this with their custom technology, as well as >>>>> the >>>>> media filter plugin for 7zip applies a similar compression method on >>>>> legacy >>>>> JPEG.) >>>>> >>>>> On Thu, Aug 20, 2020 at 4:21 PM Yoav Weiss <[email protected]> wrote: >>>>> >>>>>> I talked a bit to the team, and would like to share my thoughts >>>>>> following that. >>>>>> Supporting JPEG-XL as a Content-Encoding seems like it *might* enable >>>>>> a smoother transition period for sites that have old JPG images lying >>>>>> around. >>>>>> New image formats incur some cost and as content encoding web servers >>>>>> and CDN providers can freely apply that encoding to get ~20% >>>>>> improvements >>>>>> over JPEGs, without worrying about: >>>>>> >>>>>> 1. Users downloading the image and failing to e.g. edit it >>>>>> 2. JPEG Hardware decoding not being utilized >>>>>> 3. Web applications manipulating the image bytes directly, and >>>>>> breaking due to the transcoding. >>>>>> >>>>>> At the same time, those problems seem addressable by other means: >>>>>> >>>>>> 1. The browser could implement a "save as legacy format" context >>>>>> menu item, that would solve this problem for all next-gen image >>>>>> formats >>>>>> 2. The JPEG-XL decoding pipeline could make use of JPEG HW >>>>>> decoding abilities >>>>>> 3. Servers could avoid the JPEG-XL transformation when >>>>>> "no-transform" is indicated by the server, or when the image is >>>>>> same-origin/CORS-enabled `fetch()`ed by the user, which is likely a >>>>>> rare >>>>>> case >>>>>> >>>>>> As it is, I'm not sure if it'd be easier to convince the ecosystem to >>>>>> adopt JPEG-XL as a Content-Encoding or as an image format. >>>>>> But the good thing about an open ecosystem is - we can ask! :) >>>>>> >>>>>> I took the liberty of sending an email >>>>>> <https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0102.html> >>>>>> to the IETF's HTTP-WG, asking for their opinions. We are likely to find >>>>>> CDNs and web server implementers there. >>>>>> >>>>>> Otherwise, it'd be good to file for a TAG review >>>>>> <https://github.com/w3ctag/design-reviews>, as well as get signals >>>>>> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u> >>>>>> >>>>>> from other browser vendors. >>>>>> >>>>>> Finally, I'm curious to hear from +Eric Portis and +Doyle, Nick if >>>>>> (3) above was ever a problem they've encountered (and what they think of >>>>>> the "content-encoding vs. image format" question in general). >>>>>> >>>>>> Cheers :) >>>>>> Yoav >>>>>> >>>>>> >>>>>> On Mon, Aug 10, 2020 at 12:33 PM Evgenii Kliuchnikov < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> +jyrki >>>>>>> >>>>>>> On Thursday, August 6, 2020 at 8:13:10 PM UTC+2 Daniel Bratell wrote: >>>>>>> >>>>>>>> For jxl as an image format in particular, do you have any guess on >>>>>>>> how likely other vendors are to support it? >>>>>>>> >>>>>>>> /Daniel >>>>>>>> On 2020-07-31 18:30, 'Evgenii Kliuchnikov' via blink-dev wrote: >>>>>>>> >>>>>>>> Actually we want both. For image format we will file separate >>>>>>>> intent. Content-Encoding would be a choice for majority of already >>>>>>>> existing >>>>>>>> sites, beacause: >>>>>>>> * delivered content is exactly the same >>>>>>>> * CDNs are free to apply this tranformation >>>>>>>> * users will be able to save images and it is guaranteed that >>>>>>>> those images will be understood by the existing software (as those are >>>>>>>> regular JPEGs) >>>>>>>> * etc. >>>>>>>> >>>>>>>> Will add this section to explainer tonight. >>>>>>>> >>>>>>>> On Fri, Jul 31, 2020, 18:10 Yoav Weiss <[email protected]> wrote: >>>>>>>> >>>>>>>>> Awesome, thanks! >>>>>>>>> >>>>>>>>> Thanks for working on this! :) >>>>>>>>> >>>>>>>>> Can you elaborate on the choice to implement this is a content >>>>>>>>> encoding, rather than as an image format? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jul 31, 2020 at 5:58 PM Evgenii Kliuchnikov < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Thanks for checking. Now should work: >>>>>>>>>> *Design Doc*: >>>>>>>>>> https://docs.google.com/document/d/e/2PACX-1vQuwSbPNWwFhMXnK2rkdsyvTPGRDpX3kET-StAFqPZG43utfW1rZ-smsYoLodnNNIkNtZjlIIKol_kb/pub >>>>>>>>>> >>>>>>>>>> On Friday, July 31, 2020 at 5:54:17 PM UTC+2 [email protected] wrote: >>>>>>>>>> >>>>>>>>>>> On Fri, Jul 31, 2020 at 5:43 PM 'Evgenii Kliuchnikov' via >>>>>>>>>>> blink-dev <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Update: >>>>>>>>>>>> *Design Doc*: >>>>>>>>>>>> https://docs.google.com/document/d/e/2PACX-1vT7wTH3IlhAL12Av8VrwlBXdqozrsk1-_5SdHlHxZ--Vo2avj_2D6UxnQoOo0BxHefoMDIdco-NQ4fi/pub >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The document doesn't seem to be public. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> *TAG Review*: >>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/541 >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, July 30, 2020 at 10:49:48 AM UTC+2 Evgenii >>>>>>>>>>>> Kliuchnikov wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Surely. This will not be much different from "br" >>>>>>>>>>>>> Content-Encoding and there we do check if either scheme is >>>>>>>>>>>>> cryptographic, >>>>>>>>>>>>> or domain is localhost (see >>>>>>>>>>>>> https://source.chromium.org/chromium/chromium/src/+/master:net/url_request/url_request_http_job.cc;drc=2e3998904a6f19a0e6372f6a411d7f6adddf4689;l=543?originalUrl=https:%2F%2Fcs.chromium.org%2F >>>>>>>>>>>>> ) >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, July 30, 2020 at 8:54:20 AM UTC+2 PhistucK wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Can it be advertised over http://localhost:x as well (it is >>>>>>>>>>>>>> already considered secure for other purposes)? This will aid the >>>>>>>>>>>>>> development of support for this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ☆*PhistucK* >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jul 30, 2020 at 12:40 AM 'Evgenii Kliuchnikov' via >>>>>>>>>>>>>> blink-dev <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails [email protected] Explainer >>>>>>>>>>>>>>> https://github.com/google/brunsli https://brunsli.dev/ >>>>>>>>>>>>>>> https://brunsli.dev/split.html?progressive Design docs/spec >>>>>>>>>>>>>>> Specification: https://arxiv.org/pdf/1908.03565.pdf >>>>>>>>>>>>>>> https://docs.google.com/document/d/1jiuaWa_xgFEnc7ILIajU8CBceNNcCa5dbEK-QdSecVA/edit#heading=h.xgjl2srtytjt >>>>>>>>>>>>>>> TAG >>>>>>>>>>>>>>> review Summary JPEG XL is a next generation image format. >>>>>>>>>>>>>>> One of its features is byte-wise lossless JPEG image repacking. >>>>>>>>>>>>>>> On average, >>>>>>>>>>>>>>> encoded image is 22% smaller. This encoding could be used as an >>>>>>>>>>>>>>> HTTP >>>>>>>>>>>>>>> "Content-Encoding" specifically for JPEG image transfer (such >>>>>>>>>>>>>>> content is >>>>>>>>>>>>>>> considered non-compressible for general-purpose formats like >>>>>>>>>>>>>>> Brotli and >>>>>>>>>>>>>>> Gzip). Proposed encoding name: 'jxl' Motivation Losslessly >>>>>>>>>>>>>>> reduce interned traffic. Make internet faster. Risks >>>>>>>>>>>>>>> Interoperability and Compatibility As with 'br' >>>>>>>>>>>>>>> Content-Encoding we anticipate problems with incorrect proxies >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> recommend advertising new encoding only over opaque connection >>>>>>>>>>>>>>> (HTTPS, >>>>>>>>>>>>>>> etc.) *Gecko*: No signal *WebKit*: No signal *Web >>>>>>>>>>>>>>> developers*: No signals Ergonomics While it is possible to >>>>>>>>>>>>>>> process format incrementally, it would be beneficial to add >>>>>>>>>>>>>>> support for >>>>>>>>>>>>>>> decoding off-loading for net/filters Activation There are >>>>>>>>>>>>>>> Apache and nginx plugins for serving 'jxl' compressed content. >>>>>>>>>>>>>>> Demo-page is >>>>>>>>>>>>>>> powered by polyfill ServiceWorker. Security Data parsing. >>>>>>>>>>>>>>> Thoroughly fuzzed. >>>>>>>>>>>>>>> Debuggability Not required. Will this feature be supported >>>>>>>>>>>>>>> on all six Blink platforms (Windows, Mac, Linux, Chrome OS, >>>>>>>>>>>>>>> Android, and >>>>>>>>>>>>>>> Android WebView)? Yes Every platform is free to advertise >>>>>>>>>>>>>>> 'jxl' in 'Accept-Encoding' header. Plaftorms that do not >>>>>>>>>>>>>>> support it will >>>>>>>>>>>>>>> receive conventional traffic. Is this feature fully tested >>>>>>>>>>>>>>> by web-platform-tests >>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>> ? No jxl Content-Encoding is advertised only over HTTPS jxl >>>>>>>>>>>>>>> content is decoded into original JPEG content Link to entry >>>>>>>>>>>>>>> on the Chrome Platform Status >>>>>>>>>>>>>>> https://www.chromestatus.com/feature/5678152091172864 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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 on the web visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBjS75%3D%2B%3DSexFkJ7ewkBXDOF6FhkpwQYBeWn6sT57n1-_w%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBjS75%3D%2B%3DSexFkJ7ewkBXDOF6FhkpwQYBeWn6sT57n1-_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>> 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 on the web visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9d202b2d-c141-45fc-b86b-b768dcba5cccn%40chromium.org >>>>>>>>>>>> >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9d202b2d-c141-45fc-b86b-b768dcba5cccn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>> 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 on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBj7M9qd%2BGGAX%2BH1WBPqQLeAUuxpgBoqc%3DWsELayyqmyAA%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZPrBj7M9qd%2BGGAX%2BH1WBPqQLeAUuxpgBoqc%3DWsELayyqmyAA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>>> -- 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/f94f9dc2-b408-42c3-8dd4-03605ba106ben%40chromium.org.
