Thanks for the context. That makes sense.
3,075 karma · joined November 3, 2013
(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:
It produces a somewhat-readable PDF (first page at least) with this text output:
(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.
It's true that, given the options available today, the two usually go hand-in-hand (wider color gamut and HDR). However, one of the arguments Steve makes is that a majority of content (and a vast majority of the pixels in that content) doesn't use colors outside Rec. 1886's gamut. Illuminated objects (natural or manmade) almost never go outside that, so you're usually only talking about a few pixels from intensely-saturated light sources in the shot (like LEDs) that might use those colors. Even then, not a lot of filmmakers feel the need to go there, so their movies will look the same in narrow and wide gamuts.
I don't think the video is arguing against wider gamut or even higher dynamic range as options; modern displays are more capable than older ones, so we need tools to allow content creators to use that capability if they desire. The problem is that all of these things (color space, bit depth, transfer function, absolute luminance values, etc) have been lumped together under one label, "HDR", and some of the implementation details are actually worse than what we had with SDR. If you skip to the "Checklist Recap" portion of the video, you'll see that there are actually quite a few downsides to HDR in its current form, but since most of the standards are tightly coupled, we're kind of stuck unless we move to something better.
I also personally choose HDR versions when watching movies, but that's because UHD content is usually also HDR. What I really want is the higher resolution. I've never felt like I'd be missing out if it didn't have HDR because I've compared the two a lot - they're really mostly the same for the movies I watch with a properly calibrated screen. To each their own :)
- It was clearly a mistake to define HDR transfer functions using absolute luminance values. That mistake has created a cascade of additional problems
- HDR is not what it was marketed to be: it's not superior in many of the ways people think it is, and in some ways (like efficiency) it's actually worse than SDR
- The fundamental problems with HDR formats have resulted in more problems: proprietary formats like Dolby Vision attempting to patch over some of the issues (while being more closed and expensive, yet failing to fully solve the problem), consumer devices that are forced to render things worse than they might be in SDR due to the fact that it's literally impossible to implement the spec 100% (they have to make assumptions that can be very wrong), endless issues with format conversions leading to inaccurate color representation and/or color banding, and lower quality streaming at given bit rates due to HDR's reliance on higher bit depths to achieve the same tonal gradation as SDR
- Not only is this a problem for content delivery, but it's also challenging in the content creation phase as filmmakers and studios sometimes misunderstand the technology, changing their process for HDR in a way that makes the situation worse
Being somewhat of a film nerd myself and dealing with a lot of this first-hand, I completely agree with the overall sentiment and really hope it can get sorted out in the future with a more pragmatic solution that gives filmmakers the freedom to use modern displays more effectively, while not pretending that they should have control over things like the absolute brightness of a person's TV (when they have no idea what environment it might be in).
I was a bit surprised, however, that there's not currently a good way to reference storage objects from my postgres tables. I found that the recommended way is to store the object's path (as a string) in the database. While that works, it isn't optimal as I'd like to enforce consistency between the object and the table referencing it.
I've tried referencing the id of the corresponding row in the storage.objects table, but (1) apparently the schema supabase uses to manage storage.objects may change, and (2) it still requires separate (non-atomic) operations - or additional triggers - for keeping things in sync. Using buckets (corresponding to tables) and folders with ids is another way to work around it, but still feels suboptimal.
Not 100% sure what the best solution would look like, but ideally the supabase client could emulate storage operations for objects "attached" to a given table record, and supabase (the backend piece) could implement them as atomic operations (e.g., uploading the actual storage asset, storing the necessary metadata, and updating my table row to reference the newly-created storage object; exposing a helper function to return the URLs for any storage objects attached to a record; etc).
Anyway, just a suggestion. Keep up the great work!
If so, that could make for either a very unfortunate surprise (i.e. a spacecraft passing through that point suddenly melting to a crisp) or an interesting source of energy if it could be harnessed.
Specifically, the out-of-focus shadow details look like a smoothing or denoising algorithm has been applied. Maybe it's just something about the optics Apple is using (e.g. different lenses can have distinct characteristics in bokeh, softening, color, distortion, etc) vs other dedicated cameras, but it's something I see in almost all photos coming from an iPhone.
[1] https://kirkville.com/apples-new-proraw-photo-format-is-neit...
Essentially GitHub's webhook is configured to hit the Lambda function, which authenticates the request and adds the data to an SQS queue. The internal relay service watches that queue and passes requests to the private Jenkins server.
The architecture is similar to this[1] project, but since the public-facing piece runs on Lambda, it costs almost nothing to run.
Traffic also wasn't a problem - in one case they pulled my program membership only after I had generated hundreds of dollars in referred sales (of course they didn't pay the commission). Needless to say, it has left a bad taste in my mouth ever since. In my opinion, if they have such a narrow interpretation of what "original" or "creative" means (applying only to blog-style content, or who knows what), then I frankly don't care to do anything more with their affiliate program or drive sales to them.