Actually, I believe that the watermarks are supposed to be robust enough to withstand some signal processing -- optimally any signal processing that retains the song's enjoyability should also retain the watermark, but that is infeasable.
Actually implementing the signal processing manually is kinda perverse, if you ask me, but that would be one way of doing it. It's really just a battle of who can withstand more quality loss: you or the watermark.
A more general solution is to encrypt both the header and body. The to: field would have to have salt added so that you could have several messages addressed to you without this being apparent.
The real difficulty is retrieving only your messages securely. The brute force method of retrieving all headers pending on the server and asking for the bodies of those you understand seems... wrong.
Ah: if the salt were generated in some known way (minutes past 1970, or something) I could send the mail server a set of ids (from when I last read mail or the oldest mail still on the server, whichever is later) that could feasably be me. The server then send me all headers from all matches, and I ask for all that really are me.
Because of salting, it is possible that some I will be sent headers that are not adressed to me; these I'll be unable to decrypt, thus won't ask for the message body.
As far as I can tell, this leaks no information.
Can anyone tell me if mixmaster does something similar?
You know, I don't know that I think this was all too fair; your application should guard against random user input, but needs to trust high level events sent from the OS.
Sending the application malformed event structures and snickering when it crashes seems just a shade less strawmannish than yanking out the power cord and acting suprised when everying dies.
I'd be much more interested in a report focussing on random but legal events.
The article didn't mention this, but does this mean she's losing resolution to gain color, or does the resoltion stay the same?
As a visualisation aid, imagine an LCD with 3 subpixels. Assuming that the pixels didn't shrink, if we went and added a 4th subpixel, we would have to sacrifice resolution when doing so.
I hate LaTeX. I have used for the last five years because it is unparalleled in its ability to create beautiful documents, but anyone who tries to use it for anything but Text-with-two-figures documents needs to budget a good day just to make it come our right. For example, it puts figures at the end of the document at the drop of a hat.
It is a nightmare of arcane commands, semi-undocuments interactions, and just plain wizardry. I don't know if I'd want WYSIWYG, but something a bit more denotational would be nice.
Not that I'm a DTP snob, but if you look at conference proceedings, it is immediately clear who used TeX and who used Word; word just doesn't create an good looking documents.
This is partially due to the great fonts that ship with TeX, but mostly it has to do with incredibly buffed word wrapping heuristics in TeX (I seem to recall this being an NP complete problem, or something), while I think Word just uses the greedy algorithm.
I've been looking for the successor to LaTeX for a while now; some application that produces equally beautiful layouts, but perhaps a bit easier to make do the stuff where you want the brace there and not thereish.
I thought framemaker might have been the ticket, but apparently not.
frankly, who cares what the individual formats are? Really. That is completly besides the point.
The important thing is that they try to make a semantic interpretation of the input image and apply differing approaches depending on the content. My above post answered the question above as to why they are comparing themselves to pdf; they focus on compressing exactly one kind of information, so they shouldn't be compared to standard image compression.
So I guess I don't agree about that being redundant. whereas the fact that they use wavelets... well, that's nice, but hardly germane.
That was almost 2.5 years ago. The reason they compare against pdf is that the target application seems to be text; compress the black and white text with one-bit RLE, and the background with JPG sort of deal.
Like so many other factors, speed is one that does matter if in the extreme, but once it's good enough, it has very little importance. Size is arguably more important, because every byte saved is saved every time you use the file, while time saved is only saved during compression, which is often batched.
So for time, order of magnitude seems to be the differentiator, while size has a linear importance.
The problem is compressing them. The ideas behind decompressing fractals are easy; use the self similarity inherent in pictures (a tree looks much like another tree, so build a picture of a forest by layering trees and then correcting the errors).
But figuring this out ammounts to exhaustive search. Apparently IFS had decent heuristics that got decent compression in only a few minutes. I think this is what was licenced, and that the file-format was open? This was a while ago, so I'm filling in the gaps in memory by guessing.
It is still unclear whether it is feasable to compute holograms in real time. It might be that this system is limited to simulcasting live content only -- ie it may only be able to record and replay, not create content from scratch.
The problem is that holograms are photographs of the interference patterns of two in-phase beams reflecting off an object. You project by illumiating the developed film with similar light.
Now, replace the film with a ccd and the developed film with a high-resolution lcd, and we can see how to transmit them digitally.
However, it is likely a bear of a job simluating the light rays needed to create the interference. You'd need to simulate a large subset of all the light beams in the system -- this would make ray tracing seem easy.
So the specialised hardware you need to quickly perform these massive calculations would be completely different from your video card (indeed, are more likely to be called ASCI blue or whatever).
good I agree for the most part. add some tabasco, garnish with white pepper and celery salt (that is the magic ingredient). I dunno about the salted glass -- I'd just stick with the celery salt, but that's a quibble.
The secret to a good bloody mary is lots of ice, and recognising that you want enough vodka to mix well with the (small) can of Tomato juice, not the large glass you pour it in. Too much vodka is a bad thing, suprisingly.
Even better if you can make your own TJ -- fresh squeezed!. That will get rid of ANY ill effects of the previous night.
I'll have to admit that I wasn't aware of the ambush stats (that's a 3 on my list, which I thought was very rare). Nor was I aware of the fact that the dispatcher new the tag before the vehicle was pulled over. Is that why people seem to often get lowered tickets, but very seldomly get away with just a warning (the cop has to give 'em SOMETHING, he pulled them over for speeding, as the dispatcher as logged)?
But anyway, It would be in the officer's interest to inform me of that fact as soon as possible. They've never told me (not that I get pulled over often, but once in a while -- lead footed friends, ya know). Do you know why they don't?
As for the in-dash camera, I rather assumed that after killing the cop, the criminal trashed the tape. I know I would. That speaks against rational criminals too, I guess.
All the same, ta for the discussion, unusually interesting (and rare -- normally people just post and never respond).
Not at all. (guns are not aimed (pun!) at stopping someone from taking a swing at you -- that is not a deadly threat)
I think the question is whether the gun is there as a tool of apprehending the offeder, or protecting the officer. I would argue that it is ok for the former, but counterproductive for the latter.
I would assume that most police fatalities are due to situations that got out of hand, and one of the best ways to assure it will get out of hand is to have two groups of armed bags of testosterone yelling at each other.
A drawn handgun contributes much more to escalation than a camera crew does. A camera has a downright calming effect. As soon as your face is on camera, you have every motivation to cooperate -- you've been IDed (assume for now that most people who would shoot a cop have priors). Whereas if I had just been caught speeding with a couple of kilo of coke in the trunk, it's in my interest to shoot the cop before he calls it in. The camera effectively makes that impossible.
So we have three factors that may get a cop killed 1: the situation escalated out of control (think DeNiro or Tarantino), 2: the incentive to remove the cop's knowledge (and only incidentally, life) before he calls it in, 3: the suspects have nothing to lose and don't like cops.
(ok, there's also number 1.5: the criminal fears for his life -- c.f. the deep south for a black man a few years ago)
number 3 we can do nothing about. The others, it is in the police's interest to replace the gun by constantly streaming surveilance.
As for the big-brother scenario; assume that the most dangerous criminals are those likely to overpower a non-lethal police officer (without the gun to apprehend the officer). These are the suspects most likely to be on file and thus traceable through known addresses and what not.
In this step the gun becomes indispensable, but this is a very different scenario form the cop in the cruiser pulling a car over.
Very possibly, you would use some detective/swat team to apprehend run-from-the-scene criminals. Of course they should be armed, but they should not have anything to do with patrolling and interaction with the public.
Sure thing. 90% -- or even 95% -- of all officers are probably people who really want to help. But those 5% are the ones people notice.
The cops who are obviously out to give you a hard time, pull you over for 10 measly mph over the speed limit on an empty road, shoot unarmed immigrants, and storm the wrong house killing innocent people are more dangerous to the nice cops than any number of Guys On Drugs With Guns.
I'm reminded of greg bear's queen of angels, in which the police officers are unarmed. The idea being that cops carry networked surveillance equipment. So it's acceptable to let a suspect escape -- just i.d. them and bring em in later.
Knowing a cop poses no leathal threat would drastically reduce the amount of violence directed towards them. The elian case in particular highlight exactly the wrong way to approach confrontations.
well.
If the cops got commission on convictions, maybe I could buy the "too much trust in police testimony" argument. But I doubt that a detective is getting any feathers in his cap for busting a $135 misdemeanor. So why would he lie? This would tend to make him a trustworthy witness. I doubt that a police officer's word would be enough for conviction in a murder trial (which might count as a feather), but IANAL.
The accused, tho, has a clear incentive to lie cheat and steal to get let off.
Tho in this case, the testimony sounds rather circumstantial. Even if what he said was completely true, it seems that unless he overheard the conversation, the prosecution would need to show that it wasn't just a coincidence (perhaps by producing phone logs to show that the defendant was speaking to someone in the intersection blocking crowd).
However, the implementor in the articl discusses "pickling" program state, which allows it to be stored to disk, for example. This implies that it is not using a secondary server to manage state, but somehow hoping to store all of it. My comment was basically that this seemed impossible, because some state is stored in kernel space and only accessed by a handle.
But I can see how my comment about DSM was misleading. Sorry about that.
I'll believe it when I see it. There are alot of system specifics that would need to be taken into account; for example, I might have a file-descriptior stored in a variable. That file descriptor is not going to survive a move to another machine.
Likewise, any C-land objects that are pointed to by the state are going to be hard to move. It seems to be the sort of thing you really want to implement at the VM level using Distributed Shared Memory, not at the language level.
But, I expect that anyone smart enough to implement stackless wouldn't go around saying these sorts of things if he didn't know something I obviously don't.
Could you please give a 3 second description of the correction process? I had understood that the argument was that as long as the subpixels were contiguous with the color-carrying full pixel, no fringing would occur. I had also attributed apple-IIs fringing to the fact that the pixels were quite large.
Slashdot Mirror
Actually, I believe that the watermarks are supposed to be robust enough to withstand some signal processing -- optimally any signal processing that retains the song's enjoyability should also retain the watermark, but that is infeasable.
Actually implementing the signal processing manually is kinda perverse, if you ask me, but that would be one way of doing it. It's really just a battle of who can withstand more quality loss: you or the watermark.
Should'a hit preview <\grumble>
A more general solution is to encrypt both the header and body. The to: field would have to have salt added so that you could have several messages addressed to you without this being apparent.
The real difficulty is retrieving only your messages securely. The brute force method of retrieving all headers pending on the server and asking for the bodies of those you understand seems... wrong.
Ah: if the salt were generated in some known way (minutes past 1970, or something) I could send the mail server a set of ids (from when I last read mail or the oldest mail still on the server, whichever is later) that could feasably be me. The server then send me all headers from all matches, and I ask for all that really are me.
Because of salting, it is possible that some I will be sent headers that are not adressed to me; these I'll be unable to decrypt, thus won't ask for the message body.
As far as I can tell, this leaks no information.
Can anyone tell me if mixmaster does something similar?
You know, I don't know that I think this was all too fair; your application should guard against random user input, but needs to trust high level events sent from the OS.
Sending the application malformed event structures and snickering when it crashes seems just a shade less strawmannish than yanking out the power cord and acting suprised when everying dies.
I'd be much more interested in a report focussing on random but legal events.
The article didn't mention this, but does this mean she's losing resolution to gain color, or does the resoltion stay the same?
As a visualisation aid, imagine an LCD with 3 subpixels. Assuming that the pixels didn't shrink, if we went and added a 4th subpixel, we would have to sacrifice resolution when doing so.
isn't that just absolutly unbelievably cool?
*drool* *slobber*
Where were you when I needed you yesterday!?!
Still, mucho obligado for the info.
... and how did you solve the images at the end problem? Running into thatone myself, right now!
(would email instead of post, but...)
I hate LaTeX. I have used for the last five years because it is unparalleled in its ability to create beautiful documents, but anyone who tries to use it for anything but Text-with-two-figures documents needs to budget a good day just to make it come our right. For example, it puts figures at the end of the document at the drop of a hat.
It is a nightmare of arcane commands, semi-undocuments interactions, and just plain wizardry. I don't know if I'd want WYSIWYG, but something a bit more denotational would be nice.
Not that I'm a DTP snob, but if you look at conference proceedings, it is immediately clear who used TeX and who used Word; word just doesn't create an good looking documents.
This is partially due to the great fonts that ship with TeX, but mostly it has to do with incredibly buffed word wrapping heuristics in TeX (I seem to recall this being an NP complete problem, or something), while I think Word just uses the greedy algorithm.
wasn't the dragon book set in TROFF or something equally vile?
Drats!
I've been looking for the successor to LaTeX for a while now; some application that produces equally beautiful layouts, but perhaps a bit easier to make do the stuff where you want the brace there and not thereish.
I thought framemaker might have been the ticket, but apparently not.
frankly, who cares what the individual formats are? Really. That is completly besides the point.
The important thing is that they try to make a semantic interpretation of the input image and apply differing approaches depending on the content. My above post answered the question above as to why they are comparing themselves to pdf; they focus on compressing exactly one kind of information, so they shouldn't be compared to standard image compression.
So I guess I don't agree about that being redundant. whereas the fact that they use wavelets... well, that's nice, but hardly germane.
http://slashdot.org/article.pl?sid=older/980628231 4218&mode=nested
That was almost 2.5 years ago. The reason they compare against pdf is that the target application seems to be text; compress the black and white text with one-bit RLE, and the background with JPG sort of deal.
Like so many other factors, speed is one that does matter if in the extreme, but once it's good enough, it has very little importance. Size is arguably more important, because every byte saved is saved every time you use the file, while time saved is only saved during compression, which is often batched.
So for time, order of magnitude seems to be the differentiator, while size has a linear importance.
The problem is compressing them. The ideas behind decompressing fractals are easy; use the self similarity inherent in pictures (a tree looks much like another tree, so build a picture of a forest by layering trees and then correcting the errors).
But figuring this out ammounts to exhaustive search. Apparently IFS had decent heuristics that got decent compression in only a few minutes. I think this is what was licenced, and that the file-format was open? This was a while ago, so I'm filling in the gaps in memory by guessing.
It is still unclear whether it is feasable to compute holograms in real time. It might be that this system is limited to simulcasting live content only -- ie it may only be able to record and replay, not create content from scratch.
The problem is that holograms are photographs of the interference patterns of two in-phase beams reflecting off an object. You project by illumiating the developed film with similar light.
Now, replace the film with a ccd and the developed film with a high-resolution lcd, and we can see how to transmit them digitally.
However, it is likely a bear of a job simluating the light rays needed to create the interference. You'd need to simulate a large subset of all the light beams in the system -- this would make ray tracing seem easy.
So the specialised hardware you need to quickly perform these massive calculations would be completely different from your video card (indeed, are more likely to be called ASCI blue or whatever).
good I agree for the most part. add some tabasco, garnish with white pepper and celery salt (that is the magic ingredient). I dunno about the salted glass -- I'd just stick with the celery salt, but that's a quibble.
The secret to a good bloody mary is lots of ice, and recognising that you want enough vodka to mix well with the (small) can of Tomato juice, not the large glass you pour it in. Too much vodka is a bad thing, suprisingly.
Even better if you can make your own TJ -- fresh squeezed!. That will get rid of ANY ill effects of the previous night.
Ok,
I'll have to admit that I wasn't aware of the ambush stats (that's a 3 on my list, which I thought was very rare). Nor was I aware of the fact that the dispatcher new the tag before the vehicle was pulled over. Is that why people seem to often get lowered tickets, but very seldomly get away with just a warning (the cop has to give 'em SOMETHING, he pulled them over for speeding, as the dispatcher as logged)?
But anyway, It would be in the officer's interest to inform me of that fact as soon as possible. They've never told me (not that I get pulled over often, but once in a while -- lead footed friends, ya know). Do you know why they don't?
As for the in-dash camera, I rather assumed that after killing the cop, the criminal trashed the tape. I know I would. That speaks against rational criminals too, I guess.
All the same, ta for the discussion, unusually interesting (and rare -- normally people just post and never respond).
Not at all. (guns are not aimed (pun!) at stopping someone from taking a swing at you -- that is not a deadly threat)
I think the question is whether the gun is there as a tool of apprehending the offeder, or protecting the officer. I would argue that it is ok for the former, but counterproductive for the latter.
I would assume that most police fatalities are due to situations that got out of hand, and one of the best ways to assure it will get out of hand is to have two groups of armed bags of testosterone yelling at each other.
A drawn handgun contributes much more to escalation than a camera crew does. A camera has a downright calming effect. As soon as your face is on camera, you have every motivation to cooperate -- you've been IDed (assume for now that most people who would shoot a cop have priors). Whereas if I had just been caught speeding with a couple of kilo of coke in the trunk, it's in my interest to shoot the cop before he calls it in. The camera effectively makes that impossible.
So we have three factors that may get a cop killed 1: the situation escalated out of control (think DeNiro or Tarantino), 2: the incentive to remove the cop's knowledge (and only incidentally, life) before he calls it in, 3: the suspects have nothing to lose and don't like cops.
(ok, there's also number 1.5: the criminal fears for his life -- c.f. the deep south for a black man a few years ago)
number 3 we can do nothing about. The others, it is in the police's interest to replace the gun by constantly streaming surveilance.
As for the big-brother scenario; assume that the most dangerous criminals are those likely to overpower a non-lethal police officer (without the gun to apprehend the officer). These are the suspects most likely to be on file and thus traceable through known addresses and what not.
In this step the gun becomes indispensable, but this is a very different scenario form the cop in the cruiser pulling a car over.
Very possibly, you would use some detective/swat team to apprehend run-from-the-scene criminals. Of course they should be armed, but they should not have anything to do with patrolling and interaction with the public.
Sure thing. 90% -- or even 95% -- of all officers are probably people who really want to help. But those 5% are the ones people notice.
The cops who are obviously out to give you a hard time, pull you over for 10 measly mph over the speed limit on an empty road, shoot unarmed immigrants, and storm the wrong house killing innocent people are more dangerous to the nice cops than any number of Guys On Drugs With Guns.
I'm reminded of greg bear's queen of angels, in which the police officers are unarmed. The idea being that cops carry networked surveillance equipment. So it's acceptable to let a suspect escape -- just i.d. them and bring em in later.
Knowing a cop poses no leathal threat would drastically reduce the amount of violence directed towards them. The elian case in particular highlight exactly the wrong way to approach confrontations.
well.
If the cops got commission on convictions, maybe I could buy the "too much trust in police testimony" argument. But I doubt that a detective is getting any feathers in his cap for busting a $135 misdemeanor. So why would he lie? This would tend to make him a trustworthy witness. I doubt that a police officer's word would be enough for conviction in a murder trial (which might count as a feather), but IANAL.
The accused, tho, has a clear incentive to lie cheat and steal to get let off.
Tho in this case, the testimony sounds rather circumstantial. Even if what he said was completely true, it seems that unless he overheard the conversation, the prosecution would need to show that it wasn't just a coincidence (perhaps by producing phone logs to show that the defendant was speaking to someone in the intersection blocking crowd).
... wiping tears from eyes.
That was one of the funniest things I've read in a long time. Silly puddy 'tat. hihi.
Bravo.
Ok, that's distributed processing.
However, the implementor in the articl discusses "pickling" program state, which allows it to be stored to disk, for example. This implies that it is not using a secondary server to manage state, but somehow hoping to store all of it. My comment was basically that this seemed impossible, because some state is stored in kernel space and only accessed by a handle.
But I can see how my comment about DSM was misleading. Sorry about that.
I'll believe it when I see it. There are alot of system specifics that would need to be taken into account; for example, I might have a file-descriptior stored in a variable. That file descriptor is not going to survive a move to another machine.
Likewise, any C-land objects that are pointed to by the state are going to be hard to move. It seems to be the sort of thing you really want to implement at the VM level using Distributed Shared Memory, not at the language level.
But, I expect that anyone smart enough to implement stackless wouldn't go around saying these sorts of things if he didn't know something I obviously don't.
Could you please give a 3 second description of the correction process? I had understood that the argument was that as long as the subpixels were contiguous with the color-carrying full pixel, no fringing would occur. I had also attributed apple-IIs fringing to the fact that the pixels were quite large.