Cropping Output

[mjenckel]

With https://github.com/mjenckel/OCR-D-LAYoutERkennung/commit/44247abca930cbff6e0cfa2f259168a4ee7e2f5a we added the AlternativeImage functionality to Cropping. Since we expect all modules to be used in a pipeline (see README.md) we were wondering if simply storing the border coordinates is correct. If we use Deskewing previous to Cropping and add an alternative deskewed image to the list of AlternativeImages, shouldnt we apply the inverse rotation on the found border coordinates so they apply to the original image rather than the deskewed image?

[wrznr]

@bertsky?

[bertsky]

@mjenckel are you sure you are referring to the right commit? (You already used 44247ab in #16 as well. It does not contain what is described there either.) Remember, it's hard to talk about these things in the air without a formal description of what is meant.

If we use Deskewing previous to Cropping and add an alternative deskewed image to the list of AlternativeImages, shouldnt we apply the inverse rotation on the found border coordinates so they apply to the original image rather than the deskewed image?

You should definitely. But this is not specific to deskewing (or cropping, for that matter). Any operation that wants to add coordinates must be aware that its input could have been in non-original (relative) coordinates, whereas PAGE-XML coordinates are always absolute. As long as all processors consistently added @comments (feature descriptions) to the images they annotate, core can keep track of the respective coordinate transformations, and invert them if requested.

You can do that via coordinates_for_segment(polygon, parent_image, parent_coords), where

• polygon is your (newly found) border polygon in coordinates relative to
• parent_image, which you received from workspace.image_from_page() – regardless of whether you applied deskewing or anything else before (except dewarping, for which we do not have a rich enough annotation to preserve coordinates yet), and
• parent_coords, which you received together with that, contains the image's features and coordinate transform.

This will then give you the coordinates you can annotate via a new CoordsType(). See docstrings in core and ocrd_tesserocr/segment-region.py for examples.

[mjenckel]

as per @bertsky 's advice, all coordinates should now be absolute coordinates