Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

161–170 of 283 posts

Re: Google unkills JPEG XL?

#161

Earlier quoted context omitted.

honestly hate webp so happy about this

I don't know much about webp. Just have checked the wiki, it looks nice. So for which reason you hate it?

It was mostly about compatibility but looks like photoshop supports it now so I guess I can now officially say I don't really care one way or the other.

Re: Google unkills JPEG XL?

#162
post #66

Earlier quoted context omitted.

With all due respect, this is a completely HN-brained take. No significant number of users chooses their browser based on support for image codecs . Especially not when no relevant website will ever use them until Safari and Chrome support them. And websites which already do not bother supporting Firefox very much will bother even less if said browser by-default refuses to allow them to make revenue. They may in fact…

I don't disagree with you, but given (A) how will Firefox ever compete? One possible way is doing things that Google and Chrome don't (can't). Catering to niche audiences (and winning those niches) gives people a reason to use it. Maybe one of the niches takes off. Catering to advanced users not necessarily a bad way to compete. Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).

>Being a feature-for-feature copy of Chrome is not a winning strategy (IMHO).

Good thing they aren't? Firefox's detached video player feature is far superior to anything Chrome has that I'm aware of. Likewise for container tabs, Manifest V2 and anti-fingerprinting mode. And there are AI integrations that do make sense, like local-only AI translation & summaries, which could be a "niche feature" that people care about. But people complain about that stuff too.

Re: Google unkills JPEG XL?

#163
post #37

Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…

Google is one of the parties involved in the creating of jxl. If it's their own fault they didn't write a decoder in a memory safe language sooner.

Re: Google unkills JPEG XL?

#164

It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence). [0] https://issues.chromium.org/issues/40168998#comment507

That library had a hiatus with zero commits of over 1.5 years until recently iirc.

That this is working out is a combination of wishful thinking and getting lucky.

Re: Google unkills JPEG XL?

#165
post #37

Isn't this due to the 100M+ line C++ multi-threaded dependency being a potential nightmare when you are dealing with images in browsers/emails/etc. as an attack surface? I think both Mozilla and Google are OK with this - if it is written in Rust in order to avoid that situation. I know the linked post mentions this but isn't that the crux of the whole thing? The standard itself is clearly an improvement over what we'…

because memory safety is the only attack vector, as we all know

It is a very big one and eliminating it is a huge improvement in security. You can then spend more time fixing all the other sources of security problems.

Re: Google unkills JPEG XL?

#166

Earlier quoted context omitted.

According to tokei, the lib/ directory from the reference implementation [0] has 93821 lines of C++ code and 22164 lines of "C Header" (which seems to be a mix of C++ headers, C headers, and headers that are compatible with both C and C++). The tools/ directory adds 16314 lines of C++ code and 1952 lines of "C Header". So at least if GP was talking about libjxl "100K+" would be more accurate. [0]: https://github.com/…

>> 100M+ is a bit more than i would expect for an image format. have i not been paying attention > So at least if GP was talking about libjxl "100K+" would be more accurate. M can mean thousands and I think it's common to use it used that way in finance and finance-adjacent areas: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/A... : > A. You’ve identified two commonly used conventions in finance, one der…

I don't think many (if any) programmers would imagine 100M lines of code to mean 100,000 lines of code and not 1,000,000...

Re: Google unkills JPEG XL?

#167

Earlier quoted context omitted.

The worst epubs are bad because some jackass took some poorly OCRed text and dumped it into the format. The best (retail) epubs are on par with the best PDFs except you don't have to pan-and-scan to read a fucking page. It just reflows. For novels I want and prefer epubs, but also non-novels if they were released in the last 5 years or so. PDF isn't magic, and there are bad pdfs out there too, scans of photo-copied b…

I oversee ebook production for a uni press so I am familiar with how the proverbial sausage is made. Which is why I still mainly prefer print books.

There might be something said for academic texts with their tables of figures and diagrams and so forth. But even then, PDF can be nasty.

Re: Google unkills JPEG XL?

#169
post #97

Earlier quoted context omitted.

no one asked, but FYI in English it is more commmon to say "for several years" instead of "since some years" :)

German speakers usually have very good English, but this is one of their tells.

Another one I've noticed is using "I've" as a contraction in e.g. "I've a meeting to attend". Seems totally reasonable but for some reason native speakers just don't use it that way.

Re: Google unkills JPEG XL?

#170

"in favor of the homegrown and inferior AVIF" I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif. I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is. As for JPEG XL - I think the problem here is ... Google. G…

> I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif

going crazy reading this sentence

Post reply on HN