no deskewing/orientation in GT

[bertsky]

I don't know how this is supposed to work at all. Usually the images need no deskewing, but when they do, that information is missing in PAGE. (I would at least expect some orientation angle in the text regions. Or is Baseline the place to look for this information?)

E.g. in weigel_gnothi02_1618, page phys_0001 needs to be rotated about -2.0 degrees (clockwise). The effect is also pronounced in the GT annotation itself: it contains coordinates that effectively chop off parts of the glyphs in some corners, e.g. region TextRegion_1479403414297_29 line tl_1 (chopped "V"), region TextRegion_1488379719413_342 line tl_22 (chopped "durch ſein") and region TextRegion_1488379733255_361 (chopped "ſein").

[kba]

Needs to be specified ASAP in OCR-D/spec. Send PR for page-wise and line-wise rotation to PAGE-XML for upcoming 2019 version.

@chris1010010 @wrznr @bertsky @tboenig @cneud

[chris1010010]

Hi all, I might have mentioned in another thread, the full PAGE format collection has a dedicated XML format for this, as deskewing was seen as a pre-processing step that does not need to be reflected in the page content XML. But as it turned out, these other XML formats were never adopted much.
I guess adding the rotation doesn't hurt. Baselines would include the angles implicitly, but that's overkill in many cases I assume.
@wrznr @bertsky @tboenig @cneud

[bertsky]

Hi @chris1010010, thanks for your quick feedback!

Are you referring to the 2009 subschema deskew? This functionality would be superseeded completely if we had @orientation in PageType – we can already have the binary rotated image in AlternativeImage.

I would like to do the PR myself, but looking more closely, I have trouble interpreting the existing Region level attributes with certainty: @orientation sounds more like referring to the Coords.points, whereas @readingOrientation to the actual image. Is that impression correct? If so, are they mutually exclusive?

BTW, we just have a discussion on AlternativeImage based annotation including rotation issues here.

[chris1010010]

Hi @bertsky
Yes, I was referring to that subschema.
I always interpreted orientation and readingOrientation as additive.
Orientation is for the block/region in general. ReadingOrientation was intended for cases where the text is at an angle with reference to the block/region. We had examples somewhere, but only using orientation should be sufficient in most cases. In the current format I would probably use nested regions.

[bertsky]

Oh, I see. Thanks for the clarification!

I mentioned the additive semantics in the new PR.

[EEngl52]

@tboenig can this be closed?