Live data from Hacker News

Xerox scanners and photocopiers randomly alter numbers in scanned documents

dkriesel.com

101–110 of 118 posts

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#101
post #41
post #34

Earlier quoted context omitted.

Indeed, I keep a copy of my lab results for the last N years because they sometimes get lost, once through no real fault of the doctor ( http://en.wikipedia.org/wiki/2011_Joplin_tornado ). Grrr, I'm now going to have to view every lab report that's not an original with suspicion, and make sure my doctors aren't making recommendations due to screwed up copies. Lossy compression is not an acceptable default for a gener…

This isn't even lossy compression - it's misleading compression

It's one of the worst examples of "seamless design"[1] I have ever seen.

[1] http://jim-mcbeath.blogspot.co.uk/2008/11/seamful-design.htm...

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#104
post #84
post #78

Earlier quoted context omitted.

Errr, I didn't communicate clearly. What I meant to say was that CCITT Group IV gave acceptable sizes for early-'90s computing power, CPU and disk, and something at or better than its level of lossless compression today should be even more acceptable. And in light of this screwup, I suspect we'd agree that Xerox would have been better off to use lossless (well, after the scanning, as you point out, but then again no…

Of course they would have been better off with T.6, as Group 4 at least did not modify the image content. However especially with TIFF there are/were countless implementations of viewers, components, libraries and every single one of them had their own habits. Some would not regard endianess, some would assume payload endianess is the same as the TIFF, some did respect the Tag for byte order specific to the image. Wh…

Not that deeply, I only did B&W document imaging, and I think the last time I worked on TIFF headers and tags was in 1992, so it was almost certainly the 5.0 standard, 6.0 came out in that year.

And yeah, it was a mess; we mostly did the best we could and made sure the ones we generated worked for our customer's reader(s). Although I don't remember any big problems with people reading the ones we produced.

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#105
post #93
post #4

Truly surprising. I would never have imagined this to be in the domain of possible problems one would expect to encounter scanning or photocopying a document. It is like taking a picture of my wife with a digital camera and her face being replaced with that of some other person.

With personal video recording (a la Google Glass and friends) it won't be long before we're subjected to this sort of thing. It's amazing how close we're getting to Ghost in the Shell and I'm sure it won't be long when live video feeds can be hacked in real time to show something contrary to what's actually happening.

https://vimeo.com/29279198 real time face substitution

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#106
Just an update: the author states on Twitter that he already had notified Xerox a week ago [1]. Apparently, Xerox has only now contacted him because they thought it was a joke [2] ...

[1] https://twitter.com/davidkriesel/status/364345036407709697

[2] https://twitter.com/davidkriesel/status/364329334300880896

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#107
post #100
post #14

This class of error is called (by me, at least) a "contoot" because, long ago, when I was writing the JBIG2 compressor for Google Books PDFs, the first example was on the contents page of book. The title, "Contents", was set in very heavy type which happened to be an unexpected edge case in the classifier and it matched the "o" with the "e" and "n" and output "Contoots". The classifier was adjusted and these errors m…

It just occurred to me... The title, "Contents", was set in very heavy type which happened to be an unexpected edge case in the classifier and it matched the "o" with the "e" and "n" and output "Contoots". Wouldn't it be a good idea to perform OCR - using a language model, the works - before you start classifying the JBIG2 symbols? That way, you'd have additional contextual information to say "Aha, 'contoots' is prob…

Language model would give you the opposite problem - eg you scan a print of _this_ page containing the word "contoots" which your language model corrects to "contents"...

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#108

Earlier quoted context omitted.

Normal people seem to get that it's considerably harder to ship a barn than a letter, and that if you want to move a barn you use a specialty service rather than the post office. The size and number of files are and should be totally relevant even to "normal" people. When someone asks for something in e-mail, it's perfectly reasonable to say "no, it's much too big" and expect them to understand.

I think we can all agree that e-mails should have finite size - it's not a very good protocol for transferring multi-gigabyte files, for sure! Where we would disagree is where that limit should be drawn. I've seen systems in this day and age that fail in the face of e-mails as small as 5 megabytes (e.g. Yahoo Popgate) which IMHO is far too low - but evidently some sysadmins disagree with me!

Email size is a technical issue that shouldn't be limiting (or even visible) to the end user. If an end user wants to send a multigigabyte file to another user's email address - why not? The email client could launch a background upload process and email a link to get that file by, say, bittorrent... Some protocol extensions and software support would be needed, but that can be done and, as users need it, probabpy should be done.

Re: Xerox scanners and photocopiers randomly alter numbers in scanned documents

#110
post #100
post #14

This class of error is called (by me, at least) a "contoot" because, long ago, when I was writing the JBIG2 compressor for Google Books PDFs, the first example was on the contents page of book. The title, "Contents", was set in very heavy type which happened to be an unexpected edge case in the classifier and it matched the "o" with the "e" and "n" and output "Contoots". The classifier was adjusted and these errors m…

It just occurred to me... The title, "Contents", was set in very heavy type which happened to be an unexpected edge case in the classifier and it matched the "o" with the "e" and "n" and output "Contoots". Wouldn't it be a good idea to perform OCR - using a language model, the works - before you start classifying the JBIG2 symbols? That way, you'd have additional contextual information to say "Aha, 'contoots' is prob…

JBIG2 [91] suggests using OCR to verify that you didn't mangle anything. If the compressed result has a lower success rate in matching words than the original, then you did something wrong.

[91] http://jbig2.com/

Post reply on HN