dinglehopper icon indicating copy to clipboard operation
dinglehopper copied to clipboard
verified publisher icon qurator-spk

Display image

Open mikegerber opened this issue 6 years ago • 5 comments

The tool should display an image corresponding to the text line/OCR error selected.

I'll probably use the local images to display, not IIIF as this seems more general.

  • [x] Explore ~JS~CSS possibilities to crop images
  • [x] What about TIFF support in the browser? Or mandate converting to PNG/JPEG?
  • [ ] Implement it

mikegerber avatar Dec 06 '19 12:12 mikegerber

I may be missing sth, but those are actually all reasons for using IIIF ;)

  • Cropping images is done server-side via API request, you directly get the snippets returned based on the coordinates already present in the OCR files
  • Contrary to downloading the image and doing some cutting/preprocessing locally (how?), IIIF does all that for you in the request
  • The returned image snippets work across browsers
  • The functionality is based on an established and internationally used API standard, which seems much more general to me
  • Everyone with IIIF Image API can use the feature, they only need to supply the baseURL for the IIIF API (e.g. via parameter/config file)
  • We already have a working JS implementation for this in neat

I could probably think of more reasons pro IIIF.

cneud avatar Jun 09 '20 18:06 cneud

Reasons I am contemplating only working with local files:

  • I am almost exclusively working with local files
  • The SBB has no IIIF in the METS files (All the IIIF I have in the files is from URLs I manipulated myself)
  • IIIF is not even (cleanly) detectable if there were IIIF URLs in there
  • So IIIF would require extra configuration (baseURL)
  • Working with the local files would "just work", at least for OCR-D workspaces where I can tell OCR-D to download the files locally
  • What about non-IIIF workspaces/files?
  • The implementation in neat may work but I don't see how to use it, i.e. cropping using CSS is just as easy

Not the last word spoken, but I tend to work with local files. Even TIFF support looks doable.

mikegerber avatar Jun 15 '20 16:06 mikegerber

CSS experiments:

https://qurator-data.de/~mike.gerber/experiments/image-cropping-using-css/image-cropping-using-css.html

This means:

  • Cropping using CSS is easy
  • No TIFF

mikegerber avatar Jun 17 '20 11:06 mikegerber

https://qurator-data.de/~mike.gerber/experiments/image-cropping-using-css/image-cropping-using-css.html

Based on your example, here is how this can also be done serverside just with the pixel information you already have in the OCR and an awesome API.

E.g. the IIIF-URL for your example looks like this:

{baseurl}/{identifier}/{x,y,w,h}/{size}/{rotation}/default.{jpg|png|tif}

https://content.staatsbibliothek-berlin.de/dc/PPN77164308X-00000001/149,450,1244,228/1200,/0/default.jpg

50% scaled:

https://content.staatsbibliothek-berlin.de/dc/PPN77164308X-00000001/149,450,1244,228/600,/0/default.jpg

Or get PNG

https://content.staatsbibliothek-berlin.de/dc/PPN77164308X-00000001/149,450,1244,228/600,/0/default.png

Even TIF! - except it wont render in any web browser ;)

https://content.staatsbibliothek-berlin.de/dc/PPN77164308X-00000001/149,450,1244,228/600,/0/default.tif

If you replace {baseurl}{identifier} with those of any other institution that implements the IIIF Image API, this will always work.

See just a few example (different documents of course)

BSB https://api.digitale-sammlungen.de/iiif/image/v2/bsb00103155_00013/149,450,1244,228/1200,/0/default.jpg https://api.digitale-sammlungen.de/iiif/image/v2/bsb00103155_00013/149,450,1244,228/600,/0/default.jpg https://api.digitale-sammlungen.de/iiif/image/v2/bsb00103155_00013/full/full/0/default.jpg

ÖNB https://iiif.onb.ac.at/images/ABO/Z165851607/00000001/149,450,1244,228/1200,/0/default.jpg https://iiif.onb.ac.at/images/ABO/Z165851607/00000001/149,450,1244,228/600,/0/default.jpg https://iiif.onb.ac.at/images/ABO/Z165851607/00000001/full/full/0/default.jpg

BnF Gallica https://gallica.bnf.fr/iiif/ark:/12148/btv1b9055204k/f1/149,450,1244,228/1200,/0/default.jpg https://gallica.bnf.fr/iiif/ark:/12148/btv1b9055204k/f1/149,450,1244,228/600,/0/default.jpg https://gallica.bnf.fr/iiif/ark:/12148/btv1b9055204k/f1/full/full/0/default.jpg

There are a few hundred libraries, museums and archives worldwide that implement this, and growing.

There are Python libraries for it:

  • https://github.com/zimeon/iiif
  • https://github.com/Princeton-CDH/piffle

Bottom line - IIIF is fun ;)

cneud avatar Sep 26 '20 00:09 cneud

The problem is: How do I know the IIIF URL?

  1. In my example (https://qurator-data.de/~mike.gerber/experiments/image-cropping-using-css/PPN77164308X/mets.xml) there are IIIF URLs in the BEST file group. Not because they were in the original, but because I put them there using ppn2ocr.
  2. How do I know these are IIIF URLs other than guessing?

Thinking about it, the first idea is following

  • OCR-D interface

    • If the user tells me to use IIIF, dinglehopper will assume that the URLs in the filegroup are IIIF and use that
    • If input is PNG/JPG, use CSS cropping
    • Otherwise complain that we can't display TIFF

  • CLI interface

    • If the user gives IIIF URL, use that
    • If input (read from PAGE XML) is PNG/JPG, use CSS cropping
    • Otherwise complain that we can't display TIFF

To be honest, if the browsers would support TIFF I would not consider IIIF at all because cropping an image is trivial and supporting IIIF here just adds complexity by requiring a IIIF URL etc.

mikegerber avatar Sep 29 '20 17:09 mikegerber