The “raw” data in so-called “raw” image formats in not unprocessed data from the image sensor. The camera will already have done processing on the data, it’s just not fully processed.
If it was indeed raw data off the sensor, you’d see all kinds of “bad” things such as dead pixels. And camera vendors (obviously?) don’t want you to see that.
> The “raw” data in so-called “raw” image formats in not unprocessed data from the image sensor.
RAW images are completely un-demosaiced and otherwise unprocessed sensor data, dead or stuck pixels and all. It's the job of the RAW converter (whether performed in-camera or post-capture) to hide those in the conversion to a standard color space.
Manufacturers are now blurring the meaning of RAW to be closer to what you imagine. For example, Apple's ProRAW images are demosaiced and heavily processed.
I appreciate that they point out the weaknesses of LibrePCB
> So, if you are looking for an intuitive EDA tool to quickly design a simple PCB, you should give LibrePCB a try. But if you want to design complex PCBs, LibrePCB is probably not (yet) the tool you are looking for.
Well, that’s a common misconception, but far from the truth. If you actually care about performance, you’ll soon find out that performance wrt. database work is all about high-level optimizations: You want to reduce the times you hit the database (both reads and particularly writes).
And once you’re getting into that busyness, Core Data will allow you to create way faster coder in less time. Core Data will get you 10x the performance for 10x less effort.
Hmm...parent is actually correct. What you write is true with very slow databases, particularly when talking to enterprise databases over a network.
"Fortunately", CoreData is so slow that as long as you stay within that universe, your view will never be invalidated.
Outside, however, computers are blazingly fast in general and I/O throughput is also incredibly fast. My laptop can read/write 2 GB/s. That's a lot. Moby Dick is around 1.25 MB. This means that you can write this whale of a book, in its entirety, 800 times per second. That's a lot. But I repeat myself...because it's worth repeating.
CoreData helps you optimize/minimize the size of transactions. Except for a very few cases, that's the wrong thing to optimize, as all our storage has amazing throughput and not-so good per-transaction and seek costs. Getting 1 byte from disk is almost as expensive as getting 1 megabyte, and having a bunch of smaller transactions is almost always a loss compared to one large transaction.
