The technique is very simple. Mr Blaze has only succeeded in reinventing the wheel.
Only half true. Yes, the attack was known previously, but not widely. Mr. Blaze has succeeded in spreading knowledge and provoking discussion and thought as to how to address the security failure. Belittling the work because others got there first misses the point.
This method (and all 4D light field capture that I know of) don't use polarization information.
You want to render a scene from a new viewpoints. If you know how all the light in a cube is moving, you can render the scene in that cube from any viewpoint by putting a virtual "camera" in the space and intersecting light rays with it (through a virtual "aperature", of course). Think of it as a parameterization problem, and you can see that this will become a big table lookup (with interpolation).
Now, for the most general case, you'd need to parameterize the space in 5D to get the data you need for unique-view rendering (3D position, plus 2D for which direction you're looking), but you can simplify things a bit by assuming that:
a) There's a box aroung what you're looking at.
b) you're outside the box.
The surface of the box is 2D, and since you're outside of it, you only need data at the surface. At each point on the surface you need 2D of parameterized information (angle and azimuth), so 4D all together.
In practice, the parameterization most people use is "two-plane", in that you have two parallel planes, with your object between them (well, that part's optional), and you store the rays by the two sets of 2D coordinates of where they hit the two planes.
Now, what this paper does is use Integrated Photography, which is just photography with one big lens (on the camera) and a bunch of really tiny lenses in a grid (in front of the camera). The camera, through its big lens gives one set of 2D coordinates, and each little lens creates another set of coordinates in its own very tiny space (look at figure 2 in the paper for what I'm talking about). So you end up with a sort of 2-level hierarchical paramterization.
Each of the tiny images, one from each integrated lens, is basically a little picture of the scene from the location of that lens. So you can turn this into a two-plane parameterization: the location of the lens determines where a ray hits the first plane (the integrated lens plane), and the position within the tiny image from that lens determines the direction the ray is going, and therefore the eventual point where it strikes the second plane. You need to know exactly how your integrating lens affects light, which they get by precalibration, from my reading of the paper. (You don't need the two-plane parameterization to render images. The authors of this paper work directly from the lens image. It's just important to realize that they are equivalent in concept, if not in the details.)
This page could be quite useful to see these concepts with images:
http://graphics.lcs.mit.edu/~aisaksen/projects/d rl f/index.html
BTW, the paper by Isaksen really should have been referenced in the paper this discussion is about, since it mentions integrated lenses in the 4D light field context, and even has an image of a synthetic integrated photo. I think the main contribution of this paper is probably the use of HDTV to do it in real time. That's pretty cool.
Finally, also on the MIT graphics web page is how to improve your rendering by getting a better approximation to your geometry. See the work under publications titled "Iamge Based Visual Hulls". This is another way of tackling the 3D video problem.
It's interesting to note that bilinear filtering and trilinear filtering are exactly the proper point sampling scaling
techniques now implemented in all 3D cards that this fellow talks about when discussing how images should
be scaled up for use on a monitor.
I'm not sure who "this fellow" is, but I assume you mean Alvy Ray Smith. In any case, bilinear and trilinear reconstruction functions are not "proper" for all cases, especially in texture mapping. For the highest quality, you need an anisotropic filter. A good discussion of the technical issues can be found in this SIGGRAPH 1999 paper.
Admittedly, bi/tri-linear reconstruction is much better than box-filtering (aka pixel replication). On a very skew polygon with texture, trilinear aliases (either blurs or jaggies) badly because it's an isotropic filter. Anisotropic filters handle this case, but are more expensive.
Everyone who's ever used a low-res monitor knows that a pixel really is a little square...
This is not entirely correct. The reconstruction filter of a cheap, low-res monitor is something like a little square (with a little bit of gaussianish convolution). However, the pixel itself is a point sample of some image function.
In any case, show me a monitor that does correct 2D reconstruction of an image from these samples. Can't?
That's because it doesn't exist.
Actually, if the original signal is bandlimited below the Nyquist frequency, then reconstruction the image with the sinc filter is guaranteed to produce the correct image. The problem is, most images are not frequency limited, and the sinc filter produces "ringing" on when used to reconstruct those images. Ringing is particulary irksome to the visual system, so even though sinc is the "perfect" reconstruction filter, it's a poor choice when dealing with images. A Gaussian is much preferrable.
Mankind DOES NOT HAVE a model for image processing which is in any
way "correct".
I strongly disagree. 2D signal processing is a young but well-grounded field. In terms of reconstructing images from samples, it's provably correct. Theories of visual perception are still a bit sparse, but not so bad as to be called incorrect. Admittedly, we can't explain everything, but we're not totally in the dark about how the visual system works.
Calling it the "path to the Dark Side" is just silly.
I agree that it's a tongue-in-cheek statement, but the fact is that thinking of pixels as little squares keeps people from gainging a good understanding of image reconstruction, filtering, and antialiasing. In this sense, "knowing" that pixels are little squares is worse than not knowing anything about them at all.
Actually, voxel terrains (from the computer gaming world) are not actually voxels. They are 2D heightfields. The misnomer is due to two unfortunate traits that voxel data sets and heightfields share:
They both represent 3D data, though one represents data (usually scalars) at XYZ positions and the other represents a Z at each XY position.
They can both be rendered via raycasting (raytracing without the bounces), though again, one is 3D raycasting and the other is a sort of 2.5D method.
The "voxel terrain" rendering method was first described by P.K. Robertson in "Fast Perspective Views of Images Using One-Dimensional Operations" (IEEE CG&A, February 1987, page 47). It's been rediscovered by various people since then. I believe (but don't quote me) that it could be considered a limited form of McMillan's Occlusion Compatible ordering.
That definition is only partially correct. Unfortunately, it falls into one of the oldest mental traps of the graphics world, thinking of pixels as squares and voxels as cubes.
Pixels and voxels are zero-dimensional samples of some 2D image or 3D volume. Thinking about them as squares, gaussian splats, or something other than samples is the path to the Dark Side.
For more info, read Alvy Ray Smith's Tech Memo, "A Pixel is Not a Little Square, a Pixel is Not a Little Square, a Pixel is Not a Little Square! (And a Voxel is Not a Little Cube)" available here.
The netrek community uses the same method of blessing (public/private RSA keys (with permission from RSA)). I believe the first successful hack after blessing was implemented was less than a month later, but it required a kernel modification on the client's machine, and a patch to make it much harder was suggested (I don't know if it was ever deployed).
Oddly, reading through the description of the Encryption it seems that the plan is to use Twofish rather than a public key method. This may just be development lag (that URL points to beta code, I believe). There are good reasons for using assymetric rather than symmetric cryptography; I won't go into them here, however, since they're a little off-topic. Interested parties can mail me if they want to discuss the issues in more depth.
I didn't say that it downloaded "child porn", I said "random porn". It's never downloaded child porn that I've seen, but I don't watch it much, nor do I log what it downloads.
Interestingly, the past few days that I've checked the contents of my cache, it's been less pornful than before. Perhaps fewer people are searching for porn, or more people are searching for music.
------------------------------------------------ - This message is informational, not a flame:
I recently added Freenet-style automatic caching to gnut, one of the gnutella clients. The way the caching algorithm works is that as well as functioning as a normal gnutella node, gnut also watches the query_response stream as it routes it to other clients. Every once in a while, it chooses a random file offered for download in response to someone else's search request, and downloads it into a local cache, making it available to gnutellanet from a new location.
The idea is to propagate popular files to make it easier to find them and to spread out bandwidth usage between servers. Popular files would, presumedly, be requested more often and thefore occur in query responses more often as well.
Since the system chooses random responses, it's quite possible that some queries will occur from the cleaner without the user actually requesting the file. In testing, my caching gnut client seems to download random porn about 5% of the time.
I'm not saying that the cleaner is a bad idea, but I wanted you to be aware that this new feature might lead you to put someone's IP address up for the world to see even though they haven't tried to download files from you. Since this feature is fairly new, it's unlikely to have occurred yet, but if caching becomes widespread, it's likely that you'll see download requests that have no real user behind them.
One way to prevent misinterpreting a download request is to keep a list of GUIDs of searches that you've responded to, and use that list to corroborate download requests. If a client downloads a file without having searched for it, it's likely to be due to caching.
Just so you're aware, Ray Jones ------------------------------------------------ -
BTW, Gnut is available here: http://www.umr.edu/~jjp
The REASON a serial rapist shouldn't be allowed to sell the rights to their life story for megabucks is out of respect for the rights of their VICTIMS, either dead or alive.
I'm not against victim's rights as a concept, but only in carefully limited situations. I'm strictly against awarding any rights to the dead if those rights come into conflict with the rights of the living. Moreover, it seems likely that you are appealing to victims' rights to justify limitations of the rights of criminals even after criminals have "done their time." In other words, you wish to continue punishing (by limiting freedom) a person even after they have made what society considers restitution. This is a very dangerous idea, and it deserves more careful analysis, rather than appeals to "respect."
In my mind, a corporation does NOT have the same right to privacy as an individual. If Mitnick chooses to describe how he defeated the security on a particular site through his limited technical knowhow and superior social engineering skills, he's not besmirching the memory of someone's dead relative, or airing facts which will bring back horrific memories to a victim.
Both of these examples (besmirching dead people, bringing back bad memories) are not sufficient justification for limiting free speech rights of any individual. In the case of the first example, dead people's rights should never outweigh the rights of the living.
In the second, it would seem that this argument could apply equally well to speech by non-criminals: person A harms person B, person C talks about the facts of the case bringing back bad memories for B. C can speak, but A cannot?
The interpretation of the First Amendment is clear: you cannot ban speech solely because you do not like the speaker or their message. By the argument above, I could be prohibited from talking about the holocaust, because it brings back horrific memories in the victims, even if I were talking about how bad the holocaust was and how we should never let it happen again.
Now, the biases in favor of free speech become less one-sided in the case of commercial speech, which has fewer protections. In addition, the somewhat ill-defined right to privacy comes into play, when discussing individuals, even if everything being said is factual. This requires the evaluation of "newsworthiness" and such. However, to reiterate, this should not apply to dead people.
Again, I don't disagree with the concepts of victims' rights, but I think they should be carefully limited, balanced against more fundamental rights, and absolutely not used as extensions of punishment of criminals beyond the sentence they have already received.
I agree. I think we should make a lot of noise about this, even before we've gotten all the nitty-gritty details.
I try to be a level-headed person, and don't encourage rampant flaming. However, the Linux community's greatest asset in cases like this is the ability to generate noise and "buzz". Right now, we should be spreading the word that Abit seems to be violating the GPL. Tomorrow, it should that they *are* violating the GPL. And next week, the boycott should start, and we should be in stark-raving-Stallman-ESR mode. Not flaming, but sticking to our ideological guns and using our *significant* weight in the technical community to rein in Abit, and to prevent this from becoming a common occurrence. We need to make it known that if a company violates the GPL, we're going to notice and get mad about it. Otherwise, they'll never learn, and we'll keep going through this time after time, and eventually, they might win.
We don't have the usual tools that Big Companies[tm] do to keep each other semi-honest (lawyers, contracts, hit-men). We need to use what we do have, our brains and mouths.
Those that claim that banning non-educational uses of school networks is acceptable should consider that academic freedom is almost universally considered to completely encompass and extend the freedoms provided for by the First Amendment. (Yes, I realize that these are cross-domain (academia vs law) concepts.)
Given that the First Amendment doesn't require that speech (or listening to speech) serve any useful purpose before being protected (modulo wrong-headed obscenity exceptions), it doesn't seem possible to claim that banning Napster is anything but censorship.
The correct answer, as pointed out in other posts, is to use bandwidth limiting methods and prioritization techniques on the routers, so as to provide the maximum freedom for all users.
I am not a lawyer, but if the Linux community had the permission of even one DVD producer to use DeCSS, then DeCSS is no longer "circumventing" an access control. I don't know if this would require licensing CSS from DVD CCA, but I bet not, since they're about to lose their trade-secret protection (w.h.p.)
Slashdot Mirror
Inspired by this, we took apart a printer and made this.
Only half true. Yes, the attack was known previously, but not widely. Mr. Blaze has succeeded in spreading knowledge and provoking discussion and thought as to how to address the security failure. Belittling the work because others got there first misses the point.
This method (and all 4D light field capture that I know of) don't use polarization information.
d rl f/index.html
You want to render a scene from a new viewpoints. If you know how all the light in a cube is moving, you can render the scene in that cube from any viewpoint by putting a virtual "camera" in the space and intersecting light rays with it (through a virtual "aperature", of course). Think of it as a parameterization problem, and you can see that this will become a big table lookup (with interpolation).
Now, for the most general case, you'd need to parameterize the space in 5D to get the data you need for unique-view rendering (3D position, plus 2D for which direction you're looking), but you can simplify things a bit by assuming that:
a) There's a box aroung what you're looking at.
b) you're outside the box.
The surface of the box is 2D, and since you're outside of it, you only need data at the surface. At each point on the surface you need 2D of parameterized information (angle and azimuth), so 4D all together.
In practice, the parameterization most people use is "two-plane", in that you have two parallel planes, with your object between them (well, that part's optional), and you store the rays by the two sets of 2D coordinates of where they hit the two planes.
Now, what this paper does is use Integrated Photography, which is just photography with one big lens (on the camera) and a bunch of really tiny lenses in a grid (in front of the camera). The camera, through its big lens gives one set of 2D coordinates, and each little lens creates another set of coordinates in its own very tiny space (look at figure 2 in the paper for what I'm talking about). So you end up with a sort of 2-level hierarchical paramterization.
Each of the tiny images, one from each integrated lens, is basically a little picture of the scene from the location of that lens. So you can turn this into a two-plane parameterization: the location of the lens determines where a ray hits the first plane (the integrated lens plane), and the position within the tiny image from that lens determines the direction the ray is going, and therefore the eventual point where it strikes the second plane. You need to know exactly how your integrating lens affects light, which they get by precalibration, from my reading of the paper. (You don't need the two-plane parameterization to render images. The authors of this paper work directly from the lens image. It's just important to realize that they are equivalent in concept, if not in the details.)
This page could be quite useful to see these concepts with images:
http://graphics.lcs.mit.edu/~aisaksen/projects/
BTW, the paper by Isaksen really should have been referenced in the paper this discussion is about, since it mentions integrated lenses in the 4D light field context, and even has an image of a synthetic integrated photo. I think the main contribution of this paper is probably the use of HDTV to do it in real time. That's pretty cool.
Finally, also on the MIT graphics web page is how to improve your rendering by getting a better approximation to your geometry. See the work under publications titled "Iamge Based Visual Hulls". This is another way of tackling the 3D video problem.
I'm not sure who "this fellow" is, but I assume you mean Alvy Ray Smith. In any case, bilinear and trilinear reconstruction functions are not "proper" for all cases, especially in texture mapping. For the highest quality, you need an anisotropic filter. A good discussion of the technical issues can be found in this SIGGRAPH 1999 paper.
Admittedly, bi/tri-linear reconstruction is much better than box-filtering (aka pixel replication). On a very skew polygon with texture, trilinear aliases (either blurs or jaggies) badly because it's an isotropic filter. Anisotropic filters handle this case, but are more expensive.
This is not entirely correct. The reconstruction filter of a cheap, low-res monitor is something like a little square (with a little bit of gaussianish convolution). However, the pixel itself is a point sample of some image function.
In any case, show me a monitor that does correct 2D reconstruction of an image from these samples. Can't? That's because it doesn't exist.
Actually, if the original signal is bandlimited below the Nyquist frequency, then reconstruction the image with the sinc filter is guaranteed to produce the correct image. The problem is, most images are not frequency limited, and the sinc filter produces "ringing" on when used to reconstruct those images. Ringing is particulary irksome to the visual system, so even though sinc is the "perfect" reconstruction filter, it's a poor choice when dealing with images. A Gaussian is much preferrable.
Mankind DOES NOT HAVE a model for image processing which is in any way "correct".
I strongly disagree. 2D signal processing is a young but well-grounded field. In terms of reconstructing images from samples, it's provably correct. Theories of visual perception are still a bit sparse, but not so bad as to be called incorrect. Admittedly, we can't explain everything, but we're not totally in the dark about how the visual system works.
Calling it the "path to the Dark Side" is just silly.
I agree that it's a tongue-in-cheek statement, but the fact is that thinking of pixels as little squares keeps people from gainging a good understanding of image reconstruction, filtering, and antialiasing. In this sense, "knowing" that pixels are little squares is worse than not knowing anything about them at all.
- They both represent 3D data, though one represents data (usually scalars) at XYZ positions and the other represents a Z at each XY position.
- They can both be rendered via raycasting (raytracing without the bounces), though again, one is 3D raycasting and the other is a sort of 2.5D method.
The "voxel terrain" rendering method was first described by P.K. Robertson in "Fast Perspective Views of Images Using One-Dimensional Operations" (IEEE CG&A, February 1987, page 47). It's been rediscovered by various people since then. I believe (but don't quote me) that it could be considered a limited form of McMillan's Occlusion Compatible ordering.Pixels and voxels are zero-dimensional samples of some 2D image or 3D volume. Thinking about them as squares, gaussian splats, or something other than samples is the path to the Dark Side.
For more info, read Alvy Ray Smith's Tech Memo, "A Pixel is Not a Little Square, a Pixel is Not a Little Square, a Pixel is Not a Little Square! (And a Voxel is Not a Little Cube)" available here.
Oddly, reading through the description of the Encryption it seems that the plan is to use Twofish rather than a public key method. This may just be development lag (that URL points to beta code, I believe). There are good reasons for using assymetric rather than symmetric cryptography; I won't go into them here, however, since they're a little off-topic. Interested parties can mail me if they want to discuss the issues in more depth.
Ray Jones
I didn't say that it downloaded "child porn", I said "random porn". It's never downloaded child porn that I've seen, but I don't watch it much, nor do I log what it downloads.
Interestingly, the past few days that I've checked the contents of my cache, it's been less pornful than before. Perhaps fewer people are searching for porn, or more people are searching for music.
I sent this message to cleaner@zeropaid.com:
- -
- -
-----------------------------------------------
This message is informational, not a flame:
I recently added Freenet-style automatic caching to gnut, one of the
gnutella clients. The way the caching algorithm works is that as well
as functioning as a normal gnutella node, gnut also watches the
query_response stream as it routes it to other clients. Every once in
a while, it chooses a random file offered for download in response to
someone else's search request, and downloads it into a local cache,
making it available to gnutellanet from a new location.
The idea is to propagate popular files to make it easier to find them
and to spread out bandwidth usage between servers. Popular files
would, presumedly, be requested more often and thefore occur in query
responses more often as well.
Since the system chooses random responses, it's quite possible that
some queries will occur from the cleaner without the user actually
requesting the file. In testing, my caching gnut client seems to
download random porn about 5% of the time.
I'm not saying that the cleaner is a bad idea, but I wanted you to be
aware that this new feature might lead you to put someone's IP address
up for the world to see even though they haven't tried to download
files from you. Since this feature is fairly new, it's unlikely to
have occurred yet, but if caching becomes widespread, it's likely that
you'll see download requests that have no real user behind them.
One way to prevent misinterpreting a download request is to keep a
list of GUIDs of searches that you've responded to, and use that list
to corroborate download requests. If a client downloads a file
without having searched for it, it's likely to be due to caching.
Just so you're aware,
Ray Jones
-----------------------------------------------
BTW, Gnut is available here:
http://www.umr.edu/~jjp
I'm not against victim's rights as a concept, but only in carefully limited situations. I'm strictly against awarding any rights to the dead if those rights come into conflict with the rights of the living. Moreover, it seems likely that you are appealing to victims' rights to justify limitations of the rights of criminals even after criminals have "done their time." In other words, you wish to continue punishing (by limiting freedom) a person even after they have made what society considers restitution. This is a very dangerous idea, and it deserves more careful analysis, rather than appeals to "respect."
In my mind, a corporation does NOT have the same right to privacy as an individual. If Mitnick chooses to describe how he defeated the security on a particular site through his limited technical knowhow and superior social engineering skills, he's not besmirching the memory of someone's dead relative, or airing facts which will bring back horrific memories to a victim.
Both of these examples (besmirching dead people, bringing back bad memories) are not sufficient justification for limiting free speech rights of any individual. In the case of the first example, dead people's rights should never outweigh the rights of the living.
In the second, it would seem that this argument could apply equally well to speech by non-criminals: person A harms person B, person C talks about the facts of the case bringing back bad memories for B. C can speak, but A cannot?
The interpretation of the First Amendment is clear: you cannot ban speech solely because you do not like the speaker or their message. By the argument above, I could be prohibited from talking about the holocaust, because it brings back horrific memories in the victims, even if I were talking about how bad the holocaust was and how we should never let it happen again.
Now, the biases in favor of free speech become less one-sided in the case of commercial speech, which has fewer protections. In addition, the somewhat ill-defined right to privacy comes into play, when discussing individuals, even if everything being said is factual. This requires the evaluation of "newsworthiness" and such. However, to reiterate, this should not apply to dead people.
Again, I don't disagree with the concepts of victims' rights, but I think they should be carefully limited, balanced against more fundamental rights, and absolutely not used as extensions of punishment of criminals beyond the sentence they have already received.
I agree. I think we should make a lot of noise about this, even before we've gotten all the nitty-gritty details.
I try to be a level-headed person, and don't encourage rampant flaming. However, the Linux community's greatest asset in cases like this is the ability to generate noise and "buzz". Right now, we should be spreading the word that Abit seems to be violating the GPL. Tomorrow, it should that they *are* violating the GPL. And next week, the boycott should start, and we should be in stark-raving-Stallman-ESR mode. Not flaming, but sticking to our ideological guns and using our *significant* weight in the technical community to rein in Abit, and to prevent this from becoming a common occurrence. We need to make it known that if a company violates the GPL, we're going to notice and get mad about it. Otherwise, they'll never learn, and we'll keep going through this time after time, and eventually, they might win.
We don't have the usual tools that Big Companies[tm] do to keep each other semi-honest (lawyers, contracts, hit-men). We need to use what we do have, our brains and mouths.
Those that claim that banning non-educational uses of school networks is acceptable should consider that academic freedom is almost universally considered to completely encompass and extend the freedoms provided for by the First Amendment. (Yes, I realize that these are cross-domain (academia vs law) concepts.)
Given that the First Amendment doesn't require that speech (or listening to speech) serve any useful purpose before being protected (modulo wrong-headed obscenity exceptions), it doesn't seem possible to claim that banning Napster is anything but censorship.
The correct answer, as pointed out in other posts, is to use bandwidth limiting methods and prioritization techniques on the routers, so as to provide the maximum freedom for all users.
I am not a lawyer, but if the Linux community had the permission of even one DVD producer to use DeCSS, then DeCSS is no longer "circumventing" an access control. I don't know if this would require licensing CSS from DVD CCA, but I bet not, since they're about to lose their trade-secret protection (w.h.p.)
The counter isn't dead, just slow. I've been able to get through consistently, as long as I'm willing to wait a while.