Comment "cropped" is used by deskewing (for non-cropped pages)

[wrznr]

Running

ocrd-tesserocr-deskew -m mets.xml -I ORIGINAL -O DESKEW -p <(echo '{"operation_level": "page"}')

results in

<?xml version="1.0" encoding="UTF-8"?>
<pc:PcGts xmlns:pc="http://schema.primaresearch.org/PAGE/gts/pagecontent/2018-07-15">
    <pc:Metadata>
        <pc:Creator>OCR-D/core 1.0.0b10</pc:Creator>
        <pc:Created>2019-07-09T15:37:12.528892</pc:Created>
        <pc:LastChange>2019-07-09T15:37:12.528892</pc:LastChange>
        <pc:MetadataItem type="processingStep" name="preprocessing/optimization/deskewing" value="ocrd-tesserocr-deskew">
            <pc:Labels>
                <pc:Label value="page" type="operation_level"/>
            </pc:Labels>
        </pc:MetadataItem>
    </pc:Metadata>
    <pc:Page imageFilename="https://digital.slub-dresden.de/data/kitodo/GottDie_453779263/GottDie_453779263_tif/jpegs/00000033.tif.original.jpg" imageWidth="1187" imageHeight="1687" readingDirection="left-to-right" textLineOrder="top-to-bottom">
        <pc:AlternativeImage filename="OCR-D-IMG-DESKEW/FILE_0033_OCR-D-IMG-DESKEW.png" comments="cropped"/>
    </pc:Page>
</pc:PcGts>

The comment should be deskewed, right?

[kba]

ag comments

ocrd_tesserocr/deskew.py:121:9:        comments = 'cropped'

[bertsky]

No, it should actually be empty. In this case deskewing found angle zero, so the comment does not contain "deskewed". The "cropped" is the default, because the processor always crops from the next-higher level (which happens to be nothing here, because we are on the page and no Border is present).

But I probably just misinterpreted "cropped" in the spec anyway, right?

[kba]

While technically correct, it won't help the user much if the image is marked as cropped but is not actually. I would not set the default value to cropped. Makes concatenating a bit more cumbersome because having to check whether to append with a comma or not.

[bertsky]

Thanks @kba – and welcome back!

So my interpretation of cropped is not in fact wrong? (I considered it to be true after some PIL.Image.crop. But one might consider only page-level cropping to consitute the case for cropped.)