51–60 of 93 posts
Earlier quoted context omitted.
You say that as though Google isn't notorious for killing their own successful and well received products for seemingly no reason. It's incontrovertible that Google did attempt to kill browser adoption of jxl at one point. Thankfully they seem to have reversed course.
They only reversed under pressure from the Safari and Firefox folks. The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
Can someone explain where are we at the image processing world/timeline? Why do coding tools suggest to me .avif and .webp, and the support of these lags in Windows OS and then we have things like JpegXL and Jpeg2000 or whatever others are there flying around? Why is it so hard to find our next "jpg format"?
AVIF and webp kind of only exist for the web, they get used when you want to really crunch down on data as much as possible. They aren’t really used for files you’d save on your computer or get out of a camera. JPEG XL is replacing regular jpeg and heif for photography. It offers 16 bit color rather than 8 from jpeg and HDR support along with a ton of extra features. Every OS but Android supports it, safari supports…
Speaking only for webp here. It is designed to balance download and decompression time to load faster than it's competitors. Compressed filesize isn't generally smaller and compression time is notoriously slow.
That's rich coming from the company that tried to kill it. The audacity...
I guess today’s post represents a change.
I don’t have any public evidence to support my claim, sorry. Take it or leave it
They literally tried to kill it - stating (nonsensical) reasons why it was obsolete and unneeded.
And since now the rest of the world have adopted it despite Google, they have crawled out of their slime pits praising themselves for its development with only a passing mention of cloudinary?
Sickening.
Can someone explain where are we at the image processing world/timeline? Why do coding tools suggest to me .avif and .webp, and the support of these lags in Windows OS and then we have things like JpegXL and Jpeg2000 or whatever others are there flying around? Why is it so hard to find our next "jpg format"?
Hence the workflow with least amount of man-splaining is to stick to what the non-technical people know. Let them create everything in PNG (or JPG) with absolutely no compression whatsoever. Then have the origin server for the CDN substitute every requested image for a webp variant, mashed down to acceptable compression levels for the product/customer.
Since browsers don't care about file extensions for images, the images can be served with '.jpg' or '.png' extensions but contain webp. The browser will be fine with this because of the internal header in the image file.
Note that if the customer/user right clicks to download one of these webp images pretending to be png/jpg they should get served the PNG or JPG original, rather than the compressed webp. Yes it requires the origin server to read the headers and the CDN to read the headers too, however, this can be setup to be transparent to the people that create the images and the people that see them.
If the images are overly compressed or not compressed enough, the CDN cache can be cleared.
Note that this approach could be used to support JPEG XL right now, serving JPEG XL to browsers that support it and webp to those with lesser browsers.
What I find amusing about JPEG is that it was optimised for analogue CRTs and slow CPUs. We now have digital screens and fast(er) CPUs. The Mozilla encoder is easy to retrofit and this makes JPEG images better suited to what we have now rather than what we had in the 1980s. Things like banding goes away and the file sizes are smaller. Yet nobody adds the Mozilla libjpeg to their /bin/local.
Earlier quoted context omitted.
They only reversed under pressure from the Safari and Firefox folks. The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
Firefox isn't even enabling it
Earlier quoted context omitted.
You say that as though Google isn't notorious for killing their own successful and well received products for seemingly no reason. It's incontrovertible that Google did attempt to kill browser adoption of jxl at one point. Thankfully they seem to have reversed course.
They only reversed under pressure from the Safari and Firefox folks. The killing of JXL did push the ever-talented Jyrki to create jpegli, which was honestly a wonder.
It's really bizarre to me that this is presented as "killing the standard". Is Apple also killing mechanical keyboards and hobby electronics development because they're the only ones who don't support Web USB or Web Serial? I strongly prefer having JXL and Web USB/Serial in my browser (FF for the last 20 years), but come on. If we don't like how much power browsers have in software distribution, then maybe software distribution outside of browsers should get fixed.
* [0] https://github.com/mozilla/standards-positions/issues/522
* [1] https://github.com/mozilla/standards-positions/pull/1064
The sloppa in this article is... offending. The obvious AI headings, pointless genned image of people (I'm starting to think islam had a point with discouraging depictions of human figures), and especially the blurry, artifacted, distractingly skeuomorphic diagram, with random wire traces going everywhere... this is a technical blog, not an investor sales pitch! Every time I see one of these, I have to double-check f…
This article is not about the entropy codes and predictors, memory bandwidth and decision trees, but about the long horizon planning in corporate-driven OSS efforts and being connected to both community and cross-industry.
> In this Gemini-reconstructed scene, ... I'm generally pretty pro-AI, but I find this icky. Of course, I wouldn't have noticed except the whiteboard drawing seemed not quite right, so I'll probably be fooled in the future.
Earlier quoted context omitted.
Yep, I was totally nerd-sniped by the image. I've never seen an engineer draw a whiteboard diagram anywhere near that detailed and tidy. No acronyms, consistent title case, descenders on a baseline - everything about it is wrong. It's so counter to reality, I seriously wondered if it was a joke. The Nano Banana team should be pissed Google PR is distributing such a terrible photo. The poses are stilted, expressions f…
I have seen such detailed and tidy whiteboard diagrams, but the catch is that they never occur in active discussion . It doesn't make room for scribbling, and stopping a discussion for 5-10 minutes to draw slowly and nicely doesn't make sense...