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?
Google unkills JPEG XL?
161–170 of 283 posts
Re: Google unkills JPEG XL?
#162Earlier 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).
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?
#163Isn'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'…
Re: Google unkills JPEG XL?
#164It 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 this is working out is a combination of wishful thinking and getting lucky.
Re: Google unkills JPEG XL?
#165Isn'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
Re: Google unkills JPEG XL?
#166Earlier 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…
Re: Google unkills JPEG XL?
#167Earlier 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.
Re: Google unkills JPEG XL?
#168Re: Google unkills JPEG XL?
#169Earlier 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.
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…
going crazy reading this sentence