posted on Jun, 16 2008 @ 01:27 AM
Hmmm, well I'll first admit that I did not read the entire thread, and thought it best not to, so that I would share my opinion about the OP without
being influenced by all the previous responses.
Now I work with scanned images ALOT in my line of work (involves heavy interaction with document management software), and I can tell you from first
impression what you're seeing with those artifacts is created by a compression or quantization pattern that is being run in low quality mode.
Basically what these quantization matrices do is break the image across a block, and then break that block into many other blocks attempting to
compress the image and use "repeated blocks" to save space by referencing 1 block many times across an image. If you're feeling adventurous,
Microsoft has a nice PDF on how this works with ONE type of vector based quantization pattern here:
(Please note, this PDF is from one of MS's research employees)
So anyway, the point of that whole mess is that the type of artifacting you're seeing is exactly as planned. The user wanted to post that image on
the web and probably had to meet size constraints. Because of that, they chose a lesser quality algorithm to make the file smaller. Smaller file
size = larger blocks of sample size, so there's less "samples" of the original image. When those blocks have a piece of a letter in them, they
tend to throw the color value for the entire block off. Then we see this as mis-colored "boxes" around the print. It's a real PITA when you're
trying to reproduce a document accurately and you're dealing with such a loose standard like JPEG, you see this all the time around borders of
objects with a background near them that's not one solid color.
This should prove that just because we see it in the document, that isn't 100% proof that it was modified. Anytime that document is saved as a JPEG
in a lower quality, those artifacts are bound to show up, and with each progressive copy and re-sampling, the problem becomes more pronounced and