It's not about the specific "BioPykrete" example, it's the technique that's interesting: using proteins to bridge dissimilar materials in composites. It's using them in a way that's sort of like how an emulsifier lets you bridge lipophilic and hydrophilic compounds

Think, say, plastic-ceramic or plastic-metal composites. We can do these today (say, Colorfabb Bronzefill 3d printing filament), but the addition of ceramic or metallic particles makes the material properties generally worse, not better. The plastic just does not bond well to the particles; you have to significantly limit the percentage of metal or ceramic in your mix, and it makes them much harder to work. But what if they *did* bound well? You could easily produce materials with significantly boosted strength, abrasion resistance, etc, but with the low-temperature workability of plastics (note: they'd probably have to be thermoset, not thermoplastic, or low-temperature thermoplastics; proteins have heat survivability limits)

And why stop at metals and ceramics? You could literally just use "dust", just ordinary mineral dusts (clays, silt, etc) as a bulk filler in plastics, yet instead of ending up with a weaker product than working with pure plastic, you'd end up with a stronger one.

Maybe you don't even need a plastic. Maybe you can do what they're doing and bridge cellulose to an inorganic material? Then you're *really* operating on waste. Ice has the advantage of a low melting point in this situation, letting you use that component as a fluid - but cellulose can be dissolved in a number of substances, so perhaps you mix a cellulose-protein slurry with metal or mineral powders and then vaporize/recover the solvent?

Or even forgetting "novel" products, what about conventional composites? If you can bridge high-tensile fibres (such as carbon fibre) better to the polymer matrix that they're in, then you can help eliminate one of the main failure mechanisms of said composites, as well as making the behavior far more predictable. Because like metals (and unlike ceramics), a protein-bridged compound shouldn't be brittle; breaking one bond shouldn't introduce a discontinuity (like a ceramic), it should just reconnect after breakage (like a metal). Such composites should have ductility.

I don't know how widely applicable this will be, but technology that helps bridge dissimilar compounds is nothing to scoff at. And today we have tools like AlphaFold to assist with the design

As for the caveats:

* The concept of coupling agents is also not new, we already use various coupling agents to bond plastic to metal particles in metal-plastic composites and the like - they're just not great at their jobs.

* The aforementioned temperature limits

* Potential production challenges (though industrial enzymes are as cheap as like $15-50/kg, so seems viable?)

* Other coupling agents may offer better advantages; it's not a static field.

I haven't looked up the history, but I would imagine that the "XL" is for the fact that it can handle images up to 1B x 1B pixels (1 exapixel).

Both lossy and lossless, and so much more.

It's this.

And on the compression side, there's a lot of really cool stuff that lets it happen. For example, it dynamically resizes the blocks from 2x2 to 256x256, and they don't even have to be square. It may apply DCT in one, AFAS in another, etc - whatever is most efficient. It uses edge preserving filters to keep the edges of features clean. It can draw in splines and clone regions from one part of an image to another. Where it has to throw away high frequency noise (film grain, noisy textures, etc), it statistically samples the properties of the noise and saves that, and then regenerates equivalent noise. In "busy" areas, like say tree bark or whatnot (where the human eye isn't good at discerning changes), it throws away more precision there, and instead allocates it to details located in fragile flat areas, such as skin and shadows, that the eye is attracted to. It works in default in XYB colour space, based on the actual interactions of the cones in the eye, so it can aggressively quantize things which the brain cannot detect. And in the choice between fast but not-great Huffman coding vs. better but slow and patent-encumbered arithmetic coding, they instead use rANS, which is nearly as fast as Huffman but as efficient as arithmetic coding, and faces no patent challenges. Which is also why you can take a legacy JPEG and rapidly losslessly reincode as JPEG-XL and get a file that's ~20% smaller - you're swapping Huffman for rANS.

(That's the lossy mode - there's also a dedicated lossless mode)

Ahem

Don't we all! Hard drives, RAM, *and* GPUs, I'm in the market for it all.

I also want to buy silver-tin alloy for casting, and hey, what do you know, silver and tin are also both at astronomical prices due to in no small part the AI boom.

At one point you have to just stop waiting. Prices could start falling tomorrow, but then again, that could have been said at any point for the past several years.

They don't have the revenue to survive much longer,

They were profitable in Q2. You can't extrapolate that endlessly, but they're not a cash incinerator anymore. And they have $15-20B on-hand pre-IPO. They're fine.

Anthropic is more or less breakeven *despite* being engaged in a massive 10x YoY scaleup for approaching 4 years running. Companies undergoing even "normal" scaleup rates are almost never profitable, let alone 10x/yr. Any slowdown in scaleup, or any shift in market pressures from intense jockeying for position to starting to pay back investors, and this drives them into deep profitability

The threat to Anthropic has nothing to do with whether its current business is sustainable or deeply profitable at its core. It is. Its threat is one I've been highlighting for years and now we're really starting to see: once something is "good enough", people start to question why they should be paying more for better. We now have the rise of a bunch of crazy cheap, yet quite coding-competent models like GLM 5.3 Flash, Qwen 3 Flash, MiMo 2.6 Pro, MiMo 2.6 Flash, Muse Spark 1.3 Contributor, etc. The latter two are almost too cheap to meter. Now, you still need an orchestrator, for planning, supervision, management, etc; it can either be a human or a higher-end model. But you don't need to pay for, say, Opus to get good coding done these days. Anthropic, like OpenAI, is built on charging a sizable premium over inference costs because they have the best and people will pay for it. And sure, in non-verifiable fields (say, medicine), maybe people keep paying for the best, whatever it may happen to be. But the more of the "bulk" coding and the like moves off these premium models and into dirt-cheap models, that seems to represent a real threat to their business model.

Anthropic's response thusfar seems to be "join them". Claude 5.5 Haiku is a good model "flash" model, and they've set quite affordable pricing for it, definitely fitting into the above category. But that doesn't really solve the problem. Their best hope is that Jevon's Paradox kicks up: that now that big projects are so cheap to implement, people keep taking on even bigger projects, scaling their income from cheap flash models like Haiku, orchestrators like Sonnet and Opus, and non-verifiable tasks where people will generally always want to pay for the best. But will that compensate? Hard to tell. This is the threat to Anthropic.

Huh, does stuff like this work in vim? /prompt write me an implementation of the Navier-Stokes equations for a zero-turbulence boundary condition in python, with a sleek modern GUI and test geometry

Unrelated aside, but back in the day when there was just vi, there was always a debate as to whether it's pronounced "vee" or "vie". Eventually my friends and I agreed on a way to settle the debate: we'd have a text-to-speech program read it out for us, and treat whatever it said as canon.

It said: "six".

So is vim, but nobody ever claimed that it is worth $2e12.

I think so. I was but a tyke in that era, but I clearly remember my uncle bitterly complaining at the time: "We can put a man on the moon, but we still can't measure the nutrient levels in vegetables with sufficient accuracy!"

Life is so much better now.

And those corrections require atomic clocks.

You think LLMs would write "Slashdot doesn't have table support, so it's hard to do side-by-side well, but:"? You think LLMs like writing sentences that end in conjunctions that express incomplete thoughts? Do you think LLMs write "high frequences", "naively pairs", call H.265 X.265 (I was thinking of what you refer to it as in ffmpeg), imbalanced parens after "lacks motion vectors",etc?

Don't get me wrong, I am a LLM user, I absolutely do use it sometimes for search, fact checking things I'm writing, spelling/grammar checks (clearly not that time, lol), etc. But I write my own posts.

Slashdot doesn't have table support, so it's hard to do side-by-side well, but:

JPEG XL advantages:

Licensing:

JPEG XL: Fully royalty-free (Open source / Apache 2.0)
HEIC: Proprietary patent minefield (MPEG LA, Advance, Velos; royalties apply)

Legacy JPEG Migration:

JPEG XL: Lossless, reversible bitstream transcoding (~20% smaller); fast enough for real-time web servers
HEIC: Lossy re-encode only (generational quality loss; cannot reconstruct original JPEG)

Fine Detail & Textures

JPEG XL: Retains sharp text, fine lines, subtle textures, and film grain
HEIC: Video-derived coding (HEVC / X.265). Tends to smooth out high frequences and smudge grain.

Software Encoding Speed

JPEG XL: Extremely fast; highly parallelized SIMD architecture
HEIC: Exceptionally slow and computationally expensive in software

Software Decoding Speed

JPEG XL: Fast, lightweight multi-threaded CPU decoding
HEIC: Heavy CPU overhead (without using hardware acceleration)

Progressive Rendering:

JPEG XL: True progressive decode; smart saliency algorithm to focus bandwidth on critical details first.
HEIC: None; full file must be received and decoded before display

Lossless Compression
JPEG XL: Dedicated modular mode; vastly outperforms PNG and WebP
HEIC: Ill-suited; you basically have to try to do lossless compression with an inherently-lossy format

Bit Depth & HDR

JPEG XL: Native HDR; up to 32-bit floating point per channel
HEIC: Typically capped at 10-bit or 12-bit integer

Max Dimensions & Scaling

JPEG XL: Up to 1B x 1B; efficient viewport/crop loading without full decoding
HEIC: v5.2, 4096x2160; v6.2: 8192x4320; a tiling hack allows up to 16384 x 16384

Channels & Color Spaces:

JPEG XL: Arbitrary color spaces (hyperspectral); unlimited extra channels (alpha, depth, thermal, masks, CMYK, etc)
HEIC: Rigid container; limited auxiliary channels and standard video color spaces

HEIC advantages:

Rollout / acceleration:

JPEG XL: no dedicated hardware acceleration (thankfully, it's not as important because it's so much more efficient). Software adoption still rolling out.
HEIC: Hardware silicon (ASICs). Default capture format on modern iOS/Android; native capture in Sony, Canon, and Nikon cameras

Video:

JPEG XL: Supports animations (GIF/APNG replacement), with some optimizations** (it's not just a series of stills), but lacks the full set of optimizations that a proper video codec has.
HEIC: Container naively pairs full HEVC video tracks and audio with video.

** - JPEG XL can store up to 4 reference frames in a buffer, with multiple blending modes from the references (add, replace, multiply, etc); has subframe bounding boxes ("dirty rectangles") for when only part of a frame changes; invisible frames; modular deltas (differences between frames); etc. However, it lacks motion vectors (e.g. detecting a feature drifting across a scene and simply having to encode "move it" (followed by any needed deltas). So it's great for "GIFs", but if you wanted to encode a full movie, it'd be significantly larger than e.g. HEVC.

Look, I use HEIC, but JPEG-XL is just better.

* Royalty-free
* Lossless transcoding of legacy JPEGs to immediately reduce their sizes by ~20% (fast enough that you can have webservers do it in realtime)
* Better fine detail / high frequency data representation for the same bitrate. HEIC was designed for video and simply is not as good at stills.
* Faster decoding
* MUCH faster compression
* True progressive decoding - and not old-school blocky progressive decoding, but using a smart algorithm that restores coarse detail (particularly focusing on parts of the image that the eyes immediately focus on) first, then progressively adding in finer detail that the eyes take more time to notice later.
* Vastly better lossless compression
* Better colour depth and native HDR (up to 32 bit per channel)
* Up to 1B x 1B pixel images (again, useful for scientific and engineering applications), with efficient loading (don't have to load and decode the whole 1B x 1B image at full resolution to view it)
* Arbitrary colour spaces - you can even use it for scientific hyperspectral imaging. You can include e.g. alpha, depth maps, thermal data, selection masks, etc etc.

It's just a better format for stills. It's annoying that it's taken this long to get support to take off (because it takes ages for most people to update their browsers), but I'm really glad that it's starting to.