31–40 of 72 posts
Pretend you care, blame the users, and don't take any action. Hey, what could be wrong with that?
Earlier quoted context omitted.
By "lossy" you mean "17" may look like a crappier "17" with reasonable confidence, but will never, ever , become "21" at any compression setting, then I don't mind lossy. That's not asking for too much, is it?
But the scanner isn't starting off with "17" (as in two ascii characters) it is starting off with a bit mapped image that your brain happens to interpret as the number 17. It is too much to ask that a lossy image compression algorithm never result in a compressed bitmap that your brain interprets exactly as the original. Having various compression/quality options allows you to pick the tradeoff (file size/resulting q…
Earlier quoted context omitted.
By "lossy" you mean "17" may look like a crappier "17" with reasonable confidence, but will never, ever , become "21" at any compression setting, then I don't mind lossy. That's not asking for too much, is it?
But the scanner isn't starting off with "17" (as in two ascii characters) it is starting off with a bit mapped image that your brain happens to interpret as the number 17. It is too much to ask that a lossy image compression algorithm never result in a compressed bitmap that your brain interprets exactly as the original. Having various compression/quality options allows you to pick the tradeoff (file size/resulting q…
According to Adam (https://news.ycombinator.com/item?id=6156418) this is a known problem that Xerox, who call themselves document people for crying out loud, should have known and compensated for.
"We do not normally see a character substitution issue with the factory default settings..." It shouldn't be seen with any setting. Nothing you can do to the device (short of involving a hammer) should change the content in any way. Compress, resize, zoom, do whatever, but it simply must not change the content at any time at any resolution/quality. I'm just flabbergasted that such a compression scheme was ever implem…
So you only want non lossy compression as an option?
I can just see a legal loophole now for anyone using these devices, for example "the electronic document was modified by a Xerox and we don't have the original, those numbers were not what we signed, contract void".
No matter the case of an optional setting or the size of the font involved, this can have major consequences for people who trust the device to be an accurate representation in all cases, of what they put into it.
Earlier quoted context omitted.
By "lossy" you mean "17" may look like a crappier "17" with reasonable confidence, but will never, ever , become "21" at any compression setting, then I don't mind lossy. That's not asking for too much, is it?
But the scanner isn't starting off with "17" (as in two ascii characters) it is starting off with a bit mapped image that your brain happens to interpret as the number 17. It is too much to ask that a lossy image compression algorithm never result in a compressed bitmap that your brain interprets exactly as the original. Having various compression/quality options allows you to pick the tradeoff (file size/resulting q…
I don't expect the scanner to have any semantic awareness of the document content, so when I hear "lossy compression", my expectation is "image may become illegible", and not "image may remain legible, but become inaccurate".
Earlier quoted context omitted.
There's no OCR involved here. None. All it's doing is recognizing "similar" patches of the image and coalescing them, which is what it's supposed to do, according to the standard. Yes, it's too aggressive.
The stated goal of JBIG2 is to recognize 'characters' on the fly and compress them together. It's not traditional OCR but I wouldn't take such a hard line.
A major and highly pertinent difference is that if this OCR-ish procedure incorrectly classifies two identical letters as being different, accuracy is not affected, and the only consequence is a larger file. With normal OCR, seeing two As and saying they're different would be an error, but in this case, it's fine.
What this means is that, while regular OCR is inherently error-prone, this compression procedure can be fully tuned anywhere between no errors and nothing but errors, with file size being the tradeoff.
The ability to run this algorithm in a way that produces no errors may be enough to disqualify it as "OCR", depending on your point of view. In any case, it certainly changes things from "that's just how it is" to "this is a royal cock-up on Xerox's part".
This is an absolutely hilarious technical response to a real world customer issue. The customer does not care one iota that their photocopier uses one compression algorithm over another. And the fact there is not one mention of the word 'copy' in that entire post, is very telling of the technical disconnect exhibited here. The 'Xerox devices' in question are completely broken from a usability perspective.