search

qurator-spk / dinglehopper

An OCR evaluation tool
Apache License 2.0
59 stars 13 forks source link

getLogger Irritation with regular CLI #55

Closed M3ssman closed 3 years ago

M3ssman commented 3 years ago

Issue description

Using recent version (1778b3) of dinglehopper complains because of OCR-D-Logger

dinglehopper 1300565-gt.xml 1300565.xml

=> 

21:17:33.416 CRITICAL root - getLogger was called before initLogging. Source of the call:
21:17:33.416 CRITICAL root -   File "/home/hartwig/Projekte/work/mlu/ulb/ulb-sachsen-anhalt-dinglehopper/qurator/dinglehopper/extracted_text.py", line 243, in get_first_textequiv
21:17:33.416 CRITICAL root -     log = getLogger("processor.OcrdDinglehopperEvaluate")

Even though all report-files are being generated, the output is somehow irritating.

Steps to reproduce the issue

  1. call dinglehopper 1300565-gt.xml 1300565.xml (attached)

What's the expected result?

Additional details

The Problem could be worked around if you use OCR-D's initLogging also within the context of the non-OCR-D-CLI, adding in cli.py something like this:

initLogging()
Config.progress = progress
process(gt, ocr, report_prefix, metrics=metrics, textequiv_level=textequiv_level)

Does dinglehopper want to stick with the OCR-D-Logger also in potential non-OCR-D-contexts? Further, it looks like dinglehopper is currently missing any dedicated logging-configuration, which couples it rather strong not only to the OCR-D-Logging-Logic, but also to it's configuration.

1300565-test.zip

kba commented 3 years ago

The Problem could be worked around if you use OCR-D's initLogging also within the context of the non-OCR-D-CLI, adding in cli.py something like this:

I'm open to reintroducing on-the-fly initLogging() and dropping the error messages, as they should really be debug messages, maybe discuss in https://github.com/OCR-D/core/issues/621

which couples it rather strong not only to the OCR-D-Logging-Logic, but also to it's configuration.

But is that such a bad thing? Reusing the OCR-D logging framework gives configuration files and globally overrideable log levels. My point is that it would benefit all things OCR-D if we improved the versatility/usability of the logging framework.

mikegerber commented 3 years ago

Yes, this errror message bothered me too, last time I used the non-OCR-D CLI. I'll look into it

M3ssman commented 3 years ago

@kba Totally agree in the realms of OCR-D. But this time its all about dinglehopper's non-OCR-D-CLI. To be honest, I wasn't even able to figure out where the log messages are going after all.

mikegerber commented 3 years ago

We now just call ocrd_utils' initLogging() in both the non-OCR-D CLIs dinglehopper and dinglehopper-extract to get this resolved!

mikegerber commented 3 years ago

To be honest, I wasn't even able to figure out where the log messages are going after all.

To stdout, it seems.