704
Recreating uncensored Epstein PDFs from raw encoded attachments (neosmart.net)
submitted 9 months ago by to c/technology@lemmy.world
57 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] [S] 24 points 9 months ago* (6 children)

Are you having as much trouble with OCR as the article author? I would have thought OCR was a solved problem in 2026 even with poor font selection.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 19 points 9 months ago

    I'm not having trouble with it as such, it's just a slow and painstaking process. The source is crappy enough that an enormous number of characters need to be checked manually, and it's ridiculously time-consuming.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 10 points 9 months ago (2 children)

    I wonder if they gave considered crowdsourcing this, having many people type in small chunks of the data by hand, doing their own character recognition? Get enough people in and enough overlap and the process would have some built-in error correction.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 14 points 9 months ago* (1 child)

    I mean the problem is that even with human eyes it's still really hard to tell l and 1 in that font.

    See image

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 12 points 9 months ago* (last edited 9 months ago)

    Not an expert at all but I’m genuinely curious how long it would take to check all possibilities for each I or 1? Is that the full length of the hash or whatever? So in this example image we have 2^8 =256 different possibilities to check? Seems like that would be easy enough for a computer.

    Edit: actually read the article. It’s much more complicated than this. This isn’t really the only issue and the base64 in the example was 76 pages long.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 9 months ago (1 child)

    OCR is mostly good enough. Problem here is we have 76 pages that we need to be read perfectly, with a low fidelity input

    We also have very little in the way of error correction, since it's mostly not human readable

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 9 months ago

    We also have very little in the way of error correction, since it’s mostly not human readable

    This is the main point.
    Most well working OCR systems have a dictionary-check pass, which goes a long way into fixing the errors.

    On the other hand, if all those files are the same font and size, it should be possible to tune the OCR to better match the requirements. Also reduce the possibilities to the character set used by the encoding.

    I was recently using OCR for an unrelated project and it was totally unusable as is, because unlike what it expected (plain text documents), it got text on top of pictures. So now I have to find ways to preprocess and single out the text, removing the graphic lines that might be behind it, to make it readable.

  • permalink
  • fedilink
  • source
  • parent