研究者比较照片时，即使原件分藏于不同机构，也应当能把它们并排放在一起查看。这个朴素的愿望，道出了 IIIF（International Image Interoperability Framework，国际图像互操作框架）周边开源工具的吸引力。IIIF 标准让图像服务器与查看器能够跨越馆藏网站相互通信。[1] 沿着一张照片从存储到屏幕的过程往下看，Cantaloupe、OpenSeadragon 和 Mirador 各自的职责就会清楚起来，也能看出，一套馆藏要能跨平台使用，还需要安装查看器之外的工作。
俄亥俄大学图书馆给出了一个很适合入手的例子。它的 IIIF 指南指向一卷底片，出自 Lynn Johnson 在 1984 年承担的一项拍摄任务，内容涉及巴哈马艺术家 Amos Ferguson。档案记载，这卷底片共有 34 张，附有一张接触印样，旁边还记录了拍摄任务、摄影师、日期和地点。一张照片属于一组更完整的摄影资料。[1][2]
颜料罐、板上的画、明亮的门口，都让人想凑近细看。查看系统既要让这些细节触手可及，也要保留这一帧与原来整卷底片的联系。
先请求图像像素
IIIF Image API 为图像服务规定了一套明确的地址格式。图像标识符之后，依次跟着区域、尺寸、旋转、质量和格式的指令。以 full/1200,/0/default.jpg 结尾的请求，会要求返回宽 1,200 像素的完整图像，保持原始方向，采用默认质量，并以 JPEG 格式输出。服务的 info.json 文件说明图像尺寸和所支持的功能；客户端应先读取这些信息，确认服务支持哪些变换，再发出相应请求。[3]
即使数字展览还很简单，这套做法也已经有用。缩略图和供人细看的放大图，可以由同一份源图像响应不同请求而生成。收藏机构向外界开放稳定的图像请求方式，同时自行决定如何存储和处理图像。规范有意将这些实现细节留给部署方。[3]
Cantaloupe 是这种服务的一种开源实现。它以 Java 编写，按需生成衍生图像，支持最高至 3.0 版的 IIIF Image API。它的源模块负责读取图像，处理器负责图像操作，缓存则可保留处理结果，减少重复工作。对于从文件系统读取图像的部署，FilesystemSource.BasicLookupStrategy.path_prefix 用来指定源图像所在的目录。[4]
这个配置项指向一项基本责任：始终要有人维护图像文件，以及读取这些文件的服务。Cantaloupe 能够响应裁剪图像的请求。至于 Johnson 那卷底片应当从哪一张开始展示、拍摄任务的档案说明如何填写，则由系统的其他部分负责。
再说明读者眼前的内容
Presentation API 描述的是供人查看的馆藏对象。它的核心文档是 manifest（清单）：一份 JSON 描述，记载对象本身及其各个视图的信息。一个 Canvas（画布）代表其中一个视图，例如手稿的一页或照片的正面。注释将一幅图像关联到这个 Canvas。所描述的展示空间与实际用来呈现它的图像，由此分别表达。[5]
Johnson 的这卷底片让两者的区别变得具体。俄亥俄大学的 manifest 以接触印样开头，随后逐一列出各帧。它还列出摄影师、档案机构建议采用的引用格式等描述字段。其中的图像服务地址指向外部资源，由这些资源传送图片。JSON 文档负责组织照片的访问方式，像素数据则存放在别处。[2]
这里还有一处版本差异。这份在线档案使用 Presentation API 2，包含 sequences、canvases 和 images 字段。第 3 版则用 items 和注释页表达相应结构。底层关系依然清晰可辨，但针对一种 JSON 结构编写的代码，在读取另一种结构时仍须核对兼容性。[2][5]
因此，图像 URL、info.json URL 和 manifest URL 各有用途，使用时须加以区分。俄亥俄大学图书馆的这份独立指南明确区分了图像链接与 manifest 链接。在我看来，这个细小的教学安排恰好点明了整套工具协作的基本约定：访问图片和了解图片的背景，各自需要一个可用的地址。[1]
按任务选择查看工具
OpenSeadragon 是用于查看高分辨率图像的 JavaScript 工具。它支持多种图像服务协议，IIIF 是其中之一。开发者若要设计以缩放和平移为主的界面，可以借助它的控件、叠加层和插件系统，将它作为其中的组件。[6]
Mirador 则面向研究工作区。它能展示 manifest、显示描述信息，并将来自不同资源库的资料并排放置。Image API 和 Presentation API 的第 2 版与第 3 版，它都支持。创建注释需要插件。[7] 如果一个部署承诺保留研究者的笔记，还须配备相应的保存方式。[8]
这些部分的分工如下：
| 组件 | 所负责的内容 | 馆藏团队须安排的工作 |
|---|---|---|
| Cantaloupe | 按请求生成衍生图像 | 源图像存储、配置和服务运维 |
| Presentation manifest | 描述、视图顺序和资源链接 | 准确的元数据与持久标识符 |
| OpenSeadragon | 可缩放的图像界面 | 查看图像之外的馆藏浏览体验 |
| Mirador | 查看 manifest、比较资料的工作区 | 可用的资源链接，以及注释的持久化保存安排 |
表中列出的是一种开源组合方案，并未据此认定俄亥俄大学的档案使用了 Cantaloupe。还有一种更轻量的选择：预先生成不同尺寸的图像和图像切片，再交由普通 Web 服务器发布，就能实现符合 level 0 的 Image API 服务，也包括深度缩放功能。[8]
馆藏团队仍有工作要做
对于只有一名兼职开发者的小型档案机构，我会建议先选一个有代表性的馆藏对象：包含几个视图、有用的描述，以及一张较难处理的图像。添加服务之前，先查清现有资源库是否已经能导出 manifest。实施指南指出，编制一份 manifest 时，有时需要汇集机构内多个系统的信息；页序上的分歧，增加图像处理能力也无从解决。[8]
运营动态图像服务器的团队，应明确缓存和源图像访问分别由谁负责。Cantaloupe 有多种缓存后端，处理器也可配置，运维工作量取决于具体组合。[4] 衡量这些工作时，要用馆藏实际的扫描图像，以及预期的浏览行为。频繁被查看的接触印样与很少被打开的单张照片，可以产生不同的请求模式。
随后，在另一个域名托管的查看器中打开 manifest。这是我建议采用的验收检查，因为它直接检验了最初促成这项工作的愿望。HTTPS 和跨源资源共享在这里都很重要：若浏览器规则限制跨域访问，其他查看器就会无法获取资源，即使馆藏在自己的网站上看起来运转正常。[8]
最后，还要分清展示馆藏对象与找到它这两件事。Presentation API 明确将馆藏发现和对象内部搜索排除在核心范围之外。标题清楚、Canvas 排列有序，只完成了展示层面的工作；要让档案可供搜索，还需要其他环节。[5]
对读者而言，收获更为直观。一张照片可以与另一家机构的照片并排出现，照片的标识信息依然可查，细节也能放大到足以仔细审视。当馆藏给出可靠的地址、有用的描述，并让图像持续响应请求时，开源工具就能为读者打开这样一间阅览室。
资料来源
- 俄亥俄大学图书馆，《查找与使用 IIIF 图像》——区分图像链接与 manifest 链接的独立机构指南，以 Lynn Johnson 馆藏为例。
- 俄亥俄大学图书馆，“巴哈马民间艺术家 Amos Ferguson 及其他人，1984：第 113145-C 卷，34 张底片及接触印样”的 IIIF manifest——档案元数据、按序编排的各帧及图像服务地址。
- IIIF 联盟，《Image API 3.0》——请求语法、图像信息、符合性及实现范围。
- Cantaloupe Image Server 项目文档——动态衍生图像、源模块、处理器、缓存和文件系统配置。
- IIIF 联盟，《Presentation API 3.0》——manifest、Canvas、注释、第 3 版结构及适用范围限制。
- OpenSeadragon 项目文档——JavaScript 图像查看器、支持的切片来源、控件与插件。
- Project Mirador 项目文档——资料比较工作区、API 支持、元数据显示及注释插件。
- IIIF，《IIIF 实施指南》——静态与动态图像服务、manifest 生成、查看器选择、HTTPS 和跨源访问。