| ▲ | YesThatTom2 4 hours ago | ||||||||||||||||
Drat! I hoped this was going to cover the internal battle where Google executives trying to stop JPEG XL and how engineers finally convinced them to change their minds. My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support. | |||||||||||||||||
| ▲ | pwg 4 hours ago | parent | next [-] | ||||||||||||||||
> The executives just gave up once all the other browsers had added support. The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer. | |||||||||||||||||
| ▲ | surajrmal 3 hours ago | parent | prev | next [-] | ||||||||||||||||
It's interesting how different theories come about when there is a lack of information and a high degree of preexisting bias. Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format. However as industry adoption increased and a newer safe library appeared, the decision was changed. Also, note that while Google developed the new rust library, it wasn't the chrome team who made the investment. | |||||||||||||||||
| |||||||||||||||||
| ▲ | cbolton 3 hours ago | parent | prev | next [-] | ||||||||||||||||
That's... not what happened? See the timeline I posted here: https://news.ycombinator.com/item?id=49445897 JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't. | |||||||||||||||||
| |||||||||||||||||
| ▲ | moebrowne 27 minutes ago | parent | prev | next [-] | ||||||||||||||||
I think it might have something to do with a Rust based decoder becoming available. IIRC one of the reasons for not implementing it before was expanding the attack surface. | |||||||||||||||||
| ▲ | pmarreck 4 hours ago | parent | prev | next [-] | ||||||||||||||||
My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle | |||||||||||||||||
| |||||||||||||||||
| ▲ | nikanj 4 hours ago | parent | prev | next [-] | ||||||||||||||||
They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027 | |||||||||||||||||
| ▲ | SillyUsername 4 hours ago | parent | prev [-] | ||||||||||||||||
I thought the reasoning was Google wanted to cartel their own fledgling webp format and didn't want to promote competition? | |||||||||||||||||
| |||||||||||||||||