Great, this will work wonders for my zero-cost zero-thickness self-intersecting perfectly rigid solar panels. I just hope my spherical vacuum-chickens don't try to nest in it.
I recently upgraded to the clear spherical vacuum chickens, so I no longer have this problem. I highly recommend them.
No. This is a hill-climbing style random walk. Newton's method is something much more special-purpose (and frequently vastly superior, in the sorts of problems it does well).
...and with it shall go the supposed evidence. The paltry statistic of 244 gunshots in a two month period vs. 177 in another does not indicate anything about supposed trends in gun crime. Furthermore, yearly gun crime is what is of importance, not a few weeks.
A decent starting assumption is that things like gun shots in a given time period follow a Poisson distribution. The difference in gunshots between the periods (244 - 177 = 67) would then have variance of 421 (= 244+177), or a standard deviation of 20.5. That puts the difference at 3.3 standard deviations, which is highly significant. In other words, the second period really did have a lower gunshot rate, it wasn't just noise.
Of course, that doesn't address causality: there could be some other factor that caused the drop. Or, perhaps the choice of 2-month period was not arbitrary; if it was chosen to make the system look good, the significance probably goes away. And, as you suggest, yearly stats are more meaningful.
What about people that don't know they need to lock their doors when they leave the car, or change the oil on a regular basis?
If they're like a normal person, they learn from their mistakes and they don't do the same thing again.
Oddly, computers seem to be exempt from that. The same people get viruses, trojans, malware, etc, and keep downloading crap and failing to install updates, and it keeps happening. Most drivers seem to learn to change the oil after destroying an engine, but somehow computer users are different. Clearly there's plenty wrong with the software in the first place, but there's also something very odd about users who experience these problems and then both continue using the same problematic software and failing to learn from their mistakes.
You can build circuits that detect faults while operating. They're more complex than their normal counterparts, but the transistor count is less than 2x. On-line error detection is a common name.
Of course, such circuits get really expensive if you don't have a large market for them. But cars represent a fairly large market, so if it was the best approach they could probably use them. Of course, that assumes there's any market or regulatory pressure to use any sort of error detection at all.
That's why the author proposes the use of an external hardware verifier, whose purpose mostly seems to be verifying that it was fast enough that the malware didn't have time to write to secondary storage.
Detecting a malware detector is just as hard as detecting malware. In general, detecting software of a specific type is halting-equivalent. In practice, the goal is to take shortcuts so that your adversary has a halting-equivalent problem and you don't. At present, the malware authors are winning. If we could force them to detect the malware detectors, that would be a huge advance.
My skepticism about this is the obvious one: what if the malware just lets itself get swapped out, and relies on stealth to survive the process?
How about "We are aware of the issue and are investigating how it happened. We're sorry we don't have more to tell you, but we don't yet know. We'll update when we can say more." You can both be honest and not piss off the lawyers. You don't have to lie about it.
Newegg is clearly lying: these aren't demo units. I'm sure they're well-intentioned, and I'm sure they'll deal with their customers fairly. But I'd be happier with them if they told the truth while they were at it. And if they don't know (or can't say) what actually happened, then apologize and explain that.
My biggest search feature request: the ability to block a domain from all future searches I see. If Google never gave me another hit from some of those atrocious sites that just re-link things like paper abstracts and throw some ads around them, my search experience would improve.
For every used game sold, the game editor gets ZERO.
Really? What do you think the person selling their game used is going to go spend that money on? More video games, would be my guess.
I'm certain you're correct, but it's rather remarkably short-sighted on the part of publishers to think every used sale represents a potential new game sale lost.
My personal hypothesis is that either you can't change history, only fulfill it because it has already happened, or you end up in a different time line. Yay! now we have a testable hypothesis and science. We just need a way to test it.
Look, I'm just explaining how banks work. If you have an online business, you need a real world address and telephone number on your site. Not 'info@.' Not links from other sites. Not google. The bank needs to know that your customers will have a way to contact you in the real world to resolve disputes, otherwise the bank fears it will have to eat the costs of said disputes.
Given the number of sites I've seen that don't include real world contact info, I think this gets a big [[citation needed]].
No, the data is supposed to be non-linear. At least, that's what most file formats specify, and that was the behavior that was common before well-specified file formats were common.
Historically, the process was to convert the brightness level linearly to an electron gun control voltage in a CRT. That produced a non-linear brightness output on the screen, with a gamma of around 2.2 (details varied). Today, we have well-specified response curves, but we still use non-linear brightness values. The reason is largely that our eyes are more sensitive to the same (absolute) change on dark parts of the screen than bright parts (eg going from 1% to 2% of full brightness is a vastly larger change than from 99% to 100%). The gamma curve produces an output where unit steps in the (non-linear) brightness value produce similar apparent magnitude changes across the whole brightness range.
The result is that the scale appears linear: gray 127 looks about half as bright as white 255. It isn't, though. It's about 22% as bright. That apparent linearity is probably the cause of much of the confusion.
The assumption of gamma 2.2 isn't only in the output device. It's also in the underlying data: cameras output photos that assume gamma 2.2, for example. The standards are certainly a mess, but they've gotten much better recently. It used to be that gamma 2.2 was a half-decent guess, and 1.0 (linear data) an awful guess. Today, sRGB is fairly widely accepted, and it has a gamma of approximately 2.2. In other words, it's always been obvious that assuming linear data is wrong, but it hasn't always been obvious what the right assumption is. Today, though, the right assumption is sRGB unless otherwise specified.
You're fired up about this "scaling bug" because someone told you about it, not because it actually matters to you, and the above snippet proves it. Do you know what happens when you "adjust the brightness"? Do you care? Basically all brightness/contrast/levels/curves/whatever adjustments change the colors (and not for just one reason either). Image editing is much more complicated than you think it is. If the effects of non-linear gamma on scaling are news to you, you just got your feet wet. The same basic cause affects everything which combines pixel data or changes existing pixels, i.e. everything. That's why calling it a scaling algorithm bug is wrong. Before we start worrying about non-linear gamma, we should fix the clipping behavior of exposure compensation in most RAW conversion software.
Yeah, it's news to me that it has this impact. (I knew about nonlinear color spaces and such, but never really thought about how it impacted stuff like this — I find it interesting, but I haven't actually written software that cares that much. And now that I think about it, this bug exists in at least a fractal generator I wrote once.)
But hey, I learn lots of new things about photography. I wouldn't call myself a "serious" amateur, but I know (and care) more about the details than most people. And pretty uniformly, any time I find the camera or software is doing something complicated and automatic, I want the manual version. I use semi-automatic exposure settings more often than fully manual, but there's no way I'd buy a camera that didn't have the manual version. Similarly, I mostly want my software to just stay out of the way. For images I care about, my usual procedure is to take it correctly in the first place, and then I use software to remove noise and scale it down. Occasionally I'll adjust various color options; when I do, I basically just care about a very subjective "make it look good". I may not understand the finer points, but I understand that those tools are fussing with color curves. When I want to fuss with colors, I want that; when I want to scale the image, I sure as hell don't.
They did exactly that. It's called sRGB, and these days (nearly) all monitors claim to follow it. Some have better color than others, but they're all nominally sRGB. The ones that don't follow sRGB are well-specified as doing something else (and expensive), and purchased by people that know what to do with them. The (somewhat) arbitrary standard is a gamma of roughly 2.2. Monitors that don't produce that naturally fake it with software (in the monitor, not the computer).
The problem is that the computer software doesn't expect linear, when it comes to what color is what, because it never has been linear. Basically, 256 shades of brightness is enough — but only if they aren't linearly spaced. There's a huge difference between a gray that's 1% of the white luminosity and 0%, but you can't see the difference between 99% and 100%. Using a gamma curve fixes this, by roughly matching the apparent change in brightness per change in the brightness. So the whole toolchain is built around a gamma of roughly 2.2, except when it comes to things like image manipulation.
The example images that make it really clear are academic examples. But the scaled photos are all enough of a change to be worth noticing and caring about if you're a serious amateur photographer (never mind professional). And they don't look particularly unusual to me (I haven't looked for odd trickery, but I assume he's being honest here).
Really? It looked to me like the images I looked at need to be pretty badly pixelated (resized well beyond what a serious amateur would find acceptable) for this to be a serious concern. Of course some people are always going to be more interested in over analysing their photos than producing good ones...*shrug*
I don't see why this is worth defending. It's obviously incorrect, even if the errors are minor. If I resize something, the tool should just resize, not also shift brightness levels. I don't like to over-analyze or over-edit my photos, but I do want my tools do precisely what they're supposed to, neither more nor less. I like manual settings on my camera, and if I want to change brightness levels then I want that to be explicit.
Note that I'm not excusing the software programs from handling this better - certainly not Photoshop - but it's 1. not a new revelation and 2. certainly not a "scaling algorithm bug".
In what sense is it not a scaling algorithm bug? The images look different after scaling than before, when interpreted in accordance with the appropriate specs. It seems to me that the specification for the scale function is something like "returns an image that is as visually similar as possible to the original, but reduced in size by the specified amount." It might be known, and it might be better described as using the wrong algorithm than an algorithm bug, but it's definitely a bug in the program.
The rest of the post I basically agree with: the differences are minor except in weird test images. However, if I want to adjust the brightness, I'll do that. If I edit the photo at full res and then save at lower res for use on the web, I don't want the result to look different. I wouldn't be able to tell the difference if not in swappable comparisons, but one might still look better.
The example images that make it really clear are academic examples. But the scaled photos are all enough of a change to be worth noticing and caring about if you're a serious amateur photographer (never mind professional). And they don't look particularly unusual to me (I haven't looked for odd trickery, but I assume he's being honest here).
Actually, any well-specified file format will specify the gamma. Not all allow you to set it per-file, but they do specify it. Normally this is a line in the spec that reads something like "color values use the sRGB color space" or similar — which specifies a gamma of 2.2 (roughly). And sRGB with it's nearly 2.2 gamma has become so standard that assuming anything else (in the absence of a clear spec) would be idiotic.
Brightness by itself is not a function, so it can't be linear or nonlinear.
Displayed luminosity is a function of the data value in the image file, which is what the OP meant by brightness. And it most certainly can be linear or non-linear.
The data in the pictures is not linear data. It assumes that it will be displayed on a system that introduces a gamma of 2.2. (If your display system does not do that physically, it should correct for this.) That is, a gray 127 should not display as halfway between a white 255 and a black zero, in terms of light output. (It should *appear* halfway between them visually, because your eyes aren't linear — that's (part of) why gamma is in use in the first place.) So, a checkerboard pattern of white / black squares will have half the luminosity of the white squares. When scaling down, software will turn it into a bunch of gray pixels. But they should be gray pixels of value 186, not 127.
The page is not well written, but his example images make the issue very clear. It's not about your monitor gamma; it's about the "standard gamma" that all image files assume your monitor has.
Thermal engines are limited by Carnot efficiency. Fuel cells don't require a thermal step (operational temp is not the same thing), and so are not limited by Carnot cycle efficiency. Certain types of fuel cells may have other efficiency limits, but as a class they aren't limited except by the second law of thermodynamics.
No, they did not lose that right: if they had, then they wouldn't be able to sue the second person who infringed upon it.
You can certainly cause them damage by distributing it. Possibly even in excess of direct lost sales, though that's much harder to prove. But they still have the exclusive right to legally distribute it.
Slashdot Mirror
Great, this will work wonders for my zero-cost zero-thickness self-intersecting perfectly rigid solar panels. I just hope my spherical vacuum-chickens don't try to nest in it.
I recently upgraded to the clear spherical vacuum chickens, so I no longer have this problem. I highly recommend them.
No. This is a hill-climbing style random walk. Newton's method is something much more special-purpose (and frequently vastly superior, in the sorts of problems it does well).
...and with it shall go the supposed evidence. The paltry statistic of 244 gunshots in a two month period vs. 177 in another does not indicate anything about supposed trends in gun crime. Furthermore, yearly gun crime is what is of importance, not a few weeks.
A decent starting assumption is that things like gun shots in a given time period follow a Poisson distribution. The difference in gunshots between the periods (244 - 177 = 67) would then have variance of 421 (= 244+177), or a standard deviation of 20.5. That puts the difference at 3.3 standard deviations, which is highly significant. In other words, the second period really did have a lower gunshot rate, it wasn't just noise.
Of course, that doesn't address causality: there could be some other factor that caused the drop. Or, perhaps the choice of 2-month period was not arbitrary; if it was chosen to make the system look good, the significance probably goes away. And, as you suggest, yearly stats are more meaningful.
What about people that don't know they need to lock their doors when they leave the car, or change the oil on a regular basis?
If they're like a normal person, they learn from their mistakes and they don't do the same thing again.
Oddly, computers seem to be exempt from that. The same people get viruses, trojans, malware, etc, and keep downloading crap and failing to install updates, and it keeps happening. Most drivers seem to learn to change the oil after destroying an engine, but somehow computer users are different. Clearly there's plenty wrong with the software in the first place, but there's also something very odd about users who experience these problems and then both continue using the same problematic software and failing to learn from their mistakes.
idiots who want to use what they don't understand deserve to get 0wned.
Totally. All those drooling idiots driving cars without knowing how to rebuild an engine and transmission are just asking for it.
What about people that don't know they need to lock their doors when they leave the car, or change the oil on a regular basis?
You can build circuits that detect faults while operating. They're more complex than their normal counterparts, but the transistor count is less than 2x. On-line error detection is a common name.
Of course, such circuits get really expensive if you don't have a large market for them. But cars represent a fairly large market, so if it was the best approach they could probably use them. Of course, that assumes there's any market or regulatory pressure to use any sort of error detection at all.
That's why the author proposes the use of an external hardware verifier, whose purpose mostly seems to be verifying that it was fast enough that the malware didn't have time to write to secondary storage.
Detecting a malware detector is just as hard as detecting malware. In general, detecting software of a specific type is halting-equivalent. In practice, the goal is to take shortcuts so that your adversary has a halting-equivalent problem and you don't. At present, the malware authors are winning. If we could force them to detect the malware detectors, that would be a huge advance.
My skepticism about this is the obvious one: what if the malware just lets itself get swapped out, and relies on stealth to survive the process?
How about "We are aware of the issue and are investigating how it happened. We're sorry we don't have more to tell you, but we don't yet know. We'll update when we can say more." You can both be honest and not piss off the lawyers. You don't have to lie about it.
Newegg is clearly lying: these aren't demo units. I'm sure they're well-intentioned, and I'm sure they'll deal with their customers fairly. But I'd be happier with them if they told the truth while they were at it. And if they don't know (or can't say) what actually happened, then apologize and explain that.
My biggest search feature request: the ability to block a domain from all future searches I see. If Google never gave me another hit from some of those atrocious sites that just re-link things like paper abstracts and throw some ads around them, my search experience would improve.
For every used game sold, the game editor gets ZERO.
Really? What do you think the person selling their game used is going to go spend that money on? More video games, would be my guess.
I'm certain you're correct, but it's rather remarkably short-sighted on the part of publishers to think every used sale represents a potential new game sale lost.
My personal hypothesis is that either you can't change history, only fulfill it because it has already happened, or you end up in a different time line. Yay! now we have a testable hypothesis and science. We just need a way to test it.
You mean the Novikov principle?
Look, I'm just explaining how banks work. If you have an online business, you need a real world address and telephone number on your site. Not 'info@.' Not links from other sites. Not google. The bank needs to know that your customers will have a way to contact you in the real world to resolve disputes, otherwise the bank fears it will have to eat the costs of said disputes.
Given the number of sites I've seen that don't include real world contact info, I think this gets a big [[citation needed]].
No, the data is supposed to be non-linear. At least, that's what most file formats specify, and that was the behavior that was common before well-specified file formats were common.
Historically, the process was to convert the brightness level linearly to an electron gun control voltage in a CRT. That produced a non-linear brightness output on the screen, with a gamma of around 2.2 (details varied). Today, we have well-specified response curves, but we still use non-linear brightness values. The reason is largely that our eyes are more sensitive to the same (absolute) change on dark parts of the screen than bright parts (eg going from 1% to 2% of full brightness is a vastly larger change than from 99% to 100%). The gamma curve produces an output where unit steps in the (non-linear) brightness value produce similar apparent magnitude changes across the whole brightness range.
The result is that the scale appears linear: gray 127 looks about half as bright as white 255. It isn't, though. It's about 22% as bright. That apparent linearity is probably the cause of much of the confusion.
The assumption of gamma 2.2 isn't only in the output device. It's also in the underlying data: cameras output photos that assume gamma 2.2, for example. The standards are certainly a mess, but they've gotten much better recently. It used to be that gamma 2.2 was a half-decent guess, and 1.0 (linear data) an awful guess. Today, sRGB is fairly widely accepted, and it has a gamma of approximately 2.2. In other words, it's always been obvious that assuming linear data is wrong, but it hasn't always been obvious what the right assumption is. Today, though, the right assumption is sRGB unless otherwise specified.
if I want to adjust the brightness, I'll do that.
You're fired up about this "scaling bug" because someone told you about it, not because it actually matters to you, and the above snippet proves it. Do you know what happens when you "adjust the brightness"? Do you care? Basically all brightness/contrast/levels/curves/whatever adjustments change the colors (and not for just one reason either). Image editing is much more complicated than you think it is. If the effects of non-linear gamma on scaling are news to you, you just got your feet wet. The same basic cause affects everything which combines pixel data or changes existing pixels, i.e. everything. That's why calling it a scaling algorithm bug is wrong. Before we start worrying about non-linear gamma, we should fix the clipping behavior of exposure compensation in most RAW conversion software.
Yeah, it's news to me that it has this impact. (I knew about nonlinear color spaces and such, but never really thought about how it impacted stuff like this — I find it interesting, but I haven't actually written software that cares that much. And now that I think about it, this bug exists in at least a fractal generator I wrote once.)
But hey, I learn lots of new things about photography. I wouldn't call myself a "serious" amateur, but I know (and care) more about the details than most people. And pretty uniformly, any time I find the camera or software is doing something complicated and automatic, I want the manual version. I use semi-automatic exposure settings more often than fully manual, but there's no way I'd buy a camera that didn't have the manual version. Similarly, I mostly want my software to just stay out of the way. For images I care about, my usual procedure is to take it correctly in the first place, and then I use software to remove noise and scale it down. Occasionally I'll adjust various color options; when I do, I basically just care about a very subjective "make it look good". I may not understand the finer points, but I understand that those tools are fussing with color curves. When I want to fuss with colors, I want that; when I want to scale the image, I sure as hell don't.
They did exactly that. It's called sRGB, and these days (nearly) all monitors claim to follow it. Some have better color than others, but they're all nominally sRGB. The ones that don't follow sRGB are well-specified as doing something else (and expensive), and purchased by people that know what to do with them. The (somewhat) arbitrary standard is a gamma of roughly 2.2. Monitors that don't produce that naturally fake it with software (in the monitor, not the computer).
The problem is that the computer software doesn't expect linear, when it comes to what color is what, because it never has been linear. Basically, 256 shades of brightness is enough — but only if they aren't linearly spaced. There's a huge difference between a gray that's 1% of the white luminosity and 0%, but you can't see the difference between 99% and 100%. Using a gamma curve fixes this, by roughly matching the apparent change in brightness per change in the brightness. So the whole toolchain is built around a gamma of roughly 2.2, except when it comes to things like image manipulation.
The example images that make it really clear are academic examples. But the scaled photos are all enough of a change to be worth noticing and caring about if you're a serious amateur photographer (never mind professional). And they don't look particularly unusual to me (I haven't looked for odd trickery, but I assume he's being honest here).
Really? It looked to me like the images I looked at need to be pretty badly pixelated (resized well beyond what a serious amateur would find acceptable) for this to be a serious concern. Of course some people are always going to be more interested in over analysing their photos than producing good ones...*shrug*
I don't see why this is worth defending. It's obviously incorrect, even if the errors are minor. If I resize something, the tool should just resize, not also shift brightness levels. I don't like to over-analyze or over-edit my photos, but I do want my tools do precisely what they're supposed to, neither more nor less. I like manual settings on my camera, and if I want to change brightness levels then I want that to be explicit.
Note that I'm not excusing the software programs from handling this better - certainly not Photoshop - but it's 1. not a new revelation and 2. certainly not a "scaling algorithm bug".
In what sense is it not a scaling algorithm bug? The images look different after scaling than before, when interpreted in accordance with the appropriate specs. It seems to me that the specification for the scale function is something like "returns an image that is as visually similar as possible to the original, but reduced in size by the specified amount." It might be known, and it might be better described as using the wrong algorithm than an algorithm bug, but it's definitely a bug in the program.
The rest of the post I basically agree with: the differences are minor except in weird test images. However, if I want to adjust the brightness, I'll do that. If I edit the photo at full res and then save at lower res for use on the web, I don't want the result to look different. I wouldn't be able to tell the difference if not in swappable comparisons, but one might still look better.
The example images that make it really clear are academic examples. But the scaled photos are all enough of a change to be worth noticing and caring about if you're a serious amateur photographer (never mind professional). And they don't look particularly unusual to me (I haven't looked for odd trickery, but I assume he's being honest here).
Actually, any well-specified file format will specify the gamma. Not all allow you to set it per-file, but they do specify it. Normally this is a line in the spec that reads something like "color values use the sRGB color space" or similar — which specifies a gamma of 2.2 (roughly). And sRGB with it's nearly 2.2 gamma has become so standard that assuming anything else (in the absence of a clear spec) would be idiotic.
Brightness by itself is not a function, so it can't be linear or nonlinear.
Displayed luminosity is a function of the data value in the image file, which is what the OP meant by brightness. And it most certainly can be linear or non-linear.
But then, I suppose you already knew that.
The data in the pictures is not linear data. It assumes that it will be displayed on a system that introduces a gamma of 2.2. (If your display system does not do that physically, it should correct for this.) That is, a gray 127 should not display as halfway between a white 255 and a black zero, in terms of light output. (It should *appear* halfway between them visually, because your eyes aren't linear — that's (part of) why gamma is in use in the first place.) So, a checkerboard pattern of white / black squares will have half the luminosity of the white squares. When scaling down, software will turn it into a bunch of gray pixels. But they should be gray pixels of value 186, not 127.
The page is not well written, but his example images make the issue very clear. It's not about your monitor gamma; it's about the "standard gamma" that all image files assume your monitor has.
Thermal engines are limited by Carnot efficiency. Fuel cells don't require a thermal step (operational temp is not the same thing), and so are not limited by Carnot cycle efficiency. Certain types of fuel cells may have other efficiency limits, but as a class they aren't limited except by the second law of thermodynamics.
They have the right; it has been infringed. Once the infringement stops (via lawsuit, etc) they still have the right.
No, they did not lose that right: if they had, then they wouldn't be able to sue the second person who infringed upon it.
You can certainly cause them damage by distributing it. Possibly even in excess of direct lost sales, though that's much harder to prove. But they still have the exclusive right to legally distribute it.