This is a fork @greut's iiif package that moves most of the processing logic in to discrete Go packages and defines source, derivative and graphics details in a JSON config file. There is an additional caching layer for both source images and derivatives.
I did this to better understand the architecture behind (and to address my own concerns about) version 2 of the IIIF Image API.
For the time being this package will probably not support the other IIIF Metadata or Publication APIs. Honestly, as of this writing it may still be lacking some parts of Image API but it's a start and it does all the basics.
And by "forked" I mean that @greut and I decided that it was best for this code and his code to wave at each other across the divide but not necessarily to hold hands.
Currently all the image processing is handled by the bimg Go package which requires the libvips C library be installed. There is a detailed setup script available for Ubuntu. Eventually there will be pure-Go alternatives for wrangling images. Otherwise all other depedencies are included with this repository in the vendor directory.
Once you have things likeGo and libvips installed just type:
$> make bin
go-iiif was designed to expose all of its functionality outside of the included tools although that hasn't been documented yet. The source code for the iiif-tile-seed tool is a good place to start poking around if you're curious.
iiif-server is a HTTP server that supports version 2.1 of the IIIF Image API. For example:
$> bin/iiif-server -config config.json
2016/09/01 15:45:07 Serving 127.0.0.1:8080 with pid 12075
curl -s localhost:8080/184512_5f7f47e5b3c66207_x.jpg/full/full/0/default.jpg
curl -s localhost:8080/184512_5f7f47e5b3c66207_x.jpg/125,15,200,200/full/0/default.jpg
curl -s localhost:8080/184512_5f7f47e5b3c66207_x.jpg/pct:41.6,7.5,40,70/full/0/default.jpg
curl -s localhost:8080/184512_5f7f47e5b3c66207_x.jpg/full/full/270/default.png
Please write me
Please write me
Please write me
$> curl -s 127.0.0.1:8080/debug/vars | python -mjson.tool | grep Cache
"CacheHit": 4,
"CacheMiss": 16,
"CacheSet": 16,
$> curl -s 127.0.0.1:8080/debug/vars | python -mjson.tool | grep Transforms
"TransformsAvgTimeMS": 1833.875,
"TransformsCount": 16,
- TLS is not supported yet.
$> ./bin/iiif-tile-seed -options /path/to/source/image.jpg
Usage of ./bin/iiif-tile-seed:
-config string
Path to a valid go-iiif config file
-refresh
Refresh a tile even if already exists (default false)
-scale-factors string
A comma-separated list of scale factors to seed tiles with (default "4")
There is a sample config file included with this repo. Proper documentation is being written but right now the easiest way to understand config files is that consist of five top-level groupings, with nested section-specific details. They are:
"level": {
"compliance": "2"
}
Indicates which level of IIIF Image API compliance the server (or associated tools) should support. Basically, there is no reason to ever change this right now.
"graphics": {
"source": { "name": "VIPS" }
}
Details about how images should be processed. Because only libvips is supported for image processing right now there is no reason to change this.
"features": {
"enable": {},
"disable": { "rotation": [ "rotationArbitrary"] },
"append": {}
}
"images": {
"source": { "name": "Disk", "path": "example/images" },
"cache": { "name": "Memory", "ttl": 300, "limit": 100 }
}
Details about source images.
Where to find source images.
Possible cache sources for source images are:
- Disk - A locally available filesystem.
Planned future source providers include reading images via S3 or an OEmbed endpoint.
The path to a valid directory to find source images.
Caching options for source images.
Possible cache sources for source images are:
-
Disk - Cache images to a locally available filesystem. Until it is possible to read source A349 images from a remote location it's not clear why you would ever do this but I guess that's your business...
-
Memory - Cache images in memory.
-
Null – Because you must define a caching layer this is here to satify the requirements without actually caching anything, anywhere.
This is only valid for Memory caches and indicates the maximum number of seconds an image should live in cache.
This is only valid for Memory caches and indicates the maximum number of megabytes the cache should hold at any one time.
"derivatives": {
"cache": { "name": "Disk", "path": "example/cache" }
}
Details about derivative images.
Caching options for derivative images.
Possible cache sources for derivative images are:
-
Disk - Tache derivatives to a locally available filesystem.
-
Memory - Cache images in memory.
-
Null – Because you must define a caching layer this is here to satify the requirements without actually caching anything, anywhere.
Planned future caching providers include writing derivatives to S3.
This is only valid for Memory caches and indicates the maximum number of seconds an image should live in cache.
This is only valid for Memory caches and indicates the maximum number of megabytes the cache should hold at any one time.
The API specifications can be found on iiif.io.
filename: the name of the file (all the images are in one folder)
full: the full imagesquare: a square area in the picture (centered)x,y,w,h: extract the specified region (as pixels)pct:x,y,w,h: extract the specified region (as percentages)
full: the full image (deprecated)max: the full imagew,h: a potentially deformed image ofw x h(not supported)!w,h: a non-deformed image of maximumw x hw,: a non-deformed image withwas the width,h: a non-deformed image withhas the heightpct:n: a non-deformed image scaled bynpercent
na clockwise rotation ofndegrees!na flip is done before the rotation
limitations bimg only supports rotations that are multiples of 90.
colorimage in full colourgrayimage in grayscalebitonalimage in either black or white pixels (not supported)defaultimage returned in the server default quality
jpgpngwebptiff
limitations : bimg (libvips) doesn't support writing to jp2, gif or pdf.
It provides all informations but the available sizes and tiles. The sizes
information would be much better linked with a Cache system.
It provides meta-informations about the service. (incomplete)