Line Segmentation - Console Error Message

[lsubhd]

5 von 70 Dateien wollen nicht durch die Line Segmentation, die folgende Fehlermeldung taucht auf, leider kann ich daraus nichts ersehen, was ich verändern muss damit es gehen könnte:

• Alle Dateien sind von Hand mit LAREX Segmentiert worden

Traceback (most recent call last):
  File "/usr/local/bin/pagelineseg", line 33, in 
    sys.exit(load_entry_point('ocr4all-helpers==0.2.2', 'console_scripts', 'pagelineseg')())
  File "/usr/local/lib/python3.6/dist-packages/ocr4all_helpers-0.2.2-py3.6.egg/ocr4all_helpers/pagelineseg.py", line 634, in cli
    pool.map(parallel, dataset)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 266, in map
    return self._map_async(func, iterable, mapstar, chunksize).get()
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 644, in get
    raise self._value
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 119, in worker
    result = (True, func(*args, **kwds))
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 44, in mapstar
    return list(map(*args))
  File "/usr/local/lib/python3.6/dist-packages/ocr4all_helpers-0.2.2-py3.6.egg/ocr4all_helpers/pagelineseg.py", line 625, in parallel
    remove_images=args.remove_images)
  File "/usr/local/lib/python3.6/dist-packages/ocr4all_helpers-0.2.2-py3.6.egg/ocr4all_helpers/pagelineseg.py", line 304, in pagexmllineseg
    root = etree.parse(xmlfile).getroot()
  File "src/lxml/etree.pyx", line 3521, in lxml.etree.parse
  File "src/lxml/parser.pxi", line 1859, in lxml.etree._parseDocument
  File "src/lxml/parser.pxi", line 1885, in lxml.etree._parseDocumentFromURL
  File "src/lxml/parser.pxi", line 1789, in lxml.etree._parseDocFromFile
  File "src/lxml/parser.pxi", line 1177, in lxml.etree._BaseParser._parseDocFromFile
  File "src/lxml/parser.pxi", line 615, in lxml.etree._ParserContext._handleParseResultDoc
  File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult
  File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError
  File "/var/ocr4all/data/testset/processing/0064.xml", line 1
lxml.etree.XMLSyntaxError: Start tag expected, '<' not found, line 1, column 55

@jbarth-ubhd

[maxnth]

Ausgehend von der Fehlermeldung würde ich darauf tippen, dass die jeweiligen XML-Dateien (also z.B. 0064.xml) "defekt" sind. In Versionen <v0.5.0 gab es leider in LAREX Bugs, welche beim Vorhandensein bestimmter Elementtypen/Elementkombinationen dazu führten, dass die Segmentierung nicht korrekt als PAGE XML seralisiert wurde.
Falls Sie mir eine der XML-Dateien zukommen lassen könnten, würde ich mir diese aber noch einmal konkret ansehen.

Die entsprechenden Seiten mit der aktuellen OCR4all-Version erneut zu segmentieren sollte das Problem beheben.

[jbarth-ubhd]

Ja, habe alle Dateien mit find . -type f -name "*.xml" -exec xmllint -format \{} \; > /dev/null durchlaufen lassen:

+ xmllint -format 0064.xml
0064.xml:1: parser error : Start tag expected, '<' not found
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
                                                      ^

Nach dem > ist die Datei auch schon (zu früh) zu Ende. Am Festplattenplatz liegts wahrscheinlich nicht. In den Docker-Logs gibt's 0 Fehlermeldungen.

[jbarth-ubhd]

Gibt es schon neuere Docker-Container mit Larex ≥ v0.5.0 ?

[maxnth]

In den Docker-Logs gibt's 0 Fehlermeldungen.

Mindestens einer der Bugs resultierte aus fehlerhaftem JavaScript-Code. Die Docker-Logs behalten AFAIK jedoch nur die Fehlermeldungen des Back-Ends, was das erklären könnte (falls den wirklich einer dieser Bugs auch hierfür verantwortlich ist).

Gibt es schon neuere Docker-Container mit Larex ≥ v0.5.0 ?

Das aktuelle ls6uniwue/ocr4all:latest-Image enthält v0.5.0 für OCR4all und LAREX.

[maxnth]

Possibly related to #94

[jbarth-ubhd]

@lsubhd: aktualisiert.

@maxnth: habe wie folgt aktualisiert:

> docker pull ls6uniwue/ocr4all
Digest: sha256:7ded563ca0ee9cf4d48f0fc542e1a5273cf8d07ed64ed616ebc1e6dc004ac91c
Status: Downloaded newer image for ls6uniwue/ocr4all:latest
docker.io/ls6uniwue/ocr4all:latest

> root@xxx:/home/jb# docker ps|grep ocr4all
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                                         NAMES
f6721ec7833a        48d3c865652a                "supervisord -c supe…"   3 weeks ago         Up 2 weeks          0.0.0.0:8080->8080/tcp                        ocr4all

> docker stop f6721ec7833a

> docker run -p 8080:8080 ...
docker: Error response from daemon: Conflict. The container name "/ocr4all" is a
lready in use by container "f6721ec7833a7a7b55cd044bc9619eb228760ce925e7b72a31f6
f2dbba7f7e38". You have to remove (or rename) that container to be able to reuse that name.                                                                     
See 'docker run --help'.

> docker rm f6721ec7833a7a...

# und dann nochmal
> docker run ...
# ...das hat geklappt.

ist docker rm wirklich notwendig? Sind in den Containern Daten gespeichert?

[maxnth]

ist docker rm wirklich notwendig?

In dem Fall schon, da ein Docker Container mit demselben Namen schon existiert und der bestehende Container nicht durch das Pullen eines neuen Images verändert wird (falls sich die Frage darauf bezog).
Mit docker run --rm ... wird der hierdurch erstellte Container nach dem Stoppen des Containers automatisch entfernt.

Sind in den Containern Daten gespeichert?

Es werden nur Daten in den gemounteten Volumes gespeichert/verändert (in Form von Bildern/PAGE XMLs), andere Daten werden – zum jetzigen Stand – nicht erstellt.