No. There is no other engineering field where you can practically mathematically prove, in the general case, that your design and implementation are perfect. Electronics engineering is similar to software in that it is sometimes technically possible to do but, except in special cases, it is not practical to do so. Why should software engineering be different?
Designers of critical systems like bridges, tunnels and airplanes apply knowledge gained through scientific experiment and mistakes made in the past, add in a healthy safety margin, and then test to make sure they've gotten it right. Just like software engineers do. Sometimes bridges, tunnels and airplanes fail. In that case engineers try to learn from their mistakes. Just like they do with software.
Toyota has had a handful of incidents out of the millions of cars that they make. The incident rate is just as high for mechanical issues in cars, airplanes, bridges, space shuttles, whatever you'd like to name.
ABS isn't really drive by wire. The electronics can modify the input from the driver but there is still a mechanical (or hydraulic, rather) linkage between the pedal and the brake. It seems it's the lack of a non-electronic connection that really bothers people, although there are the die hards who think ABS is the devil as well.
I've never drive a drive-by-wire car (but I've flown in lots of fly-by-wire planes) but the only problem I've ever had with my brakes was when a hydraulic line burst.
Yes, that statement is wrong. They forgot the world "practical."
Yes, it is generally possible to absolutely verify software. If you'd ever had to do it, you'd know that it's absolute hell to do for even the simplest, almost trivial programs. It is done, sometimes, for really critical (and small) programs.
I didn't mean to imply that good journalists have to go to journalism school. All of the pioneering photojournalists you mentioned were trained - McCullen worked as a photographer's assistant, for example, and Capa worked as (or at being) both a photographer and writer before he did the work he's recognized for. You can be self trained, or trained through apprenticeship, or whatever, but I disagree with the idea that people dedicated to their art can be replaced by a mass of random dabblers.
Professionalism actually embodies more than just making a living doing something (although I think that being able to dedicate yourself full time is likely also very important). Perhaps the most relevant aspect of professionalism is adhering to a code of ethics.
Certainly someone who is a blogger today might well be a star journalist of tomorrow, but in most cases I think that will require that he or she be a) dedicated to journalism and b) be able to make enough money as a journalist to dedicate a good deal of time to it. Under those circumstances a "blog" really becomes a self-published column. As for the self-published part, it would really be helpful if these "bloggers" you can trust were collected together into some sort of organization, wouldn't it?
I notice that the bloggers I follow all either write full time or write about their professions. They are both trained (sometimes self-trained in journalism) and professional.
Journalism, newspapers and magazines are in for some lean years. Then we'll all realize that no, a million random bloggers on the Internet are not a replacement for a trained, professional journalist/writer.
From the description it sounds like you need long term storage and infrequent (if ever) access. Optical is obviously bad for that. Hard drives are too. Storing hard drives for long periods of time without spinning them up can result in the platters seizing. Tape really is your only reasonable option. You can pile it above some poor post doc's desk like they do at my lab or you can store it properly, your choice, but either way it's better than the other options.
I'll try to post some Python/C code on the page I liked to in the GP. It might take a while - I'll have to modify the C bindings so they'll work on non-macs.
Not that I know of. A quick google (on my iPhone, so I could easily have missed something) didn't turn anything up. I've got a simple version written in Python and C. I'm working on something more sophisticated that will be usable as a noise filter as well.
If you're interested keep an eye on that page I posted and I'll try to put up some usable code as soon as I get around to it. Note that post docs sometimes take a while to get around to side projects though.
What you really need is a better (bigger, heavier) lens. In most cameras post-megapixel race the maximum angular resolution is usually limited by the lens, not the sensor resolution. CS and/or sensor upgrades can't correct for that because the information doesn't actually make it through the glass to be recorded.
If you just want to make those pictures look better, you can probably get some good results with some of Photoshop's edge enhancing and sharpening filters. CS also makes a wicked noise filter (noise is not sparse and so is suppressed by CS) so it might be able to help you there.
Thanks. I think that was back with an older version of IE and it would mess up the floating divs a bit. Nothing horrible. Good to hear they've fixed that.
Yes, that's the idea. D is the original, E is the undersampled and F is the CS reconstructed image. F is visually identical to D, meaning the reconstruction worked very well.
Incidentally, that's not really low resolution. A typical MR image is about 256x256. I think I made that image 1024 pixels across and there are three images across with a bit of space between, so the individual images are pretty close to actual size.
You're missing the key feature: the image is sparse. That means it contains redundant information. What CS does is sample enough to acquire all the necessary information, but avoids sampling some of the redundant bits, so there's no need to make up information.
The description of the algorithm in the article is terrible - don't base your opinion on it. Check out the rest of the comments - some people (including me) have posted better descriptions.
When you compress something you represent it in such a way that you can reconstruct the original based on less data. Effectively you're "discovering" data that wasn't sampled (stored) in the first place. Except, with lossless compression at least, you're not really doing this. The compression process discards only redundant data.
Compressed sensing works in much the same way except that you effectively treat your acquisition and display process as you would your reading-from-disk-and-decompressing process. Instead of sampling everything you skip sampling points that are likely to be redundant.
If you go too far then yes, you get image degradation. If you keep things reasonable (and reasonable depends to some extent on what kind of image you're acquiring), you can get a perfect reconstruction, just like you do when you reconstruct a gzip compressed image.
Regarding your example: it's easier if you consider the process as it actually occurs in MR. The image is actually acquired in the Fourier domain so every point you acquire has information about every pixel in the image. So you've got a dark spot indicating a tumor. Yes, that information has to be in your acquired data but that doesn't mean you're going to be able to actually distinguish that tumor when you reconstruct the image. Noise and artifacts may obscure it.
Compressed sensing effectively tells you what you need to sample in order to retain the information about that tumor in your reduced data set (with high likelihood), and how to reconstruct the data so that the tumor is actually evident in the image (mostly be reducing artifacts).
Here's an example (sorry, I can't post an image with a tumor due to privacy).
Image C is the original, where features are clearly visible. D is undersampled in a way you might do to make an MR scan faster. What looks like noise in the image isn't really noise, it's decoherent aliasing artifacts due to the undersampling. The information to reconstruct the image is still there, but the naive reconstruction technique can't reveal it. CS reconstruction (E) reveals it.
I might have misunderstood you but I don't think you can properly compare what you're talking about to changing the aperture of a camera and if you could it would be decreasing the aperture (more things in focus), not increasing it. I think you're also talking about other techniques, such as acquiring the whole lightfield, that might well be made more practical by CS but aren't really the same thing.
The key is that the image must be sparse (and almost all useful images are sparse). By definition, a sparse image contains less information than the pixels that make it up can store. Thus, it is compressible. So you're not creating data where it doesn't exist, you're just not sampling and storing the redundant parts.
You've missed the point, which is not surprising considering the way the article is written.
Compressed sensing exploits the observation that almost every useful image is actually sparse - it contains much less information than the pixels that make it up can store. Furthermore, if you undersample that image in the right way, the original data is recoverable.
For a reasonable level of undersampling (and a sparse image) CS will give you a perfect reconstruction, just like gzip, for example. The important difference with CS is that you don't need to acquire all the data in order to figure out which parts are redundant (as with gzip) - you can just acquire the important bits to start with.
The L1 norm is generally computed on the wavelet transform of the image, not the image itself. Total variation is usually minimized in tandem because it tends to produce better reconstructions.
"Image Simulation" likely means that they simulated the acquisition. The recovery of the "after" image from the "before" image is probably as shown, it's just that the "before" image was not acquired from an actual camera. Those results don't look particularly amazing for compressed sensing. See this for example.
Some of the designs for CS cameras basically do just that. You can do CS just as well with images acquired in the image domain though, the intuitive reasoning for why it works just gets a little... less intuitive.
I'm not sure CS is going to quickly catch on in your common camera because it doesn't really solve a pressing problem but it will certainly find lots of applications.
Slashdot Mirror
No. There is no other engineering field where you can practically mathematically prove, in the general case, that your design and implementation are perfect. Electronics engineering is similar to software in that it is sometimes technically possible to do but, except in special cases, it is not practical to do so. Why should software engineering be different?
Designers of critical systems like bridges, tunnels and airplanes apply knowledge gained through scientific experiment and mistakes made in the past, add in a healthy safety margin, and then test to make sure they've gotten it right. Just like software engineers do. Sometimes bridges, tunnels and airplanes fail. In that case engineers try to learn from their mistakes. Just like they do with software.
Toyota has had a handful of incidents out of the millions of cars that they make. The incident rate is just as high for mechanical issues in cars, airplanes, bridges, space shuttles, whatever you'd like to name.
ABS isn't really drive by wire. The electronics can modify the input from the driver but there is still a mechanical (or hydraulic, rather) linkage between the pedal and the brake. It seems it's the lack of a non-electronic connection that really bothers people, although there are the die hards who think ABS is the devil as well.
The car with the burst brake line had ABS.
"'Would you like to avail the Comcast?' I don't even know what the F that means."
Consider yourself lucky.
Avail:
to be of use or advantage : serve
I think The Comcast likes you. Likes you very much.
I've never drive a drive-by-wire car (but I've flown in lots of fly-by-wire planes) but the only problem I've ever had with my brakes was when a hydraulic line burst.
Non-electronic systems fail too.
Yes, that statement is wrong. They forgot the world "practical."
Yes, it is generally possible to absolutely verify software. If you'd ever had to do it, you'd know that it's absolute hell to do for even the simplest, almost trivial programs. It is done, sometimes, for really critical (and small) programs.
I didn't mean to imply that good journalists have to go to journalism school. All of the pioneering photojournalists you mentioned were trained - McCullen worked as a photographer's assistant, for example, and Capa worked as (or at being) both a photographer and writer before he did the work he's recognized for. You can be self trained, or trained through apprenticeship, or whatever, but I disagree with the idea that people dedicated to their art can be replaced by a mass of random dabblers.
Professionalism actually embodies more than just making a living doing something (although I think that being able to dedicate yourself full time is likely also very important). Perhaps the most relevant aspect of professionalism is adhering to a code of ethics.
Certainly someone who is a blogger today might well be a star journalist of tomorrow, but in most cases I think that will require that he or she be a) dedicated to journalism and b) be able to make enough money as a journalist to dedicate a good deal of time to it. Under those circumstances a "blog" really becomes a self-published column. As for the self-published part, it would really be helpful if these "bloggers" you can trust were collected together into some sort of organization, wouldn't it?
I notice that the bloggers I follow all either write full time or write about their professions. They are both trained (sometimes self-trained in journalism) and professional.
"The worst change IMO is going to be journalism."
Journalism, newspapers and magazines are in for some lean years. Then we'll all realize that no, a million random bloggers on the Internet are not a replacement for a trained, professional journalist/writer.
Textbooks. They must have diagrams and a lot of them also require colour.
If you collect data on it, analyze it and write it up you might well be in line for an Ig Nobel prize.
PyObjC has a one liner description of how to convert an Objective-C call into a Python call and vice versa. It's not difficult.
From the description it sounds like you need long term storage and infrequent (if ever) access. Optical is obviously bad for that. Hard drives are too. Storing hard drives for long periods of time without spinning them up can result in the platters seizing. Tape really is your only reasonable option. You can pile it above some poor post doc's desk like they do at my lab or you can store it properly, your choice, but either way it's better than the other options.
I'll try to post some Python/C code on the page I liked to in the GP. It might take a while - I'll have to modify the C bindings so they'll work on non-macs.
Not that I know of. A quick google (on my iPhone, so I could easily have missed something) didn't turn anything up. I've got a simple version written in Python and C. I'm working on something more sophisticated that will be usable as a noise filter as well.
If you're interested keep an eye on that page I posted and I'll try to put up some usable code as soon as I get around to it. Note that post docs sometimes take a while to get around to side projects though.
What you really need is a better (bigger, heavier) lens. In most cameras post-megapixel race the maximum angular resolution is usually limited by the lens, not the sensor resolution. CS and/or sensor upgrades can't correct for that because the information doesn't actually make it through the glass to be recorded.
If you just want to make those pictures look better, you can probably get some good results with some of Photoshop's edge enhancing and sharpening filters. CS also makes a wicked noise filter (noise is not sparse and so is suppressed by CS) so it might be able to help you there.
Thanks. I think that was back with an older version of IE and it would mess up the floating divs a bit. Nothing horrible. Good to hear they've fixed that.
Yes, that's the idea. D is the original, E is the undersampled and F is the CS reconstructed image. F is visually identical to D, meaning the reconstruction worked very well.
Incidentally, that's not really low resolution. A typical MR image is about 256x256. I think I made that image 1024 pixels across and there are three images across with a bit of space between, so the individual images are pretty close to actual size.
You're missing the key feature: the image is sparse. That means it contains redundant information. What CS does is sample enough to acquire all the necessary information, but avoids sampling some of the redundant bits, so there's no need to make up information.
The description of the algorithm in the article is terrible - don't base your opinion on it. Check out the rest of the comments - some people (including me) have posted better descriptions.
When you compress something you represent it in such a way that you can reconstruct the original based on less data. Effectively you're "discovering" data that wasn't sampled (stored) in the first place. Except, with lossless compression at least, you're not really doing this. The compression process discards only redundant data.
Compressed sensing works in much the same way except that you effectively treat your acquisition and display process as you would your reading-from-disk-and-decompressing process. Instead of sampling everything you skip sampling points that are likely to be redundant.
If you go too far then yes, you get image degradation. If you keep things reasonable (and reasonable depends to some extent on what kind of image you're acquiring), you can get a perfect reconstruction, just like you do when you reconstruct a gzip compressed image.
Regarding your example: it's easier if you consider the process as it actually occurs in MR. The image is actually acquired in the Fourier domain so every point you acquire has information about every pixel in the image. So you've got a dark spot indicating a tumor. Yes, that information has to be in your acquired data but that doesn't mean you're going to be able to actually distinguish that tumor when you reconstruct the image. Noise and artifacts may obscure it.
Compressed sensing effectively tells you what you need to sample in order to retain the information about that tumor in your reduced data set (with high likelihood), and how to reconstruct the data so that the tumor is actually evident in the image (mostly be reducing artifacts).
Here's an example (sorry, I can't post an image with a tumor due to privacy).
Image C is the original, where features are clearly visible. D is undersampled in a way you might do to make an MR scan faster. What looks like noise in the image isn't really noise, it's decoherent aliasing artifacts due to the undersampling. The information to reconstruct the image is still there, but the naive reconstruction technique can't reveal it. CS reconstruction (E) reveals it.
I might have misunderstood you but I don't think you can properly compare what you're talking about to changing the aperture of a camera and if you could it would be decreasing the aperture (more things in focus), not increasing it. I think you're also talking about other techniques, such as acquiring the whole lightfield, that might well be made more practical by CS but aren't really the same thing.
The key is that the image must be sparse (and almost all useful images are sparse). By definition, a sparse image contains less information than the pixels that make it up can store. Thus, it is compressible. So you're not creating data where it doesn't exist, you're just not sampling and storing the redundant parts.
It's no more magic than gzip or jpeg compression.
You've missed the point, which is not surprising considering the way the article is written.
Compressed sensing exploits the observation that almost every useful image is actually sparse - it contains much less information than the pixels that make it up can store. Furthermore, if you undersample that image in the right way, the original data is recoverable.
For a reasonable level of undersampling (and a sparse image) CS will give you a perfect reconstruction, just like gzip, for example. The important difference with CS is that you don't need to acquire all the data in order to figure out which parts are redundant (as with gzip) - you can just acquire the important bits to start with.
The L1 norm is generally computed on the wavelet transform of the image, not the image itself. Total variation is usually minimized in tandem because it tends to produce better reconstructions.
"Image Simulation" likely means that they simulated the acquisition. The recovery of the "after" image from the "before" image is probably as shown, it's just that the "before" image was not acquired from an actual camera. Those results don't look particularly amazing for compressed sensing. See this for example.
Some of the designs for CS cameras basically do just that. You can do CS just as well with images acquired in the image domain though, the intuitive reasoning for why it works just gets a little... less intuitive.
I'm not sure CS is going to quickly catch on in your common camera because it doesn't really solve a pressing problem but it will certainly find lots of applications.
Your AC wish is my command.