Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xerox responds to the recent character substitution issue

realbusinessatxerox.blogs.xerox.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Xerox responds to the recent character substitution issue

#61

Post by enraged_camel »

jessedhillon wrote: post #60
Gormo wrote: post #38

Earlier quoted context omitted.

It seems a bit too coincidental that images to which human beings assign semantic value are being transformed into images to which human beings assign different semantic value. 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".

This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. But before you insinuate that the scanner has semantic awareness of the document and is altering that meaning in a less-than-coincidental way, I would hope that you could have a cursory look at how such compression works. The issue only involves small letters, because the compression scheme breaks up the image into pat…

>>This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works.

As opposed to what, ImageCompression News where you can expect everyone to know it?

Re: Xerox responds to the recent character substitution issue

#62

Post by Gormo »

jessedhillon wrote: post #60
Gormo wrote: post #38

Earlier quoted context omitted.

It seems a bit too coincidental that images to which human beings assign semantic value are being transformed into images to which human beings assign different semantic value. 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".

This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. But before you insinuate that the scanner has semantic awareness of the document and is altering that meaning in a less-than-coincidental way, I would hope that you could have a cursory look at how such compression works. The issue only involves small letters, because the compression scheme breaks up the image into pat…

I'm aware - I'm merely responding to the previous commenter's point about how the compression algorithm is "starting off with a bit mapped image that your brain happens to interpret as the number 17", and pointing out that if this were the case, the likely outcome should be a fuzzier-looking "17" and not a "21".

Clearly, the compression algorithm is designed around human perception (i.e. looking for visually-similar segments to, I assume, tokenize), and therefore does relate to the actual semantics of the document, albeit in a coarse and mechanical way. It did know enough to replace character glyphs with other character glyphs, but didn't know enough to choose the right ones.

My point is that it's not coincidental at all - this algorithm is obviously in a sort of "uncanny valley" in its attempt to model human visual perception.

Re: Xerox responds to the recent character substitution issue

#63

Post by cabalamat »

jessedhillon wrote: post #60
Gormo wrote: post #38

Earlier quoted context omitted.

It seems a bit too coincidental that images to which human beings assign semantic value are being transformed into images to which human beings assign different semantic value. 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".

This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. But before you insinuate that the scanner has semantic awareness of the document and is altering that meaning in a less-than-coincidental way, I would hope that you could have a cursory look at how such compression works. The issue only involves small letters, because the compression scheme breaks up the image into pat…

> The issue only involves small letters, because the compression scheme breaks up the image into patches and then tries to identify visually similar blocks and reuse them. Certain settings can allow for small blocks of text to be deemed identical, within a threshold, and thus replaced. That's all. Coincidence, not semantic awareness.

Copiers very commonly copy printed material. This sort of algorithm makes it likely that sometimes one character will be replaced by another, so it is a bad algorithm for the job.

Xerox should have known better.

Re: Xerox responds to the recent character substitution issue

#64

Post by dandelany »

klodolph wrote: post #7
wtallis wrote: post #4

So they claim that the fine print warns about character substitution. But they still are willing to label the option with that problem "normal quality" and suggest using "high quality" to get strictly image compression applied with no OCR. They don't seem to understand that a photocopier should in its normal operating mode never do post-processing that creates such surprising and misleading artifacts - better illegib…

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.

Whether or not we're calling it OCR has zero bearing on the point of this comment. I can't believe this entire thread is hackers bikeshedding about whether it's OCR or not - it's like the definition of pedantism.

Re: Xerox responds to the recent character substitution issue

#65

Post by tbirdz »

enraged_camel wrote: post #61
jessedhillon wrote: post #60

Earlier quoted context omitted.

This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. But before you insinuate that the scanner has semantic awareness of the document and is altering that meaning in a less-than-coincidental way, I would hope that you could have a cursory look at how such compression works. The issue only involves small letters, because the compression scheme breaks up the image into pat…

>>This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. As opposed to what, ImageCompression News where you can expect everyone to know it?

Or maybe comp.compression

Re: Xerox responds to the recent character substitution issue

#67

Post by gpvos »

smtddr wrote: post #49
gpvos wrote: post #21

Earlier quoted context omitted.

You are correct. The default setting is "high" or "higher"; I don't know which. The setting that may copy blocks of characters around is the lowest setting and is called "normal", and comes with some small print on the screen that actually warns you for the character substitution.

Oh wow, why didn't anyone mention this before? Or have I been missing it? I'm not being sarcastic, the fact that the warning about char-substitution is displayed to the user like that changes this whole story. I still think it a bad idea to even have that setting at all and Xerox should just remove it from future devices - but the user was warned, in as much as the average user ever reads warnings on computer screens…

Well, the person who changed the setting was warned. The warning does not appear on the main copying/scanning screen. And calling such a setting "normal" verges on criminal.

And even the support person didn't know about the consequences of the setting.

Also, it seems that the setting was also used when copying, not just when scanning (still seeking confirmation on that one), which would be quite useless.

Re: Xerox responds to the recent character substitution issue

#68

Post by rwallace »

dman wrote: post #19
eksith wrote: post #13

"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?

Of course! Lossy compression is tolerable for cat videos on YouTube where it doesn't matter if a few details are wrong. It is absolutely not tolerable for storage of important documents. This is something that should go without saying.

Looks like the company is trying to weasel out of it and there are going to have to be lawsuits. Though I didn't really expect otherwise; if the dice come up badly, the damage from this could exceed the net value of the company.

Re: Xerox responds to the recent character substitution issue

#70

Post by workbench »

jessedhillon wrote: post #60
Gormo wrote: post #38

Earlier quoted context omitted.

It seems a bit too coincidental that images to which human beings assign semantic value are being transformed into images to which human beings assign different semantic value. 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".

This is hacker news -- I don't expect everyone to know how jbig2 or other compression scheme works. But before you insinuate that the scanner has semantic awareness of the document and is altering that meaning in a less-than-coincidental way, I would hope that you could have a cursory look at how such compression works. The issue only involves small letters, because the compression scheme breaks up the image into pat…

You'd expect anyone who knows how JBIG2 works would also know it should never have been used for this
Post reply on HN