A very astute framing by Ted Chiang—large language models as a form of lossy compression for text.
When we’re dealing with sequences of words, lossy compression looks smarter than lossless compression.
A lot of uses have been proposed for large language models. Thinking about them as blurry JPEGs offers a way to evaluate what they might or might not be well suited for.
There’s a new image format on the browser block and it’s very performant indeed. Jake has all the details you didn’t ask for.
This is good to know! Because of a bug in Google App Engine, Brid.gy won’t work for sites using Brotli compression on HTML.
A deep, deep, deep dive into the JPEG format. Best of all, it’s got interactive explanations you can tinker with, a la Nicky Case or Bret Victor.
I’ve been playing around with the newly-released Squoosh, the spiritual successor to Jake’s SVGOMG. You can drag images into the browser window, and eyeball the changes that any optimisations might make.
On a project that Cassie is working on, it worked really well for optimising some JPEGs. But there were a few images that would require a bit more fine-grained control of the optimisations. Specifically, pictures with human faces in them.
I’ve written about this before. If there’s a human face in image, I open that image in a graphics editing tool like Photoshop, select everything but the face, and add a bit of blur. Because humans are hard-wired to focus on faces, we’ll notice any jaggy artifacts on a face, but we’re far less likely to notice jagginess in background imagery: walls, materials, clothing, etc.
On the face of it (hah!), a browser-based tool like Squoosh wouldn’t be able to optimise for faces, but then Cassie pointed out something really interesting…
When we were both at FFConf on Friday, there was a great talk by Eleanor Haproff on machine learning with JavaScript. It turns out there are plenty of smart toolkits out there, and one of them is facial recognition. So I wonder if it’s possible to build an in-browser tool with this workflow:
Maybe the selecting/blurring part would need canvas? I don’t know.
Anyway, I thought this was a brilliant bit of synthesis from Cassie, and now I’ve got two questions:
A handy in-browser image compression tool. Drag, drop, tweak, and export.
Handy web-based tools—compress HTML, CSS, and JavaScript, and convert files from one format to another.
Following on from Amber’s introduction, here’s a really in-depth look at image formats, compression and optimisation techniques from Addy.
This is a really nicely put together little web book released under a Creative Commons licence.
Google have released this encoder for JPEGs which promises 20-30% smaller file sizes without any perceptible loss of quality.
The history of the GIF—a tale of licensing, compression, and standards.
Some good thinking from Jason here. In a roundabout way, he’s saying that when it comes to responsive images—as with just about every other aspect of web development—the answer is …it depends.
You’ve probably seen this already, but it’s really worth bearing in mind: when you’re scaling up JPGs for retina display you can safely reduce the image quality by quite a lot—to the point of getting the exact same file size as a higher quality image that’s half the size.
This looks like a really handy tool for reducing the file size of JPEGs without any perceptible loss of quality (in much the same way that ImageOptim works for PNGs)—available as a Mac app or an installable web service.
An in-depth analysis (graphs! data!) of how popular sites are using—or not using—compression.