Mathematically anything is feasible, however if you place a real-world constraint such as it requiring an implementation then that greatly narrows the field down.
Furthermore one of the judging factors is the speed and portability of the algorithm upon a wide variety of commonly used platforms - it doesn't make sense to come up with a super-cool hash function that only works well on say an x86.
The short of it is that people make mistakes from time to time, and it is true that perfection is an important factor in crypto-code so the submitters should have been more thorough, From the article it seems that the overwhelming majority of them were - which is a positive.
Actually you're wrong, conceptually its a similar process but the method is very different. The video processing done in football games requires 4+ cameras to be position around the arena, the camera locations are known exactly, furthermore the cameras are all high frame rate, hi resolution.
From the article it seems to suggest one can take some arbitrary video that has non-degenerative camera motion and embed images/video into it, doing this requires knowing the optical flow of all the moving objects in the scene, the camera motion and positions (to scale) from frame to frame - these are very difficult/different things.
In conclusion, going from deliberate views to arbitrary views is somewhat complex, so don't pooh-pooh the technology straight-away just because you don't understand it or have seen something similar before.
1. Initially from a computer forensics pov, it would be trivial to detect if a video has been altered, however i think with further improvements in the embedding technology where the actual advert piece is better rendered to take into account surrounding lighting conditions it might become more difficult, however not impossible to detect intentional modifications
2. Just as with current browser ad-blockers, the these ads can also be blocked out, in-fact the technology proves that complex camera conditions such as rotational pan(the heros examples) and occlusion (fat chick on couch) can be easily determined, so creating a blank out mask of a texture that is close to the surrounding surface would also be quiet doable, perhaps not real-time at the moment, but doable nonetheless, and most definitely live sometime in the future perhaps.
Ask yourself this, do you really want to be a programmer?
Many people think its the "it thing" in IT, and that being a programmer and eventually an architect is the pinnacle of their career.
The truth is most people will not make good programmers, they wont end-up enjoying what they do, and something as mentally straining and intensive as programming requires you to continually have a good/positive mindset to be productive and to churn out top notch solutions.
I suppose this is the same for all types of careers - is it really for you?
That said most people will undoubtedly tell you to do some open source, start some of your own projects. I have another suggestion, take your QA role, and ask yourself this: what tasks that you're doing now can be further automated, is there an area where something can be solved with a program?
If you can find that area(s), and build the program(s) to solve those problem(s), then you're probably a good fit for programming, if you're the kind of person that needs someone to tell them any one of those things, then perhaps its not for you...
The 2nd explanation for projection of 3D objects onto a plane so as to allow the 2d lizards to perceive the objects is simply ridiculous as it requires them to have an external view point defeating the purpose altogether. The 1st example was ok, but its nearly 100 years old, something new/unique/novel would have been more interesting to watch, also the presentation drags on for too long, it should be sped up.
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.
You are obviously just regurgitating MS marketing without thinking critically.
Filing for a patent does not mean you have a patent, it could take years of iterations etc to get a definite patent on something and even then people may still contest it. My suggestion is that if you're inclined to stick to your morals (which btw I don't totally agree with) , to go with the flow but sort of keep the filing so general and vague that any monkey could come along and contest it. At the end of the day you're not a patent lawyer, you can't be accused of not doing your job properly.
if you haven't heard of loopy-belief propagation you're probably not aware of the state of the art in LDPCs, it has progressed a long way since Gallager's time rediscovered/reinvented a few times etc...
btw reaching channel capacity requires use of sparse matrices that have some very demanding properties. I believe the current direction at least for pure erasure channels (wifi, udp...) are Rateless codes or in other words Digital Fountains of which Tornado and LT style codes exist.
It is possible for a well designed h/w decoder to detect the loss of laser tracking and from there signal the decoder that the current bit or byte read-in is an erasure (ie: it is erroneous, the position is known but the amount of error, meaning the difference from what the decoder gets and what it really should be is unknown) - this is known as side-channel information.
In these cases the decoder is capable of decoding mixtures of errors and erasures. In an "all erasure" decoding scenario and decoder should be able to decode twice as many erasures as it can decode errors.
The relationship is 2E + S = F, where E is the number of errors, S is the number of erasures and F is the number of FEC symbols.
Your comment is incorrect, RS codes are a subset of BCH codes. In fact BCH codes are a general definition of a class of algebraic codes nothing more. your comment about one being better than the other for a specific purpose is wrong.
Think of BCH codes as "vehicle" and RS codes as "The Bugatti Veyron" that is the relationship.
RS codes are a subset of BCH codes, if anything is far superior it would be RS codes as they are more generalized and have better specific decoding techniques and can be both systematic and linear.
Again as mentioned before LDPCs are not useful in these situations they are only useful in overcoming erasures within data communications.
LDPC based codes only work for pure erasure channels and do NOT work for static error channels. How does one perform loopy-belief propagation when the error probability distribution of the medium (in this case the disk) can not be modeled correctly?
Ok, lets assume its a 128-bit hash. For a 1GB file how many combinations of 1GB will produce the same hash? the problem here is that at some point the hash/ECC may fail. it always does, its not a matter of if but when.
btw I'm sure ZFS doesn't do the checksums over 1GB blocks perhaps some smaller sized block, regardless the same logic still applies.
Fine we are all dumb, now tell me what happens when the errors on the disk are spread over all the files and the par2 equally to the extent at which the drive wont even send data back - what does one do then? how do you tell the drive about the par fec?
its best to spread data equally over multiple devices as if one device was to totally fail you could still get something back (reconstruct) from the other devices.
The speed of encoding and decoding directly relates to the type of RS and the amount of FEC required. Generally speaking erasure style RS can go as low as O(nlogn) (essentially inverting and solving for a vandermonde or Cauchy style matrix) A more general code that can correct errors (the difference between an error and an erasure is that in the latter you know the location of the error but not its magnitude) may require a more complex process, something like Syndrome-Berlekamp Massey-Forney which is about O(n^2).
It is possible to buy specialised h/w (or even GPUs) to perform the encoding steps (getting roughly 100+MB/s) and most software encoders can do about 50-60+Mb/ for RS(255,223) - YMMV
My understanding is that it is possible to drill a few holes no larger than 2mm in diameter equally spread over the surface of an "audio cd" and with the help of h/w RS erasure decoding, channel interleaving and channel prediction (eg:probabilistically reconstruct missing right channel from known left channel) one can produce a near perfect reconstruction - that's what usually happens to overcome scratches and other kinds of simple surface defects.
checksums really only help in detecting errors. Once you've found errors, if you have an exact redundancy somewhere else you can repair the errors. What reed-solomon codes do is provide the error detecting ability but also the error correcting ability whilst at the same time reducing the amount of redundancy required to a near theoretical minimum.
btw checksums have limits on how many errors they can detect within lets say a file or other kind of block of data. A simple rule of thumb (though not exact) is that 16 and 32 bit checksums can detect upto 16,32 bit errors respectively anymore and the chance of not detecting every bit error goes up, it could even result in not finding any errors at all.
It really depends where you store the FEC, some techniques store the fec separately others concatenate and others interleave the FEC. Each method has its own advantages and disadvantages.
Slashdot Mirror
Mathematically anything is feasible, however if you place a real-world constraint such as it requiring an implementation then that greatly narrows the field down.
Furthermore one of the judging factors is the speed and portability of the algorithm upon a wide variety of commonly used platforms - it doesn't make sense to come up with a super-cool hash function that only works well on say an x86.
The short of it is that people make mistakes from time to time, and it is true that perfection is an important factor in crypto-code so the submitters should have been more thorough, From the article it seems that the overwhelming majority of them were - which is a positive.
Actually you're wrong, conceptually its a similar process but the method is very different. The video processing done in football games requires 4+ cameras to be position around the arena, the camera locations are known exactly, furthermore the cameras are all high frame rate, hi resolution.
From the article it seems to suggest one can take some arbitrary video that has non-degenerative camera motion and embed images/video into it, doing this requires knowing the optical flow of all the moving objects in the scene, the camera motion and positions (to scale) from frame to frame - these are very difficult/different things.
In conclusion, going from deliberate views to arbitrary views is somewhat complex, so don't pooh-pooh the technology straight-away just because you don't understand it or have seen something similar before.
1. Initially from a computer forensics pov, it would be trivial to detect if a video has been altered, however i think with further improvements in the embedding technology where the actual advert piece is better rendered to take into account surrounding lighting conditions it might become more difficult, however not impossible to detect intentional modifications
2. Just as with current browser ad-blockers, the these ads can also be blocked out, in-fact the technology proves that complex camera conditions such as rotational pan(the heros examples) and occlusion (fat chick on couch) can be easily determined, so creating a blank out mask of a texture that is close to the surrounding surface would also be quiet doable, perhaps not real-time at the moment, but doable nonetheless, and most definitely live sometime in the future perhaps.
Ask yourself this, do you really want to be a programmer?
Many people think its the "it thing" in IT, and that being a programmer and eventually an architect is the pinnacle of their career.
The truth is most people will not make good programmers, they wont end-up enjoying what they do, and something as mentally straining and intensive as programming requires you to continually have a good/positive mindset to be productive and to churn out top notch solutions.
I suppose this is the same for all types of careers - is it really for you?
That said most people will undoubtedly tell you to do some open source, start some of your own projects.
I have another suggestion, take your QA role, and ask yourself this: what tasks that you're doing now can be further automated, is there an area where something can be solved with a program?
If you can find that area(s), and build the program(s) to solve those problem(s), then you're probably a good fit for programming, if you're the kind of person that needs someone to tell them any one of those things, then perhaps its not for you...
The 2nd explanation for projection of 3D objects onto a plane so as to allow the 2d lizards to perceive the objects is simply ridiculous as it requires them to have an external view point defeating the purpose altogether. The 1st example was ok, but its nearly 100 years old, something new/unique/novel would have been more interesting to watch, also the presentation drags on for too long, it should be sped up.
Put-Up-Or-Shutup, Provide an example if you can.
Put-Up-Or-Shutup - Provide an example if you can.
You are ABSOLUTELY wrong! C# by its very nature can not be as fast as C. There is no example you can provide where the running time of an optimized C version will be as fast or slower than the most optimized C# version. Even with JIT and supposed optimal native code generation for tight-loops there is no way you can get the same performance.
You are obviously just regurgitating MS marketing without thinking critically.
Filing for a patent does not mean you have a patent, it could take years of iterations etc to get a definite patent on something and even then people may still contest it. My suggestion is that if you're inclined to stick to your morals (which btw I don't totally agree with) , to go with the flow but sort of keep the filing so general and vague that any monkey could come along and contest it. At the end of the day you're not a patent lawyer, you can't be accused of not doing your job properly.
Also don't bite the hand that pays your salary.
if you haven't heard of loopy-belief propagation you're probably not aware of the state of the art in LDPCs, it has progressed a long way since Gallager's time rediscovered/reinvented a few times etc...
btw reaching channel capacity requires use of sparse matrices that have some very demanding properties. I believe the current direction at least for pure erasure channels (wifi, udp...) are Rateless codes or in other words Digital Fountains of which Tornado and LT style codes exist.
It is possible for a well designed h/w decoder to detect the loss of laser tracking and from there signal the decoder that the current bit or byte read-in is an erasure (ie: it is erroneous, the position is known but the amount of error, meaning the difference from what the decoder gets and what it really should be is unknown) - this is known as side-channel information.
In these cases the decoder is capable of decoding mixtures of errors and erasures. In an "all erasure" decoding scenario and decoder should be able to decode twice as many erasures as it can decode errors.
The relationship is 2E + S = F, where E is the number of errors, S is the number of erasures and F is the number of FEC symbols.
Your comment is incorrect, RS codes are a subset of BCH codes. In fact BCH codes are a general definition of a class of algebraic codes nothing more. your comment about one being better than the other for a specific purpose is wrong.
Think of BCH codes as "vehicle" and RS codes as "The Bugatti Veyron" that is the relationship.
pretty much all 2D barcodes use RS codes as well. These include, QRcode, PostBar, MaxiCode, DataMatrix etc...
RS codes are a subset of BCH codes, if anything is far superior it would be RS codes as they are more generalized and have better specific decoding techniques and can be both systematic and linear.
Again as mentioned before LDPCs are not useful in these situations they are only useful in overcoming erasures within data communications.
LDPC based codes only work for pure erasure channels and do NOT work for static error channels. How does one perform loopy-belief propagation when the error probability distribution of the medium (in this case the disk) can not be modeled correctly?
heard of the birthday paradox? don't need that much memory to come up with a collision, in fact most MD hash attacks are based on that principle.
That is correct, there is always the possibility that the data can still be viable after a large number of bit flips, and that a problem nonetheless
Ok, lets assume its a 128-bit hash. For a 1GB file how many combinations of 1GB will produce the same hash? the problem here is that at some point the hash/ECC may fail. it always does, its not a matter of if but when.
btw I'm sure ZFS doesn't do the checksums over 1GB blocks perhaps some smaller sized block, regardless the same logic still applies.
Fine we are all dumb, now tell me what happens when the errors on the disk are spread over all the files and the par2 equally to the extent at which the drive wont even send data back - what does one do then? how do you tell the drive about the par fec?
its best to spread data equally over multiple devices as if one device was to totally fail you could still get something back (reconstruct) from the other devices.
I believe the underlying code used in RAR for the recovery record is in fact an RS(255,249) codes
The speed of encoding and decoding directly relates to the type of RS and the amount of FEC required. Generally speaking erasure style RS can go as low as O(nlogn) (essentially inverting and solving for a vandermonde or Cauchy style matrix) A more general code that can correct errors (the difference between an error and an erasure is that in the latter you know the location of the error but not its magnitude) may require a more complex process, something like Syndrome-Berlekamp Massey-Forney which is about O(n^2).
It is possible to buy specialised h/w (or even GPUs) to perform the encoding steps (getting roughly 100+MB/s) and most software encoders can do about 50-60+Mb/ for RS(255,223) - YMMV
My understanding is that it is possible to drill a few holes no larger than 2mm in diameter equally spread over the surface of an "audio cd" and with the help of h/w RS erasure decoding, channel interleaving and channel prediction (eg:probabilistically reconstruct missing right channel from known left channel) one can produce a near perfect reconstruction - that's what usually happens to overcome scratches and other kinds of simple surface defects.
checksums really only help in detecting errors. Once you've found errors, if you have an exact redundancy somewhere else you can repair the errors. What reed-solomon codes do is provide the error detecting ability but also the error correcting ability whilst at the same time reducing the amount of redundancy required to a near theoretical minimum.
btw checksums have limits on how many errors they can detect within lets say a file or other kind of block of data. A simple rule of thumb (though not exact) is that 16 and 32 bit checksums can detect upto 16,32 bit errors respectively anymore and the chance of not detecting every bit error goes up, it could even result in not finding any errors at all.
It really depends where you store the FEC, some techniques store the fec separately others concatenate and others interleave the FEC. Each method has its own advantages and disadvantages.
slow news day anyone?