Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cropping Output #15

Closed
mjenckel opened this issue Oct 31, 2019 · 3 comments
Closed

Cropping Output #15

mjenckel opened this issue Oct 31, 2019 · 3 comments

Comments

@mjenckel
Copy link
Collaborator

mjenckel commented Oct 31, 2019

With 44247ab 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
Copy link

wrznr commented Nov 6, 2019

@bertsky?

@bertsky
Copy link
Contributor

bertsky commented Nov 6, 2019

@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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants