11–20 of 58 posts
You know, if you did that in the other order, you might avoid a lot of sturm und drang.
I really like JPEG XL tech, seemed like the first format that could completely replace animated gif, png, jpeg with a simple upgrade path and backwards compatability story for lots of weird corner case usages. I do have sympathy for the not adding lots of formats to the web argument though.
Rationale from thread: > 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 t…
Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments)
Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments)
Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments)
Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments)
Also:
The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 - Nov 2022 (207 comments)
Is there SNI (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...) in the current post? - if there is I can't find it.
> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), What's that mean? What's a browser partner? What's a device partner? How do additional formats cost to those "partners", as the format handling would be performed by Chrome already?
So does this mean we are getting AVIF or WebP or both? It's not clear to me which is the "blessed" format out of these. HEIC is ofcourse there but proprietary.
One advantage for AVIF is that an AVIF file is very close to just being an AV1 still, so if you implement AV1, you've basically got 95% of AVIF already. AVIF is also now natively supported by both Windows, macOS, iOS, and Android, whereas JXL is supported natively by none. The fact that AVIF has gotten OS-level support and JXL hasn't is a sign JXL is dead.
Rationale from thread: > 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 t…
I think it's a legitimately different tradeoff because the recompression is not like a new lossy format--less code, plus you don't need the whole ecosystem to move, big sites and CDNs can transparently start using it--but still substantial (22% on JPEG content out there). And by being very CPU-light it fills a fairly large gap where people are not ready to use AVIF, which needs either dedicated hardware or tons of CPU to encode.
One thing this is right about is a WASM polyfill is interesting. With that and a ServiceWorker, you can make the recompression pretty transparent (right-click saves a .jpg) but still save your 22%. The performance penalty of doing it in WASM is a question, but it's definitely possible.
> We've also heard from our browser and device partners that every additional format adds costs (monetary or hardware), What's that mean? What's a browser partner? What's a device partner? How do additional formats cost to those "partners", as the format handling would be performed by Chrome already?
Phones, TVs, Toasters