--
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 blink-dev+...@chromium.org.
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.
Update:
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.
For jxl as an image format in particular, do you have any guess on how likely other vendors are to support it?
/Daniel
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.
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- 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. 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.)
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 <jy...@google.com> 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
- 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
On Thu, Aug 20, 2020 at 11:21 PM Yoav Weiss <yo...@yoav.ws> 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 <jy...@google.com> 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 codecsTalking 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 mbpsIs this 100 mega *bits* or *bytes*? Do you have similar numbers for client-side typical CPU?