After playing around with the extended PAGE image metadata fields, @Boenig and I wanted to suggest further additions. However, this would ultimately lead to an inclusion of a complete image metadata set into PAGE which might not be desirable. Relying on an already existing XML schema is probably an effective alternative. Luckily, such a schema is existing and, even better, it is maintained under the tutelage of the W3C: https://www.w3.org/2003/12/exif/

So, what do @chris1010010, @splet and @cneud think about simply including this rdf schema in PAGE XML?

Coordinates are at the heart of stand-off annotation formats. In PAGE-XML, all visible elements must have a CoordsType, which must have a @points. There is even some syntax for that enforced by a regular expression. However, the standard lacks any semantics for the coordinate system whatsoever. There is not even a comment about this, so with luck, at least all implementors guessed consistently.

IMO we need to specify that:

1. @points always describes (a list of x-y pairs of) absolute pixel coordinates ("absolute" meaning they refer to the root image in PageType/@imageFilename with the upper left corner as 0,0)

Moreover, we should clarify whether:

2. @points has a topology of
   • (unordered) sets of points, or
   • a single (open or closed) path, or
   • multiple closed paths (and if so, whether orientation is relevant as in e.g. left=inside / right=outside)
3. @points must obey certain constraints like
   • are paths allowed to leave the parent element's polygon outline / bounding box, or maybe even the page's bounding box (i.e. become negative, which is currently forbidden by syntax)? And if not:
   • must they be closed along the parent element's polygon outline / bounding box, or may they stay open when intersecting it?
   • are paths required to be planar (i.e. have no cross-sections)? And if not:
   • how does the content area compute,
     • by union, or
     • by difference, or
     • by orientation (left-of-path or right-of-path)?

This is highly relevant for implementors, especially when polygon processing and AlternativeImage processing on multiple hierarchy levels in the presence of skew becomes common practise – which is currently happening within OCR-D (for showcases see our Tesseract and our Ocropy preprocessing and segmentation wrappers).

(Cf. altoxml/schema#49)

Add MapRegion to the xsd:choice list within RegionType (as in PageType, and as all the other region types).

(I don't see a reason why this should be excluded – most likely just forgotten.)

Hi, Sometimes it is necessary to define the Text Style (font...) for the whole page. For example if you want to create GroundTruth only for used fonts independent from text, word and glyph regions. Therefore my suggestion is to allow the element TextStyle within element Page.

We use the 2018 version in @OCR-D for Ground Truth and expect software partners to produce PAGE based on the 2018 version.

It would help a lot interoperability-wise if the schema location was dereferenceable, i.e. if

http://www.primaresearch.org/schema/PAGE/gts/pagecontent/2018-07-15/pagecontent.xsd

would resolve to the XSD the same way that

http://www.primaresearch.org/schema/PAGE/gts/pagecontent/2017-07-15/pagecontent.xsd

does now.

@chris1010010 Can you create the folder and upload the XSD?

Thank you!

While it's pretty neat that I can represent skew on region level, deskewing is typically (i.e. in ABBYY products) a process which is applied on page level only. How can I incorporate skew angles on page level in PAGE XML?

For OCR-D we have the requirement to allow preprocessing not just on page level but on regions, text lines or words. For example, dewarping of individual text blocks or text lines.

In order to support these use cases, we extended the schema to allow pc:AlternativeImage as an optional first element within

• RegionType
• TextLineType
• WordType
• GlyphType

Would you consider to incorporate these extensions in the next PAGE release?

Thanks!

CC @wrznr @tboenig @cneud

We are currently setting up the OCR-D framework using PAGE XML. For the image pre-processing step, we'd like to propose a few additions to the image metadata header section. It would be great if they could be integrated into the “official” PAGE XML schema as well.

• require @index to be ascending monotonically (but still across types)

follow-up on https://github.com/PRImA-Research-Lab/prima-page-viewer/issues/15#issuecomment-623605873

as a follow-up on https://github.com/PRImA-Research-Lab/prima-page-viewer/issues/15#issuecomment-623492135

If @index is not required to be contiguous (which I would be happier with), please let me know.

@kba @stweil @splet @chris1010010 @Boenig Hello! thanks a lot for this great tool! Please how can I use this tool?How can I install it ?Wha kind of command can use?

Is there a reason that

• there is no @production in PageType (and only there)
• there is no @secondaryLanguage in TextLineType (and only there)

or have they been forgotten?

In light of #25 and general consistency, I think there should also be a @comments under PageType (as with all other segment hierarchy types). This is especially useful for descriptors of the @imageFilename (in analogy to AlternativeImage/@comments).

In PAGE-XML there's @language / @primaryLanguage of type pc:LanguageSimpleType to identify the natural language of segments. Its documentation refers to ISO 639.x 2016-07-14, which I cannot make sense of. There's 639-1, 639-2 and 639-3, but AFAICT no standard that allows strings of arbitrary length (as in the PAGE-XML enumeration), and nothing shows up for 2016-07-14. This is problematic because exact 639 mappings are needed for software implementation and interoperability.

Take Norwegian for example:

                       <enumeration value="Norwegian"/>
                        <enumeration value="Norwegian Bokmål"/>
                        <enumeration value="Norwegian Nynorsk"/>

According to 639 these could be named no/nb/nn or nor/nob/nno, but how do we map that automatically, where do the strings derive from in PAGE-XML?

The schema documentation only says this:

• readingDirection:

  The direction in which text within lines should be read (order of words and characters), in addition to “textLineOrder”.

• textLineOrder:

  The order of text lines within the block, in addition to “readingDirection”.

Now, the values for both of these are stated in absolute terms (top-to-bottom, bottom-to-top, left-to-right, right-to-left), not relative to XML ordering (straight vs inverse).

So how exactly should they be interpreted?

1. W.r.t. @orientation: Before or after rotation?
2. W.r.t. XML ordering: Should elements always be "in order" already, or must they follow some absolute top-down left-right default?
3. W.r.t. each other: Is it an error if they are not orthogonal?

I have not found a single example anywhere in the repo. I found but 2 examples of @readingDirection="bottom-to-top" in the PRImA Layout Analysis Dataset, namely r13 in 00000408 and r3 in 00000394 – both of which are cases of @orientation=-90°. Is this correct?

Since AlternativeImage has been introduced on every level of the structural hierarchy, these image files can be used to represent results from image preprocessing (normalization, denoising, binarization, non-text suppression, despeckling, deskewing, dewarping). Some of these operations can and some cannot be represented descriptively – but referencing derived images always helps avoiding repeated computations.

However, there's a difficulty/penalty involved: All coordinates in the PAGE hierarchy are referring to the original image (under /PcGts/Page/@imageFilename), whereas derived images (AlternativeImage/@filename under Page or Region or TextLine or Word) necessarily have different, local/relative coordinate system. It is connected to the global/absolute coordinate system only implicitly.

So if you want to process via derived images, like crop segments further down the hierarchy (translating from their absolute coordinates to the images' relative coordinates) or add further segmentation (translating from new relative coordinates in the images to new absolute coordinates), then you must know the transformation between them.

This could merely be an offset (which could be unambiguously defined as the top left of the bounding box of the element's polygon), which happens after cropping (on the page level or any segmentation below that). But there are certain operations which change coordinates non-trivially:

• Deskewing will shift to the center of the element's bounding box, then rotate around that center, increasing the size of the bounding box (to avoid loosing content at the corners), and shifting back to the (new) top left of the bounding box. Alternatively, larger angles (e.g. multiples of 90°) could be applied by reflection instead of rotation.
• Dewarping may change coordinates in any number of ways (3d shear or cubic spline projection, or interpolated raster grid, including as a special case centerline projection).
• Rescaling or aspect correction will multiply coordinates by a constant factor.

All those effects are cumulative, i.e. they will compose into a new coordinate transform at each step, and in the order of the operations applied to the image (and its predecessors). This is not always trivial, e.g. cropping before/after deskewing, deskewing on page and then again on region level. It's certainly not rocket science, but (believe me) there are many ways you can get this wrong when you have to implement it.

Now, for cropping and deskewing, we are in the fortunate situation that – provided the operations applied on the derived image have been carried out in the "correct" way and documented in its @comments – their respective coordinate transform can be reconstructed from the descriptive information (Coords/@points and @orientation).

But for dewarping and rescaling we don't even have any descriptive annotation yet.

For dewarping, maybe the dewarping schema with its /DwGts/Grid/Row/@points is sufficient (although it is unfortunate that this schema is external to the content schema).

But for rescaling, there's nothing at all.

You could ask:

1. shouldn't we then allow annotating the coordinate transform explicitly?
2. why do you want to rescale?

1: I'd be happy to see PAGE adopt some representation of affine transformations (basically a 3x3 float array) under AlternativeImage/@coordinate-system. But I would still consider this only a redundant convenience feature.

2: Rescaling is useful under various scenarios:

• avoid wasting computation on images with too large pixel density by downsampling them during processing
• ensuring a fixed pixel density for operations that expect certain component sizes or distances (e.g. rule-based segmentation tools always assuming 300 DPI)
• ensuring a fixed pixel resolution for operations that expect a certain image size (e.g. neural segmentation tools)
• ensuring a fixed width/height aspect ratio during processing

Thus, I propose to at least introduce a descriptive annotation for derived images' scale factors:

• AlternativeImage/@imageWidth (as in Page/@imageWidth)
• AlternativeImage/@imageHeight (as in Page/@imageHeight)
• AlternativeImage/@imageXResolution (as in Page/@imageXResolution)
• AlternativeImage/@imageYResolution (as in Page/@imageYResolution)
• AlternativeImage/@imageResolutionUnit (as in Page/@imageResolutionUnit)
• AlternativeImage/@imageXScale (how much is AlternativeImage/@imageXResolution zoomed over Page/@imageXResolution?)
• AlternativeImage/@imageYScale (how much is AlternativeImage/@imageYResolution zoomed over Page/@imageYResolution?)

(Of course, the latter 2 are redundant, but pixel density might not be known exactly/reliably and thus omitted / set to zero. In that case, the scale can still describe precisely the factor between the unknown density of the original image and the unknown density of the derived image.)