undefined | Better HN

story

0 pointshga12y ago0 comments

Well, it doesn't go all the way, at least in this implementation (contrary to Xerox's statement, we've been told compression is not standardized), to actually recognize the symbols it finds. If it did, it would presumably make many fewer of these errors, maybe almost none since when it's uncertain it could just go with the original.

0 comments

ToothlessJake12y ago

O-SubC-R then perhaps. Still is recognizing shapes/symbols which is the very basis of OCR.

This seems a bit hair splitty when the end result is the same as invalid OCR dictionaries.

Groxx12y ago

Well sure, but then why don't we just call it "lossy GZIP"? OCR is a pretty specific subset, and produces characters - this does not produce computer-readable characters, therefore not OCR.

ToothlessJake12y ago

What are you on about? What does it produce if not computer-readable characters? Computer illegible characters? Are you saying it cannot read from the dictionary it creates? Or from the characters it is later optically recognizing off that dictionary?

Again from the JBIG2 wiki[1]:

"Textual regions are compressed as follows: the foreground pixels in the regions are grouped into symbols. A dictionary of symbols is then created and encoded.."

It seems not only is JBIG2 being deployed as OCR by Xerox for whatever reason, its implementation in this case is an absolute failure.

[1] http://en.wikipedia.org/wiki/JBIG2

Groxx12y ago

Does it produce ASCII? UTF? If no, it's not OCR.

edit: by the definition you seem to be going on, any facial recognition is also OCR, since you could consider a face a 'glyph' (edit: 'symbol'). The only 'text' thing here that I can see is that it is intended to be used on text, which lends some optimizations, nothing that it's actually text-based in any way.

1 more reply

eCa12y ago

It produces symbols, not characters.

Say that the scanner internally splits the scan into regions of 10x10 pixels that it saves in memory. If another region differs on less than (say) 10% of the pixels it is assumed that the two zones are identical and the first one is used in the second place too. The regions have no semantic meaning.

OCR translates the scan into a character set.

1 more reply

bestham12y ago

OCR per definition gives out text. Not binary data that resemble the bitmap of the input image.

j / k navigate · click thread line to collapse

0 comments

ToothlessJake12y ago

O-SubC-R then perhaps. Still is recognizing shapes/symbols which is the very basis of OCR.

This seems a bit hair splitty when the end result is the same as invalid OCR dictionaries.

Groxx12y ago

Well sure, but then why don't we just call it "lossy GZIP"? OCR is a pretty specific subset, and produces characters - this does not produce computer-readable characters, therefore not OCR.

ToothlessJake12y ago

Again from the JBIG2 wiki[1]:

"Textual regions are compressed as follows: the foreground pixels in the regions are grouped into symbols. A dictionary of symbols is then created and encoded.."

It seems not only is JBIG2 being deployed as OCR by Xerox for whatever reason, its implementation in this case is an absolute failure.

[1] http://en.wikipedia.org/wiki/JBIG2

Groxx12y ago

Does it produce ASCII? UTF? If no, it's not OCR.

1 more reply

eCa12y ago

It produces symbols, not characters.

OCR translates the scan into a character set.

1 more reply

bestham12y ago

OCR per definition gives out text. Not binary data that resemble the bitmap of the input image.

j / k navigate · click thread line to collapse