Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cmccambridge

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @jonp or @trurl could you move this over to the Docker Containers support thread section? @Squid Anything extra I need to do on the CA side for a second template in my existing repository? Thanks all for all of your help!
  2. Application: mosquitto-unraid Overview: Container for eclipse-mosquitto with Unraid ease-of-use tweaks Docker: https://quay.io/repository/cmccambridge/mosquitto-unraid Application GitHub: https://github.com/cmccambridge/mosquitto-unraid This container is a minimal port of the official Eclipse Mosquitto Docker container with minor tweaks to work more conveniently in Unraid. For details on how to configure the container, please see the README on GitHub! You can configure: Persistent Data Logging Authentication TLS Websockets Questions? Post any other questions or issues relating to this Docker container on Unraid in this thread, or by opening an issue on GitHub.
  3. Hi @Abigel - couple of thoughts... First and most important: the tesseract OCR engine that is used by ocrmypdf-auto really isn't optimized for handwriting. It's designed for typeset / printed text which has properties that make it "easier to read" like consistent letter shapes, letter spacing, word spacing, line breaks, etc. You can read all the gory details on the tesseract homepage, or explore some of the academic research efforts to extend the engine to handwriting, but the short version to my understanding is: handwriting recognition is a lot harder than recognizing typeset text. That said... here would be my best tips Sorry that I don't have any solution to this problem... Your example image appears to be a cellphone photo of a page of text. This should work, but you will probably get better results the closer your image looks to a black-and-white piece of paper. Tesseract has tips on improving recognition by improving image quality. For example, in your files the handwriting is blue on a tan background... this is clear to a human, but not as obvious to a computer. It will be easier for the computer to understand if all text is black on white. If you have access to a scanner, I would try that instead of a phone camera, since the scanner will remove some of the artificial "room coloring" that a phone camera sees. Or, convert your phone image to black and white and increase the contrast before trying to run OCR on it, so that the text versus background are very clear for the computer. Since the OCR engine does try to recognize full words, not just individual letters, it's important to tell it what language(s) to expect. This is what the OCR_LANGUAGES variable is for. In your case, since you're writing in German, I would try setting OCR_LANGUAGES="deu" to install the German language data, rather than the default of English. And as a side tip... the best program I've ever seen for recognizing actual handwriting is a somewhat unexpected one: Microsoft OneNote. This may not be helpful to you at all unless you have a Windows computer, but it could be worth a try :). I am not sure whether it will do as good a job recognizing handwriting in a photo as it does recognizing direct pen input on a tablet, though... I did a quick experiment with some of the tips above, and got slightly better results... enough that it might be worth it for you to keep experimenting? Up to you Converted your image to black and white. Increased the contrast until the handwriting was very black and the background was very white. Ran ocrmypdf-auto with OCR_LANGUAGES=deu The result was partial recognition: Das Haus ı5+ gem. Best of luck! input_black_white.pdf output_black_white.pdf
  4. I'm glad that it's working now for you, @Abigel - I believe I know what the problem was there, and will get an update posted so that other folks don't run into the same problem down the road. Thanks for reporting this! Re: handwriting recognition... This isn't really the intended purpose for tesseract, the OCR program that ocrmypdf-auto is using internally. I have limited success with recognizing block letter handwriting, such as the attached example... you can see that it mostly recognized the block letters (mistook "IS" for "1S"), did similarly OK on mixed upper and lowercase printed letters (mistook "Hello" for "Yello" and got some capitalization wrong), and did poorly on cursive lettering. If you want to research this further, here's a link I had found regarding academic research into customizing tesseract for handwriting recognition... it sounds like the accuracy is not very good: https://stackoverflow.com/questions/39556443/using-tesseract-for-handwriting-recognition Note: If it wasn't clear from the documentation or your experience with ocrmypdf-auto, there's one thing I should clarify: The program intentionally does not change the input image of the PDF itself, other than some minor quality enhancements like deskewing, etc. Instead, the program only adds an extra invisible "text layer" to the output PDF that lets you search for and highlight recognized text. For example, if you highlight all the handwriting in the output sample here, you can copy and paste the following "recognized" text: HELLO, THIS 1S AN OCR TEST. Yello, this is an OcR test. Alle, thin ko am OCR et. OCR Test Input.pdf OCR Test Output.pdf
  5. Hi @Abigel, sorry to hear you're having issues... I'm away on vacation at the moment and so don't have access to a computer to debug, but one thing comes to mind to try. The most recent change made to the code was regarding support for multiple languages. Perhaps we introduced a bug there that didn't surface until now. Could you try explicitly setting OCR_LANGUAGES="enu" (or your language of choice) even though it's supposed to work correctly without? Let me know if that changes anything...
  6. Great catch @trurl, thanks! The unRAID template is already up and running here, but I had forgotten to go back and tidy up my TODO list. There is now unRAID-specific documentation in the project's README file that describes the recommended container settings for anybody not installing via the defaults in the unRAID template directly. https://github.com/cmccambridge/ocrmypdf-auto/blob/master/README.md#unraid-integration (Note: At the moment, I've still got a few open questions to @Squid about that template in a DM, so I don't believe that it is live in CA just yet... feel free to wait on moving this thread until the template is live.)
  7. Application: ocrmypdf-auto Overview: Automatic OCR of image PDFs from an input directory to an output directory using ocrmypdf and the latest tesseract. Docker: https://quay.io/repository/cmccambridge/ocrmypdf-auto Application GitHub: https://github.com/cmccambridge/ocrmypdf-auto This container automates one stage in a "paperless" document processing pipeline: Take all the PDFs in some input folder, run OCR on them, and save the output to an output folder. It combines the excellent tools ocrmypdf and tesseract with file-monitoring and some new configurability. For example, you could configure a wireless document scanner to save all images to one share on your unRAID server, and use this container to monitor all new incoming files, OCR them, and write the finished (searchable!) PDFs to another share: For details on how to configure the container and ocrmypdf to tweak OCR behavior, please see the README on GitHub! You can configure: What options (per-folder) to pass to ocrmypdf e.g. one folder for clean, normal page size grayscale scans from the document scanner e.g. a separate folder for skewed, poor contrast receipts from a phone app e.g. a separate folder for multi-language scans What to do with original files after OCR Archive them to a 2nd output folder? Delete them? Where to store temporary files By default, within the container Or: configure your own high-speed temporary path (cache disk, ramdisk, etc.) Questions? Post any other questions or issues relating to this Docker container in this thread.