Matching PAGE imageFilename to mets:file when imageFilename is not a URL

Scenario:

1. Image files and PAGE referencing those image files by relative filepath:

   <Page imageFilename="foo.tif"/>
   

2. Create a METS file and run workspace add:

   <mets:file GROUPID="page0001" xlink:href="file://path/to/bla/foo.tif"
   

Now the PAGE imageFilename and xlink:href of the corresponding mets:file do not match anymore.

[kba]

Revisiting this with @tboenig:

• imageFilename in PAGE must always be a relative file path relative to that PAGE file, otherwise tools like Aletheia or PAGEViewer won’t work
• mets:FLocat is ideally a relative path from the mets.xml

So we need logic to determine the relative path from mets.xml to image by resolving imageFilename of a PAGE against the relative path to that PAGE.

• mets.xml: OCR-D-PAGE/foo.xml
• OCR-D-PAGE/foo.xml: …/OCR-D-IMG/foo.tif
• => OCR-D-IMG/foo.tif <- mets:FLocat of that image in mets.xml

[bertsky]

* Moving images and PAGE to the workspace will require changing the input PAGE. Not really a question, just a statement

Yes, that’s crucial. If we take this seriously, ocrd workspace add on PAGE-XML files will either take control of that file or make a copy of it (under the “right” path).

* Also do this for AlternativeImage? Does anyone beside us even use them? I suppose yes and no.

I guess we have to consider the possibility. If we solve this conceptually for Page/@imageFilename, it should work the same for AlternativeImage/@filename though.

* How to determine file metadata for the `imageFilename`? Media Type can be guessed but what `mets:fileGrp` to add the images to? Maybe the filegroup used as the input plus suffix `-IMG`?

IIUC you assume here that ocrd workspace add will be responsible for adding the image file along with the PAGE-XML file passed to it. We could have other provisions (like assuming the image file must already have been added by then), but let’s follow this logic for now:

Yes, the image could be placed under a fileGrp implicitly derived from the fileGrp for the PAGE-XML, or even the same fileGrp (just with a different MIME type and not appearing in the structMap).

Let’s make it toggleable with a --include-page-images/–no-include-page-images or similar flag.

If we add an option, why not just the name of the image file group (or none for “ignore images”)?

* Any issues that arise from necessary conventions for this are the user's responsibility, i.e. if they want to set a different name or different media type for an image, they either need to post-process the XML themselves or not use this feature and do the image adding themselves as before

Right. And let’s think about the second use-case (adding PAGE-XML after image) more thoroughly: Now ocrd workspace add can go looking for the (basename of the) filename in the (image) flocat URLs of the METS, and calculate the new relative path for the PAGE-XML under its destination directory. If it does not find an image with that filename, it can still go looking for an image with the same pageId. And then it can fail loudly.

Personally, I think this is the more sensible interface than add-image-via-PAGE.

Let’s default NOT to do this because it really only makes sense when importing data, not. e.g everytime a bashlib processor wants to add an image.

This got me confused: I though we are talking about adding PAGE-XML files here?