Am I having a stroke, or is this headline horrendously written?
this post was submitted on 04 Feb 2024
211 points (87.8% liked)
Technology
59438 readers
3544 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
I read it four times and I still don't understand what love-in means.
Dumb way of saying orgy.
I still don't understand. WTF are we talking about. This is tech news, not a celeb scandal. Why can't we just use simple words !
Why say lot word when few word do trick?
What's the smart way?
Orgy.
Dinner Party. I think group sex is just implied, right?
I did decline a event because it said "Dinner Party" in quotes.
When they explained, they meant because it's not really dinner but snacks and board games. Shame. Was expecting orgy
That’s called “Game Night”
Don’t ever go to a game night that is called a “dinner party” anyway. You’re likely to get roped into their self-created board game that is, “okay so it’s got a lot of rules and 1400 pieces, but I’ve written them all down on this 20 page spiral bound document and everyone will get a copy and an hour to read”
P.s. Fuck you Aaron, I will never come to your “dinner party” again.
Hahahah, upvote for including the tidbit with your PS and not making us ask.
As someone with very limited short-term/working memory, I feel your pain.
I believe you just responded to a message with the answer to your question.
Horrible headline.
Browser maker love-in
Chromium (used by most browsers)
snubs
doesn't support
Google-shunned JPEG XL
JPEG XL (because Google doesn't like it)
It was chrome and Firefox both who were against the format, both saying too expensive to implement for too small a benefit
Thank you. I legitimately could not understand the title.
Something about love in subs for Google ? And also JPEG?
I think these days that's the rule, if it piques your interest but you have some trouble understanding headline, you may just click on the article
The register is doing this shit for years. They are trying to sound smart...
What is this bullshit titlegore
Right? I read it like three times thinking I was just missing an inflection or something. Jesus
I'm a photographer; AVIF and WebP do not serve my needs, JPEG-XL does.
I run my own website down to the hardware in my living room; I will not store 5 variations of any 1 picture just so I can serve the best available to clients when JPEG works everywhere and JPEG-XL offers me a lossless transition from JPG to JXL.
Chromium is literally the only reason JPEG-XL isn't being adopted right now, and it's so obvious that Google is pulling those strings.
JPEG-XL Ride or Die.
Mozilla has not jumped on the JPEG XL bandwagon either: The Firefox maker said it's neutral with regard to the technology, citing cost and lack of significant differentiation from other image codecs.
Two browser orgs.
Not arguing just pointing it out
Mozilla are also dumb, yes, but they aren't the one in control of 90% of the browser marketshare.
There is a difference between indifference and actively working against something.
I saw a web warning saying “if you cant see {x} then consider upgrading to Firefox” today and it fill me with joy
GIF is the future Mr Cameraman
load more comments
(5 replies)
I still won't get over it and will keep fighting for JPEG XL. It would fix so many issues and greatly reduce the bandwidth need of the internet while not either having weird licensing or royalties and / or being a „what if we just took one frame from a video“ picture format. Also it can encode back to JPEG lossless for legacy uses. What more could one want?
Well... Google wants weird licensing or royalties, that's why they keep stamping it down.
I mean there are advantages to using AV1 for photos... Hardware accelerated decoding being one.
Decoding a large AVIF image grid should in theory work on a GPU and happen faster with less power than any software based image format implementation.
AV1 is also just an awesome format that's entirely free to use out of the gate.
Well yes, however without acceleration JPEG XL is many times faster. Also if you only have a CPU for example.
It's also highly parallelizable compared to AVIF which also matters a lot considering the amount of cores is growing with the likes of ARM and hybrid architecture CPU.
AVIF also fairs badly with high fidelity and lossless encoding, has 1/3 the bit depth and pretty small dimension limits for something like photography.
I don't think AVIF is per se a bad format. I just think if I want to replace a photo oriented format I'd like to do that with one that's focused on „good“ photos and not just an afterthought with up- and downsides.
Also if you only have a CPU for example.
I thought even mobile-tier integrated GPUs can decode AV1 extremely quickly.
Well yes sure, but remember AV1 decoding only became standard like 1-2 GPU generations ago. Encoding only this generation. iPhones only got support with the 15 Pro so it will be another generation before it trickles down to the base models. And what about the hundreds of millions of Android phones in Asia and the likes with dirt cheap SoCs. Pretty sure they don't have dedicated AV1 decoding hardware for a long time.
So that's a TON of hardware being made slow and inefficient if everything were to be AVIF tomorrow. Not saying AVIF decoding will be a big hurdle in the future but how long until all this hardware browsing the web has been replaced? That's why I think somethings that's efficient and fast on CPUs without any specialised hardware is more suited for a replacement.
Servers often come without GPU, and they’re usually the ones encoding image formats.
load more comments
(1 replies)
Isn't AV1 exclusively for video recoding? I haven't heard of it being used for photos.
Thanks to wasm, you don't have to bow to Google's whim and can choose to include jpeg xl support on your websites if you want: https://github.com/niutech/jxl.js
Do you know if it uses the native decoder if available (so, in Safari I guess)? Doesn't say in the readme.
I believe so. This line in the source code means it'll only attempt the decoding if an img element for a .jxl image url fails to load.
If you're on safari, you can verify it by going to the demo page at https://niutech.github.io/jxl.js/ and inspect the image element. If the src attributes contain blob, then it's decoded using the wasm decoder. If the src attribute contains url to a .jxl file, then it's decoded natively.
Very cool, thanks. Will keep this in mind.
load more comments
(2 replies)
"Overall, we don't see JPEG-XL performing enough better than its closest competitors (like AVIF) to justify addition on that basis alone," said Martin Thomson, distinguished engineer at Mozilla, last year. "Similarly, its feature advancements don't distinguish it above the collection of formats that are already included in the platform."
So is this a legit take on the technology? Sounds like an expert in the field is pretty convinced that this file format isn't really worth it's weight. What does JXL give the web that other file formats don't?
Perhaps true from his... perspective. I've found JXL surprisingly awesome and easy to use (size, quality, speed, intuitive encoding options with lossless, supported in XnView & XnConvert for easy batches). AVIF was terrible in real-world use last I tried (and blurs fine details).
I'm still a big Mozilla & Firefox fan, but a few decisions over past few years seem like they're being dictated or vetoed by a few lofty individuals (while ignoring popular user requests). Sad.
I've read a comparison of several newer file formats (avif, heic, webp) with jpeg-xl. The conclusion was that jpeg-xl was on par in terms of compression, sometimes better and very fast. also it can re-compress jpgs directly.
here's an article describing it https://cloudinary.com/blog/the-case-for-jpeg-xl
The big thing, to me, is that it can losslessly encode JPEGs, the dominant format for allllll sorts of archived images. That's huge for migration of images that don't necessarily exist in any other format.
Plus, as I understand it, JPEG XL performs better at those video-derived formats at lossless high resolution applications relating to physical printing and scanning workflows, or encoding in new or custom color spaces. It's designed to work in a broader set of applications than the others, beyond just web images in a browser.
If Google says chromium won't support a feature it won't be used. The majority of browsers are Chromium under the hood.
A third party adaptation of Chromium could add support for other formats, the ones we know about right now just don’t bother.
This is the best summary I could come up with:
The process began last year by gathering proposals for web technologies that group members will try to harmonize using automated tests.
The goal is to ensure browser implementations of these technologies match specifications in order to make the web platform better for developers.
Mozilla has not jumped on the JPEG XL bandwagon either: The Firefox maker said it's neutral with regard to the technology, citing cost and lack of significant differentiation from other image codecs.
"Overall, we don't see JPEG-XL performing enough better than its closest competitors (like AVIF) to justify addition on that basis alone," said Martin Thomson, distinguished engineer at Mozilla, last year.
And it has since resisted entreaties to reconsider – despite Apple's endorsement last year and recent support from Samsung and apparent interest from Microsoft.
"Chrome is 'against' because of 'insufficient ecosystem interest' and because they want to promote improvements in existing codecs," said Sneyers, pointing to JPEG, WebP, and AVIF.
The original article contains 907 words, the summary contains 155 words. Saved 83%. I'm a bot and I'm open source!
view more: next ›