IIIFの導入・運用にあたっての課題と解決方法

IIIFの導入・運用にあたっての課題と解決方法を知りたいというお話をいただきましたので、ここまでの筆者の体験について少しご紹介してみたいと思います。導入方法についてご紹介した前回の記事とあわせてご覧いただけますと幸いです。

 

まず、全般的な印象について、筆者の個人的な見解を書いておきます。筆者は、IIIFを導入するようになる前から、高精細画像をWeb上で公開するシステムを作ってきました。具体的には、色々検討した結果、自分でタイル画像ビューワをJavascriptで書いて提供していたことがあり、また、Open SeadragonでDeep Zoom形式のタイル画像を用いて公開したこともあります。そういう経験からしますと、IIIFの導入にあたっては留意しなければならないいくつかのポイントがありますが、それらは、高精細画像をWeb上で公開する際の課題とほぼ重なります。ですので、多くの課題は、IIIFの問題というよりは、高精細画像の公開一般についての問題と考えていたいただくのがよいのではないかと思っております。その上で、IIIFに準拠して公開した場合には様々なメリットが生じる一方、対応しない場合のデメリットの大きさも勘案するなら、対応しておかない手はないだろう、ということでみなさまにおすすめしているところです。

 

 そのようなことで、とりあえずここでは、筆者が自分で導入したり導入のお手伝い(いくつかの機関や企業のお手伝いもしてきております)をしたりしたなかで経験した色々な課題を、画像配信にまつわる問題、公開の在り方の問題、IIIF Manifestの問題、ビューワに関わる問題、その他諸々、といった感じにわけて、それぞれご紹介してみたいと思います。

 

1.画像配信にまつわる問題

 

やはりIIIFではこれに関わる問題が色々とあります。高精細画像の公開における課題そのものと考えていただいてよいのではないかと思いますが、とりあえず一つずつご紹介していきます。

 

1.1.タイル画像のサイズ

 Pyramid Tiled Tiff形式は、IIP Image Serverと併用して、比較的大きな画像を高速に配信するためによく使われています。8~10種類くらい(あるいはもっと)の縦横サイズの画像を作成し、さらに、指定した縦横サイズ以上の画像の場合には分割して(タイル化して)部分的に取り出せるようにして、それらを一つのTiffファイルにまとめたものがPyramid Tiled Tiff形式、もしくはPyramid Tiffなどと呼ばれる画像形式です。タイル化する際には、タイルの大きさをどのようにするかというのが一つのポイントになってきます。

 タイル画像のサイズの決定は、なかなか難しい問題です。「タイルに区切って配信することで、容量の大きな画像であっても見たい箇所だけを配信することができるので効率的である」と言っても、画像でもなんでも、Webで配信すると、1ファイルを配信するごとにサーバとクライアント(パソコン)の間で色々なやりとりが発生します。タイルが小さすぎると、やりとりされるタイルの数が増えて、このやりとりの回数も増えてしまうので、結果的に遅くなってしまいますし、大量の小さな画像を送信することはネットワークへの負荷もそれなりに大きくなってしまうことがあります。ですので、小さすぎないことも重要です。筆者はとりあえず256x256で作ってしまっていますが、もう一回り大きくてもいいかもしれないと思っております。たとえば、以下のサイトは512x512だったり、

https://open.library.ubc.ca/collections/tokugawa/items/1.0227946

https://iiif.library.ubc.ca/presentation/cdm.tokugawa.1-0227946/manife (IIIF manifest)

https://iiif.library.ubc.ca/image/cdm.tokugawa.1-0227946.0000/info.json (info.json)

さらに、大きな地図を公開している例では2147x1434とか2142x1756のようなサイズのタイルにしているところもあるようです。

2147x1434:

https://searchworks.stanford.edu/view/11298997

https://purl.stanford.edu/hs631zg4177/iiif/manifest (IIIF manifest)

https://stacks.stanford.edu/image/iiif/hs631zg4177%252Fhs631zg4177_00_0001/info.json (info.json)

2142x1756:

https://searchworks.stanford.edu/view/dp874jj6432

https://purl.stanford.edu/dp874jj6432/iiif/manifest (IIIF manifest)

https://stacks.stanford.edu/image/iiif/dp874jj6432%252F5763001/info.json (info.json)

 特に、現在ほとんどのWebサイトで使われているHTTP1.1では、一度に配信する数が多い場合、オーバーヘッドがとても大きくなってしまいます。大きな画像ではじからはじまでさっと移動させると、それだけで膨大な数のタイル画像の転送をサーバ側に要求することになってしまって、画像配信がものすごく遅くなってしまうことがあります。そこで、タイル画像のサイズを大きめにして、転送数を減らすという方向も十分にあり得ます。大きな画像を扱う場合には、実際にいくつかのタイルサイズを試してみるといいかもしれません。

 

1.2.HTTPにおけるタイル画像の大量同時配信における課題 

 詳しい技術的な解説は他のサイトに譲るとしまして、基本的に、Webで用いられているプロトコルHTTP/HTTPSは、大量のファイルを一度にサーバから送出するという使い方にはそれほど向いていません。現在広く使われているWebサーバソフト環境では、HTTP1.1が使われていることが多いですが、これは、KeepAliveの設定をOnにしておかないと、たくさんのファイルを配信するときに転送数制限に引っかかってしまって、タイル画像の読み込みが途中で止まってしまいます。たとえば、Redhat6やCentOS6のApacheでは、KeepAliveがデフォルトではOnになっていないようですので、Onにした方がよいと思います。Redhat7やCentOS7ではデフォルトでOnになっているようですので、この点は大丈夫かと思います。

 また、KeepAliveの設定をOnにしていたとしても、やはりどうしても、配信ファイル数が多くなる場合の負荷の大きさという問題は残ります。それをよりうまく解決する方法として、従来よく使われてきたHTTP1.1ではなくHTTP/2を採用するという手があります。たとえば、万暦版大蔵経デジタル版では、画像配信にHTTP/2を採用しており、それなりに速くなっているようです。ただし、現時点では、サーバ用途でよく使われるLinuxディストリビューションでは、HTTP/2は正式サポートされていないようですので、自分で対応するHTTPサーバを用意する必要があります。筆者は、HTTP/2を導入するために、OpenSSL、ApachePHPIIP Image server等をソースコードからコンパイルして設定しました。ですので、特に新たな費用は発生しませんでしたが、このやり方で導入してしまうとセキュリティアップデートなどがちょっと大変になってしまうので、企業発注の場合にも、導入コストだけでなくメンテナンスコストもやや高く見積もられてしまう可能性があります。ですので、HTTP/2に関しては、広くサーバ用途で使われるLinuxディストリビューションが対応するまで待った方がいいかもしれません。

 

1.3.画像配信サーバソフトのインストール

 画像配信サーバソフトのインストールは、作業自体はそれほど難しくはありません。いくつかの解説サイトを見て手順通りに作業すれば大丈夫です。ただし、(1) PythonrubyCGI的なものを動してよいか、(2) C++のソフトをCGIとして動かしてよいか、(3) Tomcatサーバを動かしてよいか、といった点について、サーバ運用に関する全体のポリシーとのすりあわせを行う必要があります。いずれもダメということになった場合には、IIIF Image API を導入することはやや難しくなります。この点は、たとえばOpen Seadragonの Deep Zoom形式であれば、画像配信用サーバソフトがなくてもタイル化されたJpeg画像を所定のWebディレクトリに置いておくだけで利用可能であることに比べると、状況によっては割と大きな障壁となる場合があります。また、運用ポリシーとの整合の問題は大変重要ですが、費用面に関しても、導入費用だけでなく保守費用も高くなる可能性が念頭に入れておく必要があります。また、言い方を変えると、画像配信サーバソフトのインストールがネットワーク・サーバの運用ポリシーに抵触しないのであれば、導入自体は容易であると言うこともできます。

 

1.4.タイル画像化する場合のストレージの容量

 ある程度大きな画像を配信しようとする場合や、負荷がかなり大きくなることが想定される場合には、画像を事前にタイル化しておく方が利便性を下げずに済みます。タイル画像化については、現状ではPyramid Tiled Tiff(あるいはPyramid Tiff)が一般的であるように思われます。Pyramid Tiled Tiff形式を作成する場合、お手元の状況にもよると思いますが、TiffJpeg等の画像ファイルをPyramid Tiled Tiffに変換することになると思います。この変換の際には、ImagemagickやVIPSといったフリーソフトが利用できます。いずれかのフリーソフトを用いることで、「フルサイズ画像に加えて、8~10段階程度(あるいはもっと多い場合・少ない場合もあります)の画像を作成しつつ、一定サイズ以上のものはタイル状に分割して、それらをまとめて一つのTIFF画像を作成する」という一連の操作がコマンド一つでできます。このようにして作成したPyramid Tiled Tiff画像をIIP Image Server等から読み込み・配信できるようにしておけば、クライアント側からのアクセス要求にあわせて近いサイズの画像を取り出して配信するととともに、一定サイズ以上のものはタイル状に分割して、クライアントから要求された場所のタイルを取り出して配信するということになり、サーバソフトでの処理の負荷を大幅に軽減することができ、結果的に、大きい画像であればあるほど、アクセスを高速化することができます。

 この変換作業にあたっては、簡単なスクリプトで繰り返し処理をすれば、大量の画像でもあまり手間をかけずに処理することができます。ただ、人の手間はあまりかからないのですが、この画像処理自体に結構時間がかかりますので、計画的に進めることが重要になってきます。

 また、Pyramid Tiled Tiffに変換すると、複数サイズの画像を作成するということになりますので、どうしてもファイルサイズが大きくなってしまいます。大きなストレージを用意することができるのであれば、それが一番楽ですが、そういうわけにもいかない場合もあるでしょう。そのためには、画像容量がなるべく大きくならないように、Pyramid Tiled Tiffにする際に画像の圧縮率を上げてしまうという方法があります。圧縮率を多少上げても、人が見る際にはそれほど問題がない場合もあるので、色々試してみた上で変換時の圧縮率を決めるとよいかもしれません。

 

1.5.画像へのアクセス速度をあげるための工夫: IIP Image ServerのMemcached

 IIP Image Server限定ですが、アクセス速度をあげるためにMemcachedを利用することができます。クライアント側からリクエストされた画像をそのままキャッシュして、同じリクエストがきたらそれを返すということになり、アクセスごとに画像変換を行う処理を回避できることになります。よくアクセスされるサムネイル画像群や、皆がよく見る画像、授業や会合等で皆がほぼ同時にアクセスする画像等がキャッシングされることになれば、画像配信サーバの負荷が劇的に下がることが期待できます。筆者の関係しているサイトでも一部でこれを利用しております。

 

 

2.他の機関に画像を持って行かれるようにみえる/公開機関の存在感がなくなる

 

 この問題については、こちらの論考 http://researchmap.jp/?action=cv_download_main&upload_id=125135 のp. 65の「IIIFの導入に伴う公開の在り方の変化」という節をご覧ください。それに筆者の考えをもう少し付け加えると、基本的には、「デジタルアーカイブ」の利活用を広げ、デジタル時代の知識流通基盤を確かなものにしていくためにはIIIFのような利用のされ方が必要にならざるを得ず、しかもそのためには、各「デジタルアーカイブ」で共通のルールが用いられる必要があることから、現時点では、高精細画像を共有する機能に関してはIIIFの仕様を採用していくことが最良の選択肢であると思っております。

 また、IIIFの仕様としては、権利所有者についての情報とライセンス情報を書くというルールになっており、各対応ビューワはそれを表示するようになっています。

 なお、Image API単独での利用を考慮して、画像毎にライセンス情報を付与できる仕様もImage APIには用意されていますが、(http://iiif.io/api/image/2.1/#rights-and-licensing-properties)これを何らかの形で実装している例にはまだ気づいたことがありません。もしどなたかご存じでしたらぜひご教示ください。

 

 3.IIIF Manifestファイルに関して

 

 IIIF Manifestファイルを作成した時には、IIIF Validator http://iiif.io/api/presentation/validator/service/ にて整合性チェックをしてみましょう。最低限、これでエラーが出なくなるまではきちんと修正する必要がありますが、エラーが出た場合に、どこがエラーなのかわからないことがあります。その場合には、別のJSONバリデータを使うことで確認できることがあります。JSONバリデータは、ググるとたくさん出てきますので、ここだけでわからない時は、他のものを探していくつか試してみるとよいかもしれません。ちなみに筆者は、oXygen XML EditorがJSONにも対応してバリデータの機能も持っているので、基本的にはこれを使っています。テストパターン作成もこれで行っています。

 IIIF Manifestファイルに目次情報を入れたりするとだんだんファイルが巨大になっていってしまいます。ビューワ側としては基本的にはIIIF Manifestファイルを全部読み込んでから次のプロセスに移るものが多いようですので、IIIF Manifestファイルが巨大になると、配信に時間がかかって、その分、画像が開くのが遅くなります。そこで、Webサーバ側でJSONファイル配信時にgzip圧縮をかける設定をすると、そこのボトルネックがかなり解消されます。体感的には結構速くなりました。たとえばApacheの場合には、mod_deflateで.jsonに圧縮がかかるようにすればいいようです。

 IIIF Manifestでは、@idごとにURIを作成することになりますが、重複しないように注意してください。それから、作成したURIごとに対応するJSONファイルを作成した方がよいので、それも頑張ってください。筆者の場合、最初はやってませんでしたが、途中からなるべく作成するようにしております。(しかし、canvasなど、直接アクセスされやすそうなものだけで、まだ全部作成しているわけではありませんので、これは筆者自身の課題でもあります。)

 

4.IIIF対応ビューワに関して

 

 IIIF対応ビューワには、Universal Viewer、Miradorというメジャーなもの以外にも、Leaflet-IIIFやOpen Seadragonなど、カスタマイズすることで色々な形で使える、自由度は高いが開発力を要求するタイプのものがありますが、簡便に導入できる便利なものを採用したければやはりUniversal ViewerかMiradorということになります。Universal Viewerに比べて、Miradorの場合には、サムネイル画像を横に並べてページをめくっていける機能があり、サムネイル画像を多く表示できる分、使いやすい面があるのですが、当初は、IIIF ManifestではviewingDirectionとしてright-to-leftという値が用意されているにも関わらずMiradorではそれに対応していませんでした。日本語や中国語の縦書き資料でページめくりやサムネイル画像のリストが左から右になってしまっていることに関しては、結構な数の利用者から使いにくいというクレームがあっただけでなく、自分自身としても、あまりにも使いにくかったので、オープンソースとして開発されているMiradorのソースコードを見て、自分でコードを追加して、viewingDirectionがright-to-leftになっている時だけはそれに対応したページめくり方向・サムネイル画像の並び方向になるようにしました。自分のところではそれを使えばよかったのですが、日本の他機関にも使ってもらうといいのではないかと持ちかけたところ、本家で対応していないとだめだということを言われたので、本家のソースコードに反映してもらえるように交渉をしました。ソースコードを提供してからやや時間がかかり、本家が何度かバージョンアップしてそのたびにこちらの追加コードを書き直すことになったりしましたが、ようやくバージョン2.6.0で正式に取り込まれた、ということがありました。いずれにしても、オープンソースプロジェクトなので、こちらが必要な機能をこちらで開発してコードを提供すれば、グローバルな機能の一つとして取り込んでもらうことは可能なようです。

 

5.HTTPS問題

 

 近年、認証を必要とするシステムでは、HTTPSに対応することが求められるようになってきています。そして、IIIFが依拠する仕組みでは、HTTPSのサイトにIIIFコンテンツを読み込ませようとすると、IIIFコンテンツもHTTPS対応していなければなりません。これは、Webブラウザの仕様による制限であって、IIIFの問題ではありません。が、とにかく、HTTPで公開しているコンテンツは、一般的なWebコラボレーションシステム(=HTTPSで運用されていることが多い)のようなものでは取り込めなくなってしまうことが多いです。ですので、IIIFコンテンツをHTTPS で公開することは必須になりつつあります。そして、そのためにはSSLの証明書が必要になります。これは、どこか信頼できるところから取得する必要があり、しばらく前までは、そのためにそれなりの費用を支出する必要がありました。しかし、最近は、Let’s encryptというフリーのSSL証明書取得サービスが始まったので、一応、これを利用してHTTPS対応するという選択肢が出てきました。このサービスでは、証明書の利用期間が短く、数ヶ月ごとに証明書を更新する必要がありますが、導入・更新のためのスクリプトが用意されていて、コマンド一発でできるようになっています。ですので、とりあえずはこれを利用しておくという手もあろうかと思います。

 

6.仕様のアップデートの問題

 

 筆者が開催しているIIIF講習会ではいつも強調していることの一つであり、かつ、IIIFに限ったことではなく、「デジタルアーカイブ」全般において避けて通れない重要な課題なのですが、IIIFのAPIの仕様はそれなりの頻度でアップデートされます。ですので、アップデートされた場合には、適切な速度でうまくついていけるような体制とシステムにしておく必要があります。HTMLの例で考えていただけばよいと思いますが、5年くらいはまあなんとか大丈夫ですが、10年経つと互換性がちょっとあやしくなることがある、というような感じでしょうか。もちろん、ビューワ側で旧バージョンにも対応し続けてくれれば問題ないのですが、ビューワ開発のマンパワーは無尽蔵ではないので、新バージョンでできる新しく意義深いことが優先されるようになってしまうと、旧バージョン対応がちょっと厳しくなることもあるでしょう。

 一方で、IIIFのAPIの仕様がアップデートされても、ビューワやサーバソフトなどの環境がすぐに対応できるわけではないので、アップデートに即応する必要はありません。たとえば、筆者が関わり始めたときはImage APIとPresentation APIがどちらもバージョン1からバージョン2に移行する時期で、使っているソフトがバージョン2にうまく対応できているかどうかの確認ができず、ものによって対応しているようであるものとそうではなさそうなものがあるようで、よくわからずに少々混乱しました。それでも、2016年の3月くらいには、バージョン2に対応するソフトがかなり安定してきたようだったので、本格的な導入に向けて作業を始めたのでした。また、バージョン2はそれなりの使い勝手を提供できており、それなりに安定しているようでもありましたので、海外有力機関が続々採用し始めていたこともあり、皆様にも広めようと思うに至ったのでした。

 そのような感じですので、あまり無理して最新のAPI仕様についていく必要はないのですが、さりとて、ずっと古いままで、いずれビューワやその他の関連ツールや関連環境などが対応できなくなってしまうと本末転倒な感じになってしまいますので、やはり、どこかの時点でアップデートに対応できる体制とシステムはあった方がいいように思われます。

 

まだまだ色々あるような気がしますが、とりあえずここまでとしたいと思います。上記の情報は、記憶に頼って書いている部分が多く、正確でないところがあるかもしれませんので、くれぐれもご注意ください。何か、気がついたことがございましたらぜひお知らせください。