chapter 3 歴史データをつなぐこと −画像データ−(中村 覚)★『歴史情報学の教科書』全文公開
Tweet
chapter3
歴史データをつなぐこと
−画像データ−
中村 覚(東京大学情報基盤センター)
1. はじめに
本章は画像データを扱います。まず、2において、画像データの基礎について説明します。次に、3において、画像データを共有するための国際的な枠組みであるIIIF(International Image Interoperability Framework)について説明します。
2. 画像データの基礎
ここでは画像データに関する用語や画像フォーマットについて説明します。なお、本項は、「国立国会図書館資料デジタル化の手引2017年度版」[01]を参考に執筆しています。
2.1. 解像度
資料をスキャンすることによって作成した画像データは、ディスプレイ上では、ピクセル(画素)と呼ばれる画像データを構成する最小単位の点で表現されます。画像データは、このピクセルが縦横に規則正しく並んでいます。この点の細かさを示す尺度を解像度と呼びます。通常、解像度と画質は比例します。
図1 解像度の違い
図2 RGB(左)とCMYK(右)
この解像度は、1インチ(25.4mm)内のピクセル数を示すPPI(pixel per inch)という単位で表現されます。また、画像データのサイズは画像の縦横のピクセル数で表されます。入出力機器(プリンターなど)では、1インチあたりに集まる物理的なドットの密度を表す単位であるdpi(dots per inch)と表記されることもあります。
例えば図1に示した各画像の辺の長さが1インチの場合、左から1マスの幅=1dpi、2マスの幅=2dpi、右端が100マスの幅=100dpiとなります。
2.2. カラースペース
カラースペースは色空間やカラーモデルとも呼ばれ、色を作り出す方法またはその範囲を意味します。代表的なカラースペースとして、RGB、CMYKなどがあります(図2)。
RGBは光の3原色である赤(Red)、緑(Green)、青(Blue)で色を表現します。各色が混ざる程明るい色になり、最終的には白になることから加法混色といわれます。コンピュータのスクリーンの多くは、この仕組みを用いています。
CMYKはインクの3原色である藍(Cyan)、紅(Magenta)、黄(Yellow)と黒(Key Plate)で色を表現します。これらの色を混ぜるほど色が暗くなり、最終的には黒に近くなることから、減法混色といわれます。印刷やコンピュータのプリントの多くは、この仕組みを用いています。
2.3. 色深度(ビット深度)
ビットとはコンピュータの中で扱う情報の最小単位です。1ビットで2進数の1桁が0か1かを表すことができます。色深度は1ピクセルあたりの色の情報量を示します。一般的に1ピクセルあたりのビット数で表現され、単位としてbpp(bits per pixel)などが用いられます。
白黒の画像には、1ビットカラーと呼ばれる白および黒の2色のみで画像を表現するものや、グレースケールという中間色を含んで画像を表現するものがあります。8ビットグレースケールとは、白から黒までの色を2=256通りで表現するものです。
カラーの画像は、色相、彩度、明度の色の3要素を使用して表現します。色相は色合いの違い、彩度は色の鮮やかさ、明度は色の明るさを意味します。インデックスカラーと呼ばれる256色(8ビット)のものや、フルカラーと呼ばれる1667万色以上(24ビットフルカラー)のものなどがあります。
2.4. 画像フォーマット
画像データのフォーマットには、RAW、TIFF、JPEG、JPEG2000、GIF、PNGなどがあります。以下、これらの画像フォーマットについて説明します。
RAWはデジタルカメラなどで撮影した際の生データで、現像することでほかのフォーマットの画像を作成することができます。
TIFF(Tagged Image File Format)は、マイクロソフト社とアルダス社(アドビシステムズ社に合併)によって開発されたフォーマットです。非圧縮画像のためデータのサイズが大きくなりますが、品質劣化がないため、圧縮画像を作成する際の元データとして利用されます。画像データベースや保存用に使用する画像フォーマットのデファクトスタンダードとして認知されています。
JPEG(Joint Photographic Experts Group)は、圧縮率に優れた画像フォーマットです。そのため、Webサイトの写真画像などの公開用画像として標準的に利用されます。高い圧縮率が特徴ですが、非可逆圧縮(圧縮前のデータと、圧縮・展開を経たデータとが完全には一致しないデータ圧縮方式)であるため、圧縮を行うと元の画像情報を完全に復元することができません。
JPEG2000は、JPEGの後継規格です。ファイルサイズの指定、電子透かし、メタデータの付与機能など、多くの機能に対応しています。非可逆圧縮のJPEGとは異なり、可逆圧縮も可能です。一方、比較的新しい規格であるため、Internet ExplorerやFireFoxなどのブラウザはまだ標準では対応していない、画像を閲覧する際には別途プラグインを導入する必要がある、などの課題もあります。保存用画像、公開用画像の両者の目的で使用されます。
GIF(Graphics Interchage Format)は、Webサイトのアイコンなどによく用いられます。色表現は8ビット(256色パレット)に対応しています。写真などの高精彩画像の保存には向いていませんが、動画や簡単な透明色を用いた画像を作ることができる点が特徴としてあげられます。圧縮方式は可逆圧縮です。
PNG(Portable Network Graphics)は、GIFに替わる画像フォーマットとしてW3Cから勧告されました。色表現は8ビットのGIFとは異なり、人の識別能力を上回る48ビットまで対応しています。圧縮方式はJPEGのように画像の劣化がともなう非可逆圧縮ではなく、可逆圧縮です。そのため、透明色を用いた画像や可逆圧縮を重視したい画像に適しています。一方、ファイルサイズが大きくなりがちな点に注意が必要です。
3. IIIF(International Image Interoperability Framework)
3.1. はじめに
1990年代よりインターネットの普及が進み、博物館や図書館、文書館、大学などの世界中の機関において、所蔵資料のデジタルデータの公開が進められています。しかし、これまでは画像データの公開方法は統一されておらず、基本的に利用者は各機関が提供する専用のビューアなどを用いて画像を閲覧する必要がありました。この結果、例えば異なる機関で公開されている画像との比較などは容易ではなく、また利用者は個々のシステムの公開形式に合わせて、操作方法の習熟やプログラム開発を行う必要がありました。これは利用者だけでなく、画像データを公開する機関、提供者側にもデメリットを生んでいました。例えば「より高解像度の画像をより高速に提供可能な画像サーバがほしい」「閲覧者が画像に注釈を付与できるようにしたい」といったニーズは、機関を問わず共通に抱える課題です。しかし、これまでは個々の機関がそれぞれ異なるシステムを使用していたため、これらの課題を解決するためのソフトウエアやツールを、おのおのの機関で開発、改善する必要がありました。
このような画像データのアクセスにおける共通の課題の解決を目的として、2011年に大英図書館やスタンフォード大学、オックスフォード大学ボドリアン図書館、フランス国立図書館などの機関が中心となり、画像データの相互運用のための一連の技術仕様、APIを策定しました。この技術仕様の総称がIIIFです。データ提供機関が共通のAPIに従って画像データを公開することにより、これを利用するソフトウエアやツールも共通の仕組みで開発することが可能となります。
なお、IIIFという用語は、画像の相互運用性に関する課題を開発するための、ソフトウエア、ツール、コンテンツ、人、および機関のコミュニティを指す用語としても使われますが、本章では一連の技術仕様を指す用語として使用します。
IIIFの採用は世界的に広がりつつあり、2018年10月現在において、国内外600以上の機関がIIIFを採用しているといわれています。また、日本国内においても、東京大学や京都大学、国立国会図書館、国文学研究資料館、国立歴史民俗博物館などでIIIFが採用されています。
以下では、このIIIFの仕組みや活用例について説明します。
3.2. IIIFの仕様
IIIFの仕様の一覧は(https://iiif.io/api/#current-specifications)で公開されています。2018年10月現在では、Authentication API(1.0.0)、Image API(2.1.1)、Presentation API(2.1.1)、Search API(1.0.0)の4種類です。これらのうち、先行して開発され、すでに広く普及しているImage APIとPresentation APIについて説明します。
3.2.1. Image API
Image APIは、画像を要求し配信するための標準化された方法を提供します。次の構文を持つURIのテンプレートを使用して画像を要求することで、さまざまな状態の画像を習得することができます。
{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}
本APIを用いた画像の操作例を図3に示します。上記テンプレートの{region}や{size}、{rotation}、{quality}の値を変更することで、それぞれ縮小・拡大、部分切り出し、回転、グレースケール化などを行うことができます。図3左上は縮小・拡大処理の例で、{size}の値に「150,」を与えることで、幅150pxの画像を取得しています。また、図3右下の例では、{quality}の値に「gray」を与えることで、グレースケール化を行っています。
図3 Image APIを用いた画像の操作例[02]
なお、Image APIはIIIFの仕様においては、後述するPresentation APIから画像を利用するために機能していますが、このImage API単体でも利用することができます。
3.2.2. Presentation API
Presentation APIは、「資料オブジェクト」(例えば、図4左のように、複数の画像から構成される一資料)の構造とレイアウト情報を記述するためのJSONフォーマットを定義します。JSON(JavaScript Object Notation)はテキストベースのデータフォーマット形式です。
画像情報の表示方法が標準化されることで、例えば図4に示すように、同じ資料オブジェクトを異なるビューアで表示することや、別の資料オブジェクトと並べて比較することが可能になります。ビューアについては次節で紹介しますが、図4左がUniversal Viewerで表示した例、右がMiradorを用いて複数の画像を並べて表示している例を示しています。
図4 Presentation APIを用いた画像の表示例(左:Universal Viewer, 右:Mirador)
Presentation APIに従ったJSONの記述方法の詳細については割愛しますが、基本的な資料オブジェクトの関係とJSONの記述例を図5に示します。Presentation APIでは、資料オブジェクト全体を表す要素をマニフェスト(Manifest)と呼びます。多くの場合はひとつのJSONファイルはひとつの資料オブジェクトを表現します。また一般に、このJSONファイルもマニフェストと呼ばれます。このマニフェストは、共有キャンバス(Shared Canvas)という概念に基づいており、ひとつのキャンバスに画像など(図5中の「Content」)が付与され、そのキャンバスの集合がひとつの資料オブジェクトの構成要素となります。
図5 基本的な資料オブジェクトとマニフェストJSONの例[03]
3.3. IIIFソフトウエア
開発されているIIIFソフトウエアのほとんどはオープンソースで、Awesome-IIIF(https://github.com/IIIF/awesome-iiif)のリストから見つけることができます。このようにIIIFに対応したオープンソースソフトウエアが数多く開発されています。これがIIIFの使い勝手を向上させ、さらに利用者が増えるという好循環を生んでいます。
典型的なIIIFの要求と応答のサイクルは、図6のようになります。この要求応答サイクルは、IIIFクライアントがn個の画像からなる資料オブジェクトを表示したい、という基本パターンを示しています。IIIFクライアント / ビューアは、IIIFマニフェストサーバにマニフェストを要求します。次に、クライアントはマニフェストを解析し、表示したい各画像について、IIIF画像サーバからinfo.jsonを要求します。info.jsonには、寸法、使用可能な画像サーバのオプション、利用可能なタイルレベルなど、画像に関する情報が含まれています。クライアントはこの情報を使用し、さらに実際に表示する画像をサーバから取得します。
図6 IIIFの要求と応答のサイクルの例
3.3.1. IIIFマニフェストサーバ
IIIFマニフェストは静的または動的コンテンツとして提供されます。
静的コンテンツとしての提供では、サーバ上にマニフェストJSONファイルを格納する方法です。クライアントは当該ファイルにアクセスし、画像の表示方法などに関する情報を取得します。
動的コンテンツとしての提供では、クライアントからの要求ごとに、マニフェストを生成して返却します。この場合、動的にマニフェストを生成する仕組みを持つソフトウエアなどが必要になります。
例えば、ジョージ・メイソン大学のRoy Rosenzweig Center for History and New Mediaを中心に開発されているオープンソースのコンテンツ管理システム(CMS)であるOmeka[04]は、テーマやプラグインを使ってさまざまな機能拡張を行うことができます。このプラグインのひとつである「IIIF Server」[05]は、システムに登録された画像とメタデータからマニフェストを動的に生成する機能を提供しています。
3.3.2. IIIF画像サーバ
画像サーバには、info.jsonの要求への応答と、画像の要求への応答というふたつの主要機能があります。主要なIIIF画像サーバは、Awesome-IIIFのImage Servers(https://github.com/IIIF/awesome-iiif#image-servers)で確認することができます。
また、IIIF Hosting[06]のような画像のホスティングサービスも存在します。本サービスに画像をアップロードすることで、登録した画像をImage APIに準拠して公開することができます。さらに、マニフェストも合わせて生成されるため、後述するIIIFビューアに読み込ませることもできます。2018年10月時点では、ディスク容量100MB、画像5枚まで、本サービスを無料で利用することができます。
3.3.3. IIIFクライアント / ビューア
IIIFビューアはマニフェストを読み取って適宜画像をWebブラウザ上に配置し、必要に応じてサイズや切り出し位置の調整などを行います。
以下では、主要なIIIFビューア3点を取り上げます。そのほかのビューアについては、公式サイト(https://iiif.io/apps-demos/#image-viewing-clients)などで確認することができます。
▶Mirador(http://projectmirador.org/)
スタンフォード大学、ハーバード大学の研究者らによりオープンソースで作成されたビューアです。画面分割による画像比較、アノテーション(注釈)の付与など、豊富な機能を提供しています。例えば図7左は、フランスの国立図書館とフランス国立科学研究センターがそれぞれ公開する西洋写本の断片を重ね合わせて表示している例です。また、図7右は画像にアノテーションを付与している例を示します。
図7 画像の重ね合わせとアノテーション付与の例[07]
▶Universal Viewer(https://universalviewer.io/)
米国・ウェルカムライブラリーや英国図書館によって開発されたビューアです。画像データだけでなく、3Dや音声、動画、PDFなどを閲覧することもできます(図4左)。
▶IIIF Curation Viewer(http://codh.rois.ac.jp/software/iiif-curation-viewer/)
人文学オープンデータ共同利用センター(以下、CODH)が開発しているビューアです。ページ移動やズームといった一般的なビューアが持つ機能に加え、複数の資料の中から任意のページを取り出し、任意の順序で閲覧する機能を提供しています。例えば、図8左に示すように、表示中のコマの部分矩形領域を選択し、利用者独自のコレクションである「キュレーションリスト」(図 8右)として登録することができます。
図8 IIIF Curation Viewerを用いたキュレーションの例[08]
3.4. IIIFの活用例
ここではIIIFの活用例として、ポータルサイトにおける活用例、キュレーションにおける活用例の2点について紹介します。
3.4.1. ポータルサイトにおける活用例
国外、特に欧米を中心として、さまざまな分野・領域の機関が連携し、各機関が保有する多様なデジタルコンテンツのメタデータを集約し、インターネット上で検索・閲覧できる、国・地域ごとの統合ポータルの構築が進んでいます。Europeana[09]は、欧州35ヶ国、3,000以上の図書館・美術館・博物館・文書館などの文化施設が保有する3,600万件以上の文化資源へのアクセスを可能とするポータルサイトです。そのほか、2013年に開設した米国デジタル公共図書館(DPLA: Digital Public Library of America)[10]は、1,300以上の文化施設が参加し、700万件以上のデジタル文化資源の閲覧を可能としています。特に前者のEuropeanaでは、参加機関がIIIFに対応している場合、ポータルサイトの画面上で各機関が公開する画像を操作可能な仕組みを提供しています。日本でも国内の分野横断統合ポータル「ジャパンサーチ」[11]の開発が進められています。ジャパンサーチにおいても、このような機能の提供が予定されており、デジタルアーカイブや画像データの連携を実現する上で、IIIFは非常に有効なソリューションとして位置づけられます。
関連する事例として、京都大学図書館機構と慶應義塾大学メディアセンターは、両大学が所蔵する医学分野の貴重資料コレクション「富士川文庫」のデジタル化画像を統合表示するWebサイト、「富士川文庫デジタル連携プロジェクト試行版」を2018年9月に公開しました[12]。本プロジェクトは、両大学が分散して所蔵する「富士川文庫」に対して、IIIFを活用した分散コレクションの仮想統合の一例を提示しています(図9)。
図9 所蔵機関を横断したコレクションの仮想統合の例[13]
3.4.2. キュレーションにおける活用例
IIIFは、外部からコンテンツの詳細にまで容易にアクセスを可能とする規格であるため、さまざまな観点からこれを活用したソリューションが世界中で開発されています。
先述したIIIF Curation Viewerはその代表例のひとつです。さらに、CODHはIIIF Curation Viewerで作成したキュレーションを検索可能にし、さらに検索結果を再編集した新たなキュレーションを公開可能とするIIIF準拠の画像検索ツール「IIIF Curation Finder」を含む、利用者主導型のオープンな次世代IIIFプラットフォーム「IIIF Curation Platform」を2018年5月に公開しています[14]。この活用例として、美術作品に出現する顔の部分を切り取って集め、それを美術史研究(特に様式研究)に活用するプロジェクト「顔貌コレクション」が公開されています。2018年10月時点においては、国文学研究資料館、京都大学、慶應義塾大学で公開されている画像から顔貌を収集し、画像の提供機関を横断した利活用を実現しています。
そのほかの代表的なソリューションとして、トロント大学図書館が中心に開発しているOmekaのプラグイン「IIIF Toolkit」[15]があげられます。本プラグインを使用することにより、プラグインに内蔵されたMiradorを使ってIIIF対応コンテンツにアノテーションを付与できるほか、付与したアノテーションをOmekaのデータベースに保存することができます。さらに、そのほかのプラグインと組み合わせて利用することにより、例えばIIIF対応コンテンツを地図や年表と組み合わせて表示・公開することができます。
図10 は2017年第2回NDLデジタルライブラリーカフェ「地域資料を最新規格でお手軽に使いやすくしてみよう」[16]の成果物の例を示しています。参加者が選定したIIIF準拠の画像にアノテーションを付与し、それを地図と年表にマッピングして表示している例です。選定対象となる画像はIIIFに準拠していれば、提供機関を問わないため、世界中の機関が公開する画像を使って、参加者ごとのコレクションを作成・公開することを可能としています。
図10 Omeka IIIF Toolkitを用いたIIIFコンテンツの表示例[17]
また、永崎ら[18]はIIIFマニフェストの効果的な共有を目的とするWebコラボレーションプラットフォーム「IIIF Manifest for Buddhist Studies」を開発しています。利用者がIIIFマニフェストのURLをシステム上に登録することにより、IIIFマニフェスト内の情報がデータベースに格納され、それらの情報に基づく検索を可能としています。本システムを利用することにより、世界中のIIIF画像を各コミュニティの目的に応じて収集・編集し、利活用することが可能となります。
4. まとめ
本章では、画像データに関するトピックとして、用語や画像フォーマットなどの基礎情報、および画像データ共有のための国際規格IIIFについて説明しました。IIIFは西洋中世写本の画像データを対象に開発がスタートしましたが、今日では動画や音声、3D画像など、対象範囲が拡大しつつあります。画像データの利活用の可能性を高めるという意味において、IIIFは今後より重要な役割を果たすことが予想されます。
ぜひ実際にIIIF対応コンテンツや、IIIF準拠のソフトウエアやツールなどを利用することで、IIIF準拠の画像データの相互運用性の高さを感じていただきたいと思います。
─注(Webページはいずれも2018-10-20参照)
[01]国立国会図書館, 国立国会図書館資料デジタル化の手引2017年版, http://www.ndl.go.jp/jp/preservation/digitization/guide.html.
[02]Europeana, https://www.europeana.eu/portal/en.
[03]Digital Public Library of America, https://dp.la/.
[04]デジタルアーカイブジャパン推進委員会及び実務者検討委員会, https://www.kantei.go.jp/jp/singi/titeki2/digitalarchive_suisiniinkai/index.html.
[05]IIIF Image API 2.1.1, https://iiif.io/api/image/2.1/.
[06]IIIF Presentation API 2.1.1, https://iiif.io/api/presentation/2.1/.
[07]Omeka, https://omeka.org/.
[08]Omeka S, IIIF Server, https://omeka.org/s/modules/IiifServer/.
[09]IIIF Hosting, https://www.iiifhosting.com/.
[10]Mirador, Advanced Features Demo, http://projectmirador.org/demo/advanced_features.html.
[11]人文学オープンデータ共同利用センター, 『顔貌データ:イギリスの肖像』(CODH編集), http://codh.rois.ac.jp/curation/exhibition/2/.
[12]京都大学貴重資料デジタルアーカイブ, 日本医学史研究者の旧蔵書, 没後70年以上の時を経て『デジタル富士川』として一堂に, https://rmda.kulib.kyoto-u.ac.jp/news/2018-09-28.
[13]富士川文庫デジタル連携プロジェクト試行版, http://www.kulib.kyoto-u.ac.jp/rdl/digital_fujikawa/index.html.
[14]人文学オープンデータ共同利用センター, IIIF Curation Platformの特長, http://codh.rois.ac.jp/iiif-curation-platform/.
[15]Omeka Classic, IIIF Toolkit, https://omeka.org/classic/plugins/IiifItems/.
[16]NDL Lab, "2017年「NDLデジタルライブラリーカフェ」開催のご案内", https://lab.ndl.go.jp/cms/digicafe2017.
[17]永崎研宣, NDL デジタルライブラリーカフェ「地域資料を最新規格でお手軽に使いやすくしてみよう」作業手順解説用資料, https://jinmoncom2017.omeka.net/items/show/1.
[18]永崎研宣・下田正弘・Muller A. Charles・蓑輪顕量「横断型デジタル学術基盤を目指して-SAT2018の構築を通じて-」、『研究報告人文科学とコンピュータ(CH)』Vol. 2018-CH-117、No. 1、2018年、1-8頁。
------
【全体目次】
ご挨拶○新たな学の創成に向けて(久留島 浩)
はじめに(後藤 真)
chapter1 人文情報学と歴史学
後藤 真(国立歴史民俗博物館)
chapter2 歴史データをつなぐこと―目録データ―
山田太造(東京大学史料編纂所)
chapter3 歴史データをつなぐこと―画像データ―
中村 覚(東京大学情報基盤センター)
●column.1 画像データの分析から歴史を探る―「武鑑全集」における「差読」の可能性―
北本朝展(ROIS-DS人文学オープンデータ共同利用センター/国立情報学研究所)
chapter4 歴史データをひらくこと―オープンデータ―
橋本雄太(国立歴史民俗博物館)
chapter5 歴史データをひらくこと―クラウドの可能性―
橋本雄太(国立歴史民俗博物館)
chapter6 歴史データはどのように使うのか―災害時の歴史文化資料と情報―
天野真志(国立歴史民俗博物館)
●column.2 歴史データにおける時空間情報の活用
関野 樹(国際日本文化研究センター)
chapter7 歴史データはどのように使うのか―博物館展示とデジタルデータ―
鈴木卓治(国立歴史民俗博物館)
chapter8 歴史データのさまざまな応用―Text Encoding Initiative の現在―
永崎研宣(人文情報学研究所)
chapter9 デジタルアーカイブの現在とデータ持続性
後藤 真(国立歴史民俗博物館)
●column.3 さわれる文化財レプリカとお身代わり仏像―3Dデータで歴史と信仰の継承を支える―
大河内智之(和歌山県立博物館)
chapter10 歴史情報学の未来
後藤 真(国立歴史民俗博物館)
おわりに