allow cropping separately

[bertsky]

I know OCR-D integration is still underway, but just wanted to bring to attention that OCR-D currently lacks a neural (or in fact, any useable) cropping tool, and thus it would be extremely helpful if eynollah's (or sbb_textline_detection's) UNet-based model for that would be wrapped independent of the overall segmentation.

[vahidrezanezhad]

Actually for my usage and mostly for data preparation, I have provided a page-extractor tool. I will soon publish it on our qurator github then OCR-D can also use it dependently.

[vahidrezanezhad]

https://github.com/qurator-spk/sbb_page_extractor

[bertsky]

https://github.com/qurator-spk/sbb_page_extractor

Not public yet?

[vahidrezanezhad]

https://github.com/qurator-spk/sbb_page_extractor

Not public yet?

Sorry was my fault. It is public now

[bertsky]

Thanks @vahidrezanezhad!

[mikegerber]

As far as I can understand this, sbb_page_extractor is one processing step of eynollah, maybe it could just be an eynollah option to only do this aspect of the overall layout analysis (with no code duplication?)

[cneud]

I agree with @mikegerber, can we instead make page extraction available as a command line option in the current codebase of eynollah @vahidrezanezhad?

[vahidrezanezhad]

I agree with @mikegerber, can we instead make page extraction available as a command line option in the current codebase of eynollah @vahidrezanezhad?

Page extraction was already available by eynollah. What you need is to enable plotting and then save output images and page image is one of those outputs.

[bertsky]

I don't know about other use cases (plotting / cropped image is not used by OCR-D), but to wrap the cropper into a separate processor, I think we do need some additional boilerplate, because that's also a chance to avoid the at once build_pagexml approach. In OCR-D, we need incremental annotation, so we can freely exchange individual steps in between workflows. (I.e. regarding eynollah, currently one cannot have prior processors, as their PAGE would be ignored.)

So IMO that should be a minimalistic crop_processor.py that simply delegates to extract_page, but uses only its second result to create a Border on the input PAGE. (Of course, we could also add another Processor class to processor.py.)