Blog posts tagged iiif

zoomable.images.js

We’ve updated the user interface elements that control how a static image can be made “zoomable” making them easier to use and more portable across a number of different settings.

This is a blog post by aaron cope. It was published on September 14, 2020 and tagged iiif, javascript and zoomable.

Geotagging at SFO Museum, Part 5 – Images

If the go-www-geotag application is designed to be agnotic to the details of any one user’s data sources how does it know where to find and load the images it’s meant to geotag? Isn’t this exactly the problem I described in the first post in this series, a scenario where the go-www-geotag application is required to know about an infinite number of image sources? Rather than trying to support a potentially infinite list of image sources we’ve decided to require the use of the oEmbed standard as the means by which images are identified and loaded in to the application.

This is a blog post by aaron cope. It was published on April 29, 2020 and tagged sfo, collection, geotagging, oembed and iiif.

Zoomable” images at SFO Museum

In the future we’ll do another more technical blog post about how the image tiling works but today’s post is about celebrating the ability to “wander around” an image, to get up close and enjoy its details.

This is a blog post by aaron cope. It was published on February 03, 2020 and tagged sfo, iiif and zoomable.

go-iiif version 2.1

Longer-term, and importantly, it also means the workflows we develop aren’t inextricably bound to Amazon services. Knowing that we don’t have to use AWS and knowing that there is an alternative avenue for accomplishing the same work in the future, should we ever need it, goes a long way towards making it easier for us to want to use AWS in the present.

This is a blog post by aaron cope. It was published on December 05, 2019 and tagged aws, golang and iiif.

go-iiif version 2.0

I am happy to announce that go-iiif version 2.0 has been released. The biggest change in this release is that go-iiif no longer requires the libvips image processing library, by default. As of version 2.0 go-iiif can do all its image processing using native (Go) code. The absence of external dependencies means that go-iiif tools can be compiled in to standalone applications that can be run even if Go isn’t installed on the same computer.

This is a blog post by aaron cope. It was published on November 13, 2019 and tagged golang and iiif.

Using IIIF (with AWS) at SFO Museum

At the end of that first blog post about go-iiif we wrote “An ideal scenario is one where a museum could upload a set of full-sized images to a AWS S3 bucket, wait for Amazon’s computers to process each image … and then find a new set of images to download (along with a reasonable bill for services rendered) in a different S3 bucket.” Today, that is possible.

This is a blog post by aaron cope. It was published on February 12, 2019 and tagged iiif, golang and aws.

Using IIIF at SFO Museum

This is a technical blog post about image processing. The short non-technical summary is that not only were we able to use open source software to simplify our image processing workflow (and reduce costs) but we contributed our improvements back to the project so that hopefully others in the museum sector may benefit from our work. Yay!

This is a blog post by aaron cope. It was published on July 18, 2018 and tagged golang and iiif.