IIIF Image API

Using the IIIF Image API

Image Request

Info

See the IIIF Image API reference v2.1 or v3.0 for further details on the URI syntax (region, size, rotation, quality and format).

The IIIF Image API URI for requesting an image defines the following URI Template:

{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}

For the University Library IIIF Server, the {scheme}://{server} part is https://iiif.ub.unibe.ch followed by /image/{version} as {prefix} where version is either v2.1 or v3.0. For the following examples we will use v3.0 as {version} (https://iiif.ub.unibe.ch/image/v3.0/...)

There are two ways on the University Library IIIF Server to call a specific image:

• By image identifier
  Here the ID of the image is used as identifier to call the IIIF Image API:
  Example with image ID e61b22ed-3d94-4322-9633-e4b9a3df1def:
  https://iiif.ub.unibe.ch/image/v3.0/e61b22ed-3d94-4322-9633-e4b9a3df1def/full/max/0/default.jpg
  The ID of the image can be found in the Image View) or in the CSV export created in the Collection or Sequence View).

• By project slug and image source file name
  Here the project slug will be added to the {prefix} value:
  Example with project slug my-project: https://iiif.ub.unibe.ch/image/v3.0/my-project/...
  As image identifier the image source file name (original file name in import, unique within a project) is used.
  Example with project slug haller and source file name gga_00001_001.tif:
  https://iiif.ub.unibe.ch/image/v3.0/haller/gga_00001_001.tif/full/max/0/default.jpg
  The slug of the project can be found on the Project View), the source file name of the image can be found in the Image View). Both information can also be found in the CSV export created in the Collection or Sequence View).

Info

When using the variant with the project slug and image source file name, a HTTP redirect to the first variant (image identifier) will be created. This means for every such request to the image API the browser has to do a second request. This causes a minimal delay (microseconds) on each request and increases the load on the web server. We recommend to use the first variant whenever possible.

Image Information Request

Info

See the IIIF Image API reference v2.1 or v3.0 for further details on the URI syntax.

The IIIF Image API URI for requesting an image defines the following URI Template:

{scheme}://{server}{/prefix}/{identifier}/info.json

For the University Library IIIF Server, the {scheme}://{server} part is https://iiif.ub.unibe.ch followed by /image/{version} as {prefix} where version is either v2.1 or v3.0. For the following examples we will use v3.0 as {version} (https://iiif.ub.unibe.ch/image/v3.0/...)

There are two ways on the University Library IIIF Server to call a specific image information:

• By image identifier
  Here the ID of the image is used as identifier to call the IIIF Image API:
  Example with image ID e61b22ed-3d94-4322-9633-e4b9a3df1def:
  https://iiif.ub.unibe.ch/image/v3/e61b22ed-3d94-4322-9633-e4b9a3df1def/info.json
  The ID of the image can be found in the Image View) or in the CSV export created in the Collection or Sequence View).
• By project slug and image source file name
  Here the project slug will be added to the {prefix} value:
  Example with project slug my-project:
  https://iiif.ub.unibe.ch/image/v3.0/my-project/...
  As image identifier the image source file name (original file name in import, unique within a project) is used.
  Example with project slug haller and source file name gga_00001_001.tif:
  https://iiif.ub.unibe.ch/image/v3/haller/gga_00001_001.tif/info.json
  The slug of the project can be found on the Project View), the source file name of the image can be found in the Image View). Both information can also be found in the CSV export created in the Collection or Sequence View).

Warning

When using the variant with the project slug and image source file name, a HTTP redirect to the first variant (image identifier) will be created. This means for every such request to the image API the browser has to do a second request. This causes a minimal delay (microseconds) on each request and increases the load on the web server. We recommend to use the first variant whenever possible.