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.

The need for them came from relativity, but the atomic clocks needed to be able to handle such fine corrections are based on the hyperfine transition of 133Cs. You're not getting very far on atomic clocks without particle physics

Okay Felicia.

Sounds like Newton. Long tradition, I guess

"Okay, nuclear power. Yeah. Yeah, they did give us that. That's true. "

"And industrial-scale superconducting magnets!"

"Don't forget GPS satellite relativistic corrections!"

"And radioisotope therapy!"

"Electron beam therapy?"

"World Wide Web, wasn't that created by particle physicists?"

"Yeah, they did do that."

"Capacitative touchscreens too, you know."

"All right, all right, FAIR ENOUGH! But APART from computers, telecommunications, nuclear power, PET scans, MRIs, satellite communications, superconductors, radioisotope therapy, electron beam therapy, heat-shrink tubing, cargo and baggage screening, smoke detectors, muon tomography, capacitative touchscreens, and the World Wide Web, WHAT HAS PARTICLE PHYSICS EVER DONE FOR US?!"

"Synchrotron light sources for drug discovery?"

"Oh, drug discovery?! GROW UP!"

Yeah, what has a better understanding of particle physics ever done for US, huh??? ... ...

_ ...........

if this were true it would not be possible for the system to read the watermark.

You confuse "invisible to humans" with "invisible to statistical analysis". Humans can't, for example, see the difference between metameric colours. Statistical analysis can. Humans can't see minor drift at scales where Brownian motion dominates. Statistical analysis can. Humans can't see the difference between background disease rates and new rising threats. Statistical analysis can. On and on. Statistical analysis is a far more powerful tool than human perceptual abilities.

this is also a lie. Identical thoughts must be expressed identically, otherwise they are, in fact, *different* thoughts.

I literally gave an example above. If you saw "picked a mango", "selected and picked a mango", "from within the tree, picked a mango", you would never think there was anything going on in the choice, and it isn't going to change the story one iota.

Pretty sure whatever he died from came from bats. Or hamsters

1. 'She', not 'he', AIUI. I can assure you from personal experience that anatomically Russians are indistinguishable in all important respects from other humans.
2. Or more likely marnosets. The commonest vector for plague in this region is the mamoset. I'm not even sure hamsters are found within several thousands km of this area.
3. The disease has a long history in this area. A recent article : "Lethal plague outbreaks in Lake Baikal hunter-gatherers 5,500 years ago" https://doi.org/10.1038/s41586... Nature Vol654 697, 18 June 2026
     "Here we describe early plague strains that are associated with two phases of outbreaks among mid-Holocene hunter-gatherers near Lake Baikal in southeast Siberia, beginning from about 5,500 years ago. These outbreaks occur across four hunter-gatherer cemeteries, with a 39% detection rate for plague infection. By reconstructing kinship pedigrees, we show that small familial groups were affected, consistent with human-to-human spread of disease, and that the first outbreak occurred within a single generation. The infections appear to have resulted in acute mortality, especially among children (aged 8 to 11 years)."

We're all the descendents of the people who for whatever genetic reason survived the plagues in the past and thats why plaque hasn't reoccured as an epidemic since the middle ages.

Except - that was our (mostly) ancestors acquiring a degree of immunity to a strain of the bacterium circulating 250 and more years ago.

It's fairly unlikely that current wild-type strains are the same strain.

Bacteria do evolve in the wild, you know. (Everything evolves in the wild.)

("It actually makes RAM needs worse" -> "MoEs actually make RAM needs worse")

It actually makes RAM needs worse than a dense model, for a given quality.

That said, inference techniques like FreeToken are improving MoE swapping performance, so it's not as bad as it once was. Honestly, I would not be at all surprised if we start doing training in a swap-aware manner, where expert cache misses count as loss and models can queue experts to start loading before they're needed. Could even train in two tiers of loading - RAM and disk. Wouldn't that be great? Could run multi-terabyte models on consumer hardware. Training would tend to tend to concentrate key logic and reasoning on small number of very active experts, mixed reasoning/knowledge on less common experts that are usually kept in RAM, and rarer knowledge on experts that usually remain on-disk until needed.

There are well known, reputable abliterators on HuggingFace.

Also, censorship usually (not always) is something you care about for chats, not agentic work.

A .safetensors or .gguf model cannot run code unless you let it. No agentic framework = all it can do is write text. It can't hurt you directly. At worst, it can only lie to you.