On Tue, Jun 20, 2023 at 5:35 PM ― <hmz2...@gmail.com> wrote: > Worth Noting: On top of Apple support, Mozilla is now looking into Jxl > integration again. From neutral to positive. >
This is incorrect. https://mozilla.github.io/standards-positions/#jpegxl is still neutral. cheers, > Chrome will need feature parity even if chromium doesn’t have it. > > > On Wed, 7 Jun 2023 at 15:32, ― <hmz2...@gmail.com> wrote: > >> >> *Update:* >>> >> >> >> >>> Firefox: >>> In testing builds. (Neutral - depending on support from community.) >>> >>> Safari (& iOS): >>> Currently undergoing testing & implementation as of latest iOS/macOS dev >>> previews. (Positive.) >>> >>> Web Developers & Community: >>> (Very Positive Support) >>> >> >> >> >>> - - - - - - - - - >>> >> >> >> Support added by a lot of apps with more showing support should Google >>> Chrome (and ChromeOS) support the format by default & Android Community has >>> requested support for it too alongside some in the Windows Insider >>> Community. >>> >>> This would also be welcomed by the Digital art community, the medical >>> community for scans, and have benefits for streamlining online image >>> storage with a healthy balance of quality vs size taken up. >>> >>> Fwiw, I also support JPG-XL adoption to have healthy competition with >>> AVIF/WebP and I'm neither a developer nor a representative of any company. >>> Just a tech user enthusiast, I've also met countless of people supporting >>> the view. >>> >>> 1,000 in Chromium bug tracker over 500 in Mozilla's Trending Feature >>> Requests, then you have those on reddit and Phoronix wishing to raise their >>> support for the matter. >>> >>> But let's not beat around the bush here, support from Chromium/Chrome >>> can make or break something like this, regardless of whether or not it is >>> logically right to do so, Google knows that fact all too well by now. >>> >>> >>> >>> On Tue, 6 Jun 2023, 11:50 Albert Andaluz González, < >>> albertanda...@gmail.com> wrote: >>> >>>> The Chrome status page ( >>>> https://chromestatus.com/feature/5188299478007808) should now mention >>>> that Webkit supports jpeg-xl, at least for Safari 17 beta onwards. >>>> >>>> https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes >>>> See also relevant WWDC2023 session (Explore media formats for the web) >>>> : >>>> https://developer.apple.com/videos/play/wwdc2023/10122/ (available 8th >>>> June) >>>> >>>> >>>> El sábado, 17 de diciembre de 2022 a las 22:55:47 UTC+1, ⸻ “How Things >>>> Work” escribió: >>>> >>>>> >>>>> 800 Users with hundreds of comments seem to be distrustful after the >>>>> previous ones, can't that be considered or taken into account for the >>>>> request? There are many developers from quite a few big name companies >>>>> such >>>>> as Facebook/Meta & Intel too. Also use cases highlighted, such as Medical >>>>> Imaging. Regardless of how this is spun, it would seem that this format >>>>> would see widespread adoption & implementation across multiple industries >>>>> if it were permitted to be enabled by default. >>>>> >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - One >>>>> again leaving this link for reference, please reconsider, a lot of work >>>>> would go to waste when we could all just compromise and improve on the >>>>> format in the future >>>>> On Saturday 17 December 2022 at 03:53:10 UTC Yaowu Xu wrote: >>>>> >>>>>> Thanks for the feedback regarding speed tests, please see updated >>>>>> decoding timing info on latest builds on more platforms: >>>>>> https://storage.googleapis.com/avif-comparison/decode-timing.html >>>>>> >>>>>> >>>>>> On Tuesday, December 13, 2022 at 8:19:40 AM UTC-8 Markus K. wrote: >>>>>> >>>>>>> I find it very concerning that this decision is has evidently been >>>>>>> based on this bogous data: >>>>>>> https://storage.googleapis.com/avif-comparison/index.html >>>>>>> >>>>>>> 1. The speed comparison is based on a buggy and outdated JPEG >>>>>>> XL implementation. >>>>>>> 2. The filesize comparison is based on a metric that JPEG XL was not >>>>>>> tuned for. >>>>>>> >>>>>>> On top of that we seem to have completely misjudged ecosystem and >>>>>>> industry demand for JPEG XL . >>>>>>> And there seems to have been no consideration for certain features, >>>>>>> which I don't want to reiterate here, that AVIF just doesn't support. I >>>>>>> think there is a place for JPEG XL alongside AVIF. >>>>>>> >>>>>>> I would suggest to halt the removal of the JPEG XL experiment in >>>>>>> Chromium until this is addressed to prevent further harm based on bad >>>>>>> science. >>>>>>> >>>>>>> On Sunday, December 4, 2022 at 7:00:22 PM UTC+1 ⸻ “How Things >>>>>>> Work” wrote: >>>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - >>>>>>>> Also requesting a reconsideration of.JXL as a format due to >>>>>>>> cross-industry >>>>>>>> interest from companies & consumers alike. Also on the grounds of it >>>>>>>> being >>>>>>>> hindered by being buried behind an obscure flag within beta builds :/ >>>>>>>> >>>>>>>> Could just revert the removal till the M111 or 112 builds and see >>>>>>>> how things stand then, would give time for debate *& a more fairer >>>>>>>> test of market sentiment for this open JPEG standard*. >>>>>>>> >>>>>>>> On Friday 2 December 2022 at 23:05:15 UTC Tomáš Poledný wrote: >>>>>>>> >>>>>>>>> Now you should run your tests again with this: >>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4031214 >>>>>>>>> >>>>>>>>> Dne pátek 2. prosince 2022 v 22:20:19 UTC+1 uživatel Jarek Duda >>>>>>>>> napsal: >>>>>>>>> >>>>>>>>>> If there are objectivity concerns, maybe there available tests of >>>>>>>>>> independent sources? >>>>>>>>>> For example Phoronix often uses libjxl in benchmarks - at least >>>>>>>>>> for speed getting very different numbers: >>>>>>>>>> https://www.phoronix.com/review/aocc4-gcc-clang/3 - maybe there >>>>>>>>>> are available other independent tests? >>>>>>>>>> >>>>>>>>>> [image: obraz.png] >>>>>>>>>> >>>>>>>>>> On Friday, December 2, 2022 at 6:57:35 PM UTC+1 Yaowu Xu wrote: >>>>>>>>>> >>>>>>>>>>> Following Jim’s previous note, here is a link to tests >>>>>>>>>>> <https://storage.googleapis.com/avif-comparison/index.html> >>>>>>>>>>> AVIF engineers ran comparing AVIF to JPEG, WebP and JPEG-XL. The >>>>>>>>>>> tests >>>>>>>>>>> provide all the necessary code, test sets and parameters to >>>>>>>>>>> reproduce the >>>>>>>>>>> test results. Developers are welcome to ask questions and submit >>>>>>>>>>> feedback >>>>>>>>>>> to avif-f...@googlegroups.com. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Apologies for the delay in providing this information. We >>>>>>>>>>> wanted to be sure that everyone would be able to duplicate and >>>>>>>>>>> verify these >>>>>>>>>>> results for themselves before posting. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Friday, November 11, 2022 at 7:58:28 AM UTC-8 Jim Bankoski >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Helping the web to evolve is challenging, and it requires us to >>>>>>>>>>>> make difficult choices. We've also heard from our browser and >>>>>>>>>>>> device >>>>>>>>>>>> partners that every additional format adds costs (monetary or >>>>>>>>>>>> hardware), >>>>>>>>>>>> and we’re very much aware that these costs are borne by those >>>>>>>>>>>> outside of >>>>>>>>>>>> Google. When we evaluate new media formats, the first question we >>>>>>>>>>>> have to >>>>>>>>>>>> ask is whether the format works best for the web. With respect to >>>>>>>>>>>> new image >>>>>>>>>>>> formats such as JPEG XL, that means we have to look >>>>>>>>>>>> comprehensively at many >>>>>>>>>>>> factors: compression performance across a broad range of images; >>>>>>>>>>>> is the >>>>>>>>>>>> decoder fast, allowing for speedy rendering of smaller images; are >>>>>>>>>>>> there >>>>>>>>>>>> fast encoders, ideally with hardware support, that keep encoding >>>>>>>>>>>> costs >>>>>>>>>>>> reasonable for large users; can we optimize existing formats to >>>>>>>>>>>> meet any >>>>>>>>>>>> new use-cases, rather than adding support for an additional >>>>>>>>>>>> format; do >>>>>>>>>>>> other browsers and OSes support it? >>>>>>>>>>>> >>>>>>>>>>>> After weighing the data, we’ve decided to stop Chrome’s JPEG >>>>>>>>>>>> XL experiment and remove the code associated with the experiment. >>>>>>>>>>>> We'll >>>>>>>>>>>> work to publish data in the next couple of weeks. >>>>>>>>>>>> >>>>>>>>>>>> For those who want to use JPEG XL in Chrome, we believe a >>>>>>>>>>>> WebAssembly (Wasm) implementation is both performant and a great >>>>>>>>>>>> path >>>>>>>>>>>> forward. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jim >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Monday, October 31, 2022 at 11:01:44 AM UTC-7 >>>>>>>>>>>> ash...@scirra.com wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Apologies for bringing back an old thread, but I thought it >>>>>>>>>>>>> was important to bring this up here. >>>>>>>>>>>>> >>>>>>>>>>>>> I was surprised to read that Google are abandoning their >>>>>>>>>>>>> efforts to implement JPEG-XL: >>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 >>>>>>>>>>>>> >>>>>>>>>>>>> As I understood it, JPEG-XL brought significant improvements >>>>>>>>>>>>> over existing image formats, and had a lot of interest in the >>>>>>>>>>>>> technology >>>>>>>>>>>>> world. However the reasons cited were apparently lack of benefits >>>>>>>>>>>>> and lack >>>>>>>>>>>>> of interest. >>>>>>>>>>>>> >>>>>>>>>>>>> I for one was interested in this format and the improvements >>>>>>>>>>>>> it would bring, and it seems many others are disappointed too. >>>>>>>>>>>>> Can Google >>>>>>>>>>>>> explain how they came to this conclusion? How are they evaluating >>>>>>>>>>>>> the >>>>>>>>>>>>> benefits and interest? Even this intent to prototype lists many >>>>>>>>>>>>> of the >>>>>>>>>>>>> purported benefits and the extent of the interest, which makes >>>>>>>>>>>>> this >>>>>>>>>>>>> reversal particularly hard to understand. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, 30 Mar 2021 at 20:20, 'Moritz Firsching' via blink-dev >>>>>>>>>>>>> <blin...@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *de...@chromium.org, firs...@google.com, lo...@google.com, >>>>>>>>>>>>>> jy...@google.com*Explainer >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *https://jpeg.org/jpegxl/ >>>>>>>>>>>>>> <https://jpeg.org/jpegxl/>http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf >>>>>>>>>>>>>> <http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf>* >>>>>>>>>>>>>> Specification >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *https://arxiv.org/abs/1908.03565 >>>>>>>>>>>>>> <https://arxiv.org/abs/1908.03565>*Summary >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *JPEG XL is a new royalty-free image codec targeting the >>>>>>>>>>>>>> image quality as found on the web, providing about ~60% size >>>>>>>>>>>>>> savings when >>>>>>>>>>>>>> compared to original JPEG at the same perceptual quality, while >>>>>>>>>>>>>> supporting >>>>>>>>>>>>>> modern features like HDR, animation, alpha channel, lossless JPEG >>>>>>>>>>>>>> recompression, lossless and progressive modes. It is based on >>>>>>>>>>>>>> Google's PIK >>>>>>>>>>>>>> and Cloudinary's FUIF, and is in the final steps of >>>>>>>>>>>>>> standardization with >>>>>>>>>>>>>> ISO.This feature enables image/jxl decoding support in the blink >>>>>>>>>>>>>> renderer.*Blink >>>>>>>>>>>>>> component >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Blink>Image >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>* >>>>>>>>>>>>>> Motivation >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *The main motivations for supporting JPEG XL in Chrome are: - >>>>>>>>>>>>>> The improvement in image quality vs image size, about 60% file >>>>>>>>>>>>>> size savings >>>>>>>>>>>>>> for the same visual quality (lossy compression of larger >>>>>>>>>>>>>> originals) when >>>>>>>>>>>>>> compared to JPEG at the qualities found on the web.- Improved >>>>>>>>>>>>>> visual >>>>>>>>>>>>>> latency by both smaller download sizes and supporting >>>>>>>>>>>>>> progressive decoding >>>>>>>>>>>>>> modes. - Support for HDR, animation and progressive all together >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> same image codec. - Support for lossless-recompressed JPEGs - >>>>>>>>>>>>>> Ecosystem >>>>>>>>>>>>>> interest in JPEG XL: Several Google teams evaluated using JPEG >>>>>>>>>>>>>> XL for >>>>>>>>>>>>>> storing and delivering images, as well as outside of Google: >>>>>>>>>>>>>> including CDNs >>>>>>>>>>>>>> interest in storing lossless-recompressed JPEGs as JPEG XL and >>>>>>>>>>>>>> converting >>>>>>>>>>>>>> to JPEG on request is the browser doesn't support JXL. Facebook >>>>>>>>>>>>>> is >>>>>>>>>>>>>> exploring to use JPEG XL.*Initial public proposal >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Support decoding image/jxl behind a feature flag which is >>>>>>>>>>>>>> turned off by default on all platforms. *Search tags >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *jxl <https://www.chromestatus.com/features#tags:jxl>*TAG >>>>>>>>>>>>>> review >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Not applicable for image decoders*TAG review status >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Not applicable*Risks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *JPEG XL is in the final stage ISO standardization. Firefox >>>>>>>>>>>>>> has an open bug: >>>>>>>>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 >>>>>>>>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1539075>Edge/Safari >>>>>>>>>>>>>> - no >>>>>>>>>>>>>> signals yetGecko: No signalWebKit: No signalWeb developers: high >>>>>>>>>>>>>> interest/many stars in the tracking bug, and there was a >>>>>>>>>>>>>> separate external >>>>>>>>>>>>>> crbug requesting the feature. A lot of interest on encode.su >>>>>>>>>>>>>> <http://encode.su>, r/jpegxl, <https://reddit.com/r/jpegxl/> >>>>>>>>>>>>>> discord >>>>>>>>>>>>>> <https://discord.com/channels/794206087879852103>, ...*Is >>>>>>>>>>>>>> this feature fully tested by web-platform-tests >>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>> ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *No, but planning to have complete tests before shipping. >>>>>>>>>>>>>> *Tracking >>>>>>>>>>>>>> bug >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058>*Launch >>>>>>>>>>>>>> bug >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178040 >>>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1178040>*Link >>>>>>>>>>>>>> to entry on the Chrome Platform Status >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://www.chromestatus.com/feature/5188299478007808 >>>>>>>>>>>>>> >>>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>> 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/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>> -- > Sent from Gmail Mobile > > -- > 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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Simon Pieters https://www.mozilla.com/ -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC7mYC6M_SNcE4NQSs736KVSBRYKEcq%3DOQVg46CYzkAmpTooJg%40mail.gmail.com.
