3 ms·

The discussion and this reminds me on the problems with Xerox Scanners: https://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_are_switching_written_numb

• peri-cl 1mo ago
  Here's the Wikipedia link, https://en.wikipedia.org/wiki/JBIG2#Character_substitution_errors_in_scanned_documents https://en.wikipedia.org/wiki/JBIG2#Character_substitution_e... JBIG2's a high-compression ratio arithmetic coder for 1-bit black-and-white images. One of its tricks is it builds tables of glyphs, and may encode new glyphs using similar glyphs as references/predictions. If you have a scanned image of a physical document, you will have large sets of small raster images of the same recurring glyph, say "8"'s, which are very similar to each other as rasters. The arithmetic coder takes advantage of this, the low relative entropy of the set of similar rasterized glyphs. There's both a lossless mode, and a lossy mode which can skip this step and directly substitute a glyph for a different glyph, if it believes they're really two analog versions of the same textual glyph. It's an obvious bug to use the lossy mode on numeric data: lossy compression can silently substitute a blurry glyph with a crisp version of a different one. Like in the Xerox example, a blurry "8" turned into a "6". (Numeric data, specifically, because natural language is resilient to sjngle-cℏaracter errors). It's akin to OCR errors, but more insidious than OCR, because it alters the original raster document in a convincing way.