PAGE XML rendering processor for debugging

[kba]

https://gitter.im/OCR-D/Lobby?at=603289f74c79215749fed1bb
@SB2020-eye 17:27
Using Prima Page Viewer to view an xml file, is there a way to save what I am looking at as an image file? (This will help me compare results of different workflows more efficiently.)
@SB2020-eye 18:06
(PS ...or directly doing this from an ocr-d workflow is even better, of course, if possible!)

It might be useful to have a processor in OCR-D/core that renders PAGE-XML and its elements to an image file to debug.

Tools that could be wrapped:

• ocrd-segment-extract-pages from https:/OCR-D/ocrd_segment/
• https:/vahidrezanezhad/page-xml-to-image
• https:/GBN-DBP/page-xml-draw/

[bertsky]

• https:/vahidrezanezhad/page-xml-to-image

cf. vahidrezanezhad/page-xml-to-image#1

It might be useful to have a processor in OCR-D that renders PAGE-XML and its elements to an image file to debug.

There are already processors doing that. See https://gitter.im/OCR-D/Lobby?at=601ffe3b24cd6b60d824c7da

But the OP probably did not mean CLIs. Instead, this might be a functionality worth adding to the core API.

See also this proposal.

[kba]

Yes, sry, I forgot about ocrd-segment-extract-pages -P plot_*.

And yes, I think it might be useful to have API-level support for PAGE rendering in core and potentially bundle a processor much like ocrd-segment-extract-pages.

[bertsky]

Ok, then I suggest simply moving all ocrd-segment-extract-* stuff from ocrd_segment into ocrd.processor.builtin and refactoring the various shared functions into ocrd_models.ocrd_page, maybe grouped into coordinate repair (unravelling validation reports), iteration through the segment hierarchy, and ImageDraw.Draw.polygon() (both by alpha compositing or plain).

(One might even move replace-original and replace-page, perhaps with better naming.)

That would also help keeping ocrd_segment small and avoid unnecessary dependencies.