(I've never encountered destination dispatch myself, so I'm not really sure how it works in practice)

Of course, user error is also a factor, so this isn't accounting for people not understanding how to use it and making things worse that way.

Instead of looking at a single snapshot of a person, you're now looking at trends over time. We probably don't have the analytical tools to effectively evaluate medical imaging with that time dimension at such scale (because I assume it would be rare for someone to get MRIs so frequently), but maybe with more data and study, we'll be able to more definitively distinguish benign quirks from real concerns.

Rather than a human comparing a couple of scans five years apart, you're talking about computationally identifying outlying regions in the data (a motion picture of the entire body) that are trending towards areas of concern.

I'm sorry your experience has been so terrible or that you thought you were buying an open-ecosystem printer. I never got that impression, so I never expected it.

And in 2026, I wouldn't trust access controls on their own even if Bambu Lab did keep them enabled in this situation (who's to say they don't include a back door of their own?). I prefer security at the network level, enforcing access controls before any untrusted hosts can even see a machine that I want to protect on the network.

> completely exposes your printer by removing existing access controls

If these printers are in LAN-only mode and you want to point 3rd-party software at them, don't you kind of expect the existing access controls (which are probably at least in part tied to cloud services) to be removed? Behind a LAN with developer mode on, you're generally going to (1) not be exposed to the internet anyway, and (2) probably know what you're doing and would be implementing access controls yourself anyway.

If you want a completely open (hardware and software) 3D printer, don't get a Bambu Lab machine I guess? A big part of the value of their printers is that they've managed to make everything so seamless. Some of that relies on a somewhat closed ecosystem. They're the Apple of 3D printers, but everyone keeps expecting them to be the Linux, just because their slicer (or parts of it anyway) is open-source. If openness is more important to you than those conveniences, go with a different brand. It's a good thing we have choices as consumers :)

Maybe I'm mistaken, but I don't think that's what is happening. They aren't doing anything to block OrcaSlicer or any fork from working with the printer using LAN-only mode. It's only if you want to use Bambu Lab's servers for essentially a remote-access solution (which, by the way, kind of defeats the privacy-oriented purpose of running some of these forks) that they're saying you should use their own software.

Thought experiment: the core of macOS (Darwin) is open source. Does that mean everyone running Darwin or a fork of it should be able to use iCloud services for free?

All this outrage essentially sounds like "since Bambu Lab's slicer is open-source, the open-source community should be able to point any slicer at Bambu Lab's servers to get free remote monitoring services". And I don't think that's right.

Their cloud infrastructure obviously has real costs associate with running it, and I don't understand why any software other than their own should be entitled to use those resources.

If you buy something and then significantly modify it, you generally tend to void the warranty - and that's not because companies are just greedy; there are real limitations when it comes to a company's ability to support the endless ways a product could be modified.

Publishing something as open-source does not imply that you must operate an optional-but-complementary service at a loss for charity.

So yes, the "fixed" output has errors, but it’s not hallucinating details like an LLM, nor is it trying to produce output that conforms to any linguistic or stylistic heuristics.

The phrase "correcting similar OCR'd PDFs" should have been "correcting similar OCR'd base 64 representations of PDFs".

which uses this Rust zlib stream fixer: https://pastebin.com/iy69HWXC

and gives the best output I've seen it produce: https://imgur.com/itYWblh

This is using the same OCR'd text posted by commenter Joe.

Claude Opus came up with this script:

https://pastebin.com/ntE50PkZ

It produces a somewhat-readable PDF (first page at least) with this text output:

https://pastebin.com/SADsJZHd

(I used the cleaned output at https://pastebin.com/UXRAJdKJ mentioned in a comment by Joe on the blog page)

From what I can tell, any time you use this to check something like the customer's subscription state (or anything else payment-related) - either from the front end or the back end - it's going to perform an API request to Flowglad's servers. If you care about responsiveness, I'm not sure that's a good idea. Of course, you can cache that state if you need to access it frequently, but then it kind of defeats the purpose of this layer.

Stripe integration can be tricky, but if you don't want to store anything locally, you might as well just hit Stripe's APIs without the middleman. For the payment systems I've worked on, having cached state in the database is actually really nice, even if it's a bit more work. Want to do a complicated query on your customers based on payment/subscription state and a bunch of other criteria? It's just a DB query. With this, I think you'll be hoping they expose an API to query what you need and how you need it. Otherwise, you'll be stuck waiting for a thousand API requests to fetch the state of each of your customers.

Bitcoin (and possibly a few others) is one of the few uses of blockchain that actually makes sense. The blockchain serves the currency, and the currency serves the blockchain. The blockchain exists to provide consensus without needing to trust any off-chain entity, but the blockchain relies on computing infrastructure that has real-world costs. The scarcity of Bitcoin (the currency) and arguably-fictitious reward for participation in mining is the incentive for people in the real world to contribute resources required for the blockchain to function.

Any real-world value given to Bitcoin is secondary and only a result of the fact that (1) mining infrastructure has a cost, and (2) people who understand the system have realized that, unlike fiat, stablecoins, or 1000 other crypto products, Bitcoin has no reliance on trusted, off-chain entities who could manipulate it.

You trust your stablecoin's issuer that they hold enough fiat in reserve to match the coin? You might as well trust your bank, but while you're at it, remind them that they don't have to take days to process a transaction - they could process transactions as fast as (actually faster than) a blockchain. But I imagine most banks would point to regulation as a reason for the delays, and they might be right.

So what are stablecoins really trying to do? Circumvent regulation? Implement something the banks just aren't willing to do themselves?

Once it's truly "open", you can't have any sensitive identifiers in there, so you need another protocol/system for correlating opaque identifiers with real-world entities (thus defeating the purpose).

And if financial institutions are involved, they'll want the ability to do what they do now: rewrite history whenever they feel the need (or are compelled by governments). Another strike against using blockchain.

To illustrate the temporal aspect: consider a traditional film projector. Between every frame, we actually see complete darkness for a short time. We could call that darkness "noise", and if we were to linger on that moment, we'd see nothing of the original signal. But since our visual systems tend to temporally average things out to a degree, we barely even notice that flicker (https://en.wikipedia.org/wiki/Flicker_fusion_threshold). I suspect noise and grain are perceived in a similar way, where they become less pronounced compared to the stable parts of the signal/image.

Astrophotographers stack noisy images to obtain images with higher SNR. I think our brains do a bit of that too, and it doesn't mean we're hallucinating detail that isn't there; the recorded noise - over time - returns to the mean, and that mean represents a clearer representation of the actual signal (though not entirely, due to systematic/non-random noise, but that's often less significant).

Denoising algorithms that operate on individual frames don't have that context, so they will lose detail (or will try to compensate by guessing). AV1 doesn't specify a specific algorithm to use, so I suppose in theory, a smart algorithm could use the temporal context to preserve some additional detail.

a) Compressed original with significant artifacts from the codec trying to represent original grain

b) A denoised version with fewer compression artifacts, but looks "smoothed" by the denoising

c) A denoised version with synthesized grain that looks almost as good as the original, though the grain doesn't exactly match

I personally think the FGS needs better grain simulation (to look more realistic), but even in its current state, I think I'd probably go with choice C. I'm all for showing the closest thing to the author's intent. We just need to remember that compression artifacts are not the author's intent.

In an ideal world where we can deliver full, uncompressed video to everyone, then obviously - don't mess with it at all!

That's not to say that all noise and grain is good. It can be unavoidable, due to inferior technology, or a result of poor creative choices. It can even be distracting. But the alternative where everything undergoes denoising (which many of our cameras do by default now) is much worse in my opinion. To my eyes, the smoothing that happens with denoising often looks unrealistic and far more distracting.

That's true, but at a given bitrate (until you get to very high bitrates), the compressed original will usually look worse and less sharp because so many bits are spent trying to encode the original grain. As a result, that original grain tends to get "smeared" over larger areas, making it look muddy. You lose sharpness in areas of the actual scene because it's trying (and often failing) to encode sharp grains.

Film Grain Synthesis makes sense for streaming where bandwidth is limited, but I'll agree that in the examples, the synthesized grain doesn't look very grain-like. And, depending on the amount and method of denoising, it can definitely blur details from the scene.

I don't think anyone is saying HDR isn't really HDR. It obviously does support higher dynamic range, but it's kind of like giving someone directions in a language they don't speak. Technically, the spec does what it claims to do, but it adds unnecessary requirements on the display side that undermine a lot of the benefit. As a result, you have filmmakers forced to pick an arbitrary level of "scene white", which in turn means that displays aren't using their full range of brightness as effectively as they could. It also means that most TVs and projectors have to implement their own version of "tone mapping", some of which are pretty terrible to be honest. Not just terrible for HDR, but worse than SDR.