IIIFイメージサーバで高解像度画像を快適に配信するためには、ソース画像の前処理が不可欠です。本章では、ピラミッドTIFF（Pyramidal Tiled TIFF） の仕組みと作成方法を中心に、画像変換のベストプラクティスを解説します。
ピラミッドTIFFとは何か
ピラミッドTIFFとは、1つのTIFFファイルの中に 複数の解像度レベル と タイル分割 を格納した画像形式です。
なぜ必要か
デジタルアーカイブで扱う画像は、数万ピクセル四方に及ぶ高解像度のものが珍しくありません。たとえば、東京大学総合図書館所蔵の『百鬼夜行図』は 79,508 x 3,082 ピクセルという巨大な画像です。このような画像を通常のJPEGやTIFF形式で配信すると、以下の問題が生じます。
- メモリ不足: サーバが全画像をメモリに読み込む必要があり、処理が破綻する
- 応答速度の低下: ユーザが画像の一部だけを閲覧したい場合でも、全体の読み込みが必要
ピラミッドTIFFは、これらの問題を以下の仕組みで解決します。
タイル分割（Tiled）: 画像を 256x256 ピクセル等の小さなタイルに分割して格納します。IIIFサーバは、リクエストされた領域に対応するタイルだけを読み込めばよいため、メモリ消費を最小限に抑えられます。
ピラミッド構造（Pyramidal）: 元画像のフルサイズに加え、1/2、1/4、1/8…と段階的に縮小した複数の解像度レベルを1つのファイルに格納します。ユーザが広域表示（ズームアウト）している際には低解像度レベルから、詳細表示（ズームイン）している際には高解像度レベルから、適切なタイルを返すことで、常に高速なレスポンスを実現します。
tiffinfo コマンドで確認すると、以下のように複数のTIFFディレクトリ（レイヤー）が格納されていることがわかります。
libvips/pyvipsを使った変換方法
ピラミッドTIFFの作成には libvips（vips） を強く推奨します。後述するImageMagickと比較して、正確なピラミッド構造を生成でき、出力ファイルサイズも小さくなる傾向があります。
vipsコマンドラインでの変換
libvipsのインストール方法は公式サイトを参照してください。macOSの場合は brew install vips、Ubuntuの場合は apt install libvips-tools で導入できます。
基本的な変換コマンドは以下のとおりです。
vips tiffsave source_image.jpg output_image.tif \
--tile --pyramid --compression jpeg \
--tile-width 256 --tile-height 256
各オプションの意味は以下のとおりです。
| オプション | 説明 |
|---|---|
--tile | タイル分割を有効にする |
--pyramid | ピラミッド構造（複数解像度レベル）を生成する |
--compression jpeg | 圧縮方式を指定（jpeg, deflate, lzw, none等） |
--tile-width 256 | タイルの幅（ピクセル） |
--tile-height 256 | タイルの高さ（ピクセル） |
アルファチャンネルを含む画像（PNG等）の場合は、事前にアルファチャンネルを除去する必要があります。
# アルファチャンネルのある画像を処理する場合
vips extract_band source_image.png temp_image.v 0 --n 3 \
&& vips tiffsave temp_image.v output_image.tif \
--tile --pyramid --compression jpeg \
--tile-width 256 --tile-height 256 \
&& rm temp_image.v
pyvips（Python）での変換
Pythonから変換する場合は、pyvipsライブラリを使用します。事前にlibvipsのインストールが必要です。
pip install pyvips
import pyvips
image = pyvips.Image.new_from_file("source_image.jpg")
image.tiffsave("output_image.tif",
tile=True,
compression="jpeg",
pyramid=True,
tile_width=256,
tile_height=256)
このコードはGoogle Colabでも実行可能です。Colabにはlibvipsがプリインストールされているため、pip install pyvips を実行するだけで利用を開始できます。
圧縮方式の比較
ピラミッドTIFFの圧縮方式は、品質要件とファイルサイズのトレードオフに基づいて選択します。以下は、274MBのJPEG2000画像（国立公文書館デジタルアーカイブの資料）を各方式で変換した際の検証結果です。
| 圧縮方式 | パラメータ | ファイルサイズ | 元ファイル比 | 可逆性 |
|---|---|---|---|---|
| JPEG | Q=25 | 57MB | 0.21x | 非可逆 |
| JPEG | Q=75 | 167MB | 0.61x | 非可逆 |
| JPEG | Q=100 | 2.4GB | 8.8x | 非可逆 |
| Deflate | - | 2.8GB | 10.2x | 可逆 |
| LZW | - | 3.2GB | 11.7x | 可逆 |
| 無圧縮 | - | 4.3GB | 15.7x | 可逆 |
JPEG圧縮（非可逆）
JPEG圧縮では品質パラメータ（--Q）でファイルサイズと画質のバランスを調整します。
# Q=75（推奨バランス設定、vipsのデフォルト値）
vips tiffsave input.jp2 output.tif --tile --pyramid --compression=jpeg --Q=75
# Q=100（ほぼ無劣化だがファイルサイズ大）
vips tiffsave input.jp2 output.tif --tile --pyramid --compression=jpeg --Q=100
Q=25では文字の輪郭にJPEG特有のノイズが目視で確認できますが、Q=75以上ではほぼ劣化を感じません。一般的なWeb配信にはQ=75が推奨されます。
ロスレス圧縮
原本性を重視するアーカイブ保存にはロスレス圧縮が適しています。ロスレス圧縮の中ではDeflateが最も効率的です。
# Deflate（ロスレスで最小サイズ）
vips tiffsave input.jp2 output.tif --tile --pyramid --compression=deflate
# 4GB超の場合はBigTIFF形式が必要
vips tiffsave input.jp2 output.tif --tile --pyramid --compression=none --bigtiff
用途別推奨設定
| 用途 | 推奨圧縮方式 | 理由 |
|---|---|---|
| アーカイブ保存（マスタデータ） | Deflate | ロスレスで最小サイズ |
| Web配信（品質重視） | JPEG Q=75〜85 | 品質とサイズの最適バランス |
| Web配信（速度重視） | JPEG Q=50〜60 | 転送速度を優先 |
| 印刷用途 | JPEG Q=90〜100 | 高品質を維持 |
ImageMagickの注意点と落とし穴
ImageMagickでもピラミッドTIFFを作成するコマンドが公開されていますが、いくつかの重要な問題点があります。
ピラミッド構造が正しく生成されないケース
ImageMagickのバージョンによっては、ptif: プレフィックスを使った変換でピラミッド構造が正しく生成されない場合があります。
# ImageMagickでの変換コマンド
convert source_image.jpg -alpha off \
-define tiff:tile-geometry=256x256 \
-define tiff:generate-pyramids=true \
-compress jpeg \
'ptif:output_image.tif'
tiffinfo で確認すると、TIFF directory 0（フルサイズ）のみが存在し、ピラミッド構造（複数のdiretory）が生成されていないケースが確認されています。
対してvipsでは、同じ入力画像から7つのディレクトリ（解像度レベル）が正しく生成されます。
ファイルサイズの差
同じ画像を変換した場合、ImageMagickの出力はvipsの約3倍のファイルサイズになることがあります（検証例: vips 35.6MB vs. ImageMagick 107.4MB）。これはserverless-iiifでの配信時、S3のストレージコストやLambdaのメモリ消費にも影響します。
推奨
以上の理由から、ピラミッドTIFFの作成にはlibvips（vips）の使用を強く推奨します。ImageMagickは画像の前処理（リサイズ、フォーマット変換等）には有用ですが、ピラミッドTIFFの生成には不向きです。
変換結果は必ず tiffinfo コマンドで検証し、複数のTIFFディレクトリが存在することを確認してください。
tiffinfo output_image.tif | grep "TIFF directory"
CMYKカラー画像の処理
印刷物のスキャン画像では、CMYKカラースペースが使われている場合があります。CMYKカラーの画像をそのままピラミッドTIFFに変換すると、色が反転して表示される という問題が発生することがあります。
問題の原因
CMYKカラースペースの画像をImageMagickでJPEG圧縮のピラミッドTIFFに変換すると、色空間の変換が正しく行われず、色が反転してしまいます。これはCantaloupe、IIPImage等のイメージサーバやMirador、Universal Viewer等のビューア側の問題ではなく、変換されたTIFF画像自体に問題があります。
対処法
ImageMagickを使う場合は、-colorspace sRGB オプションを追加してRGBカラースペースに変換してから処理を行います。
# 色が反転する（問題あり）
convert source_image.tif -alpha off \
-define tiff:tile-geometry=256x256 \
-compress jpeg 'ptif:output_image.tif'
# 色が反転しない（修正版）
convert source_image.tif -alpha off -colorspace sRGB \
-define tiff:tile-geometry=256x256 \
-compress jpeg 'ptif:output_image.tif'
libvipsを使う場合は、CMYKからRGBへの変換が自動的に行われるため、通常は追加の設定なしで正しい色で出力されます。CMYKカラーの画像を多く扱う場合も、libvipsの使用が安全です。
事前チェック
変換前に画像のカラースペースを確認しておくことで、問題を未然に防げます。
# ImageMagickで確認
identify -verbose source_image.tif | grep Colorspace
# vipsで確認
vipsheader -a source_image.tif | grep interpretation
AWS Lambdaでの自動変換パイプライン
S3に画像をアップロードすると自動的にピラミッドTIFFに変換するパイプラインを、AWS Lambda + Docker + pyvips で構築できます。前章のserverless-iiifと組み合わせることで、「画像をS3にアップロードするだけでIIIF配信が始まる」という自動化された環境を実現できます。
アーキテクチャ
構築手順
1. Dockerイメージの準備
pyvipsを含むLambda用のDockerイメージが公開されています。
git clone https://github.com/ldasjp8/lambda-docker-vips-python.git
cd lambda-docker-vips-python
このイメージをAmazon ECRにプッシュします。
aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin <アカウントID>.dkr.ecr.us-east-1.amazonaws.com
docker build -t lambda-docker-vips-python .
docker tag lambda-docker-vips-python:latest \
<アカウントID>.dkr.ecr.us-east-1.amazonaws.com/lambda-docker-vips-python:latest
docker push <アカウントID>.dkr.ecr.us-east-1.amazonaws.com/lambda-docker-vips-python:latest
2. Lambda関数の作成
AWSコンソールで新しいLambda関数を作成し、「コンテナイメージ」タイプを選択して、ECRにプッシュしたイメージのURIを指定します。
3. S3バケットの設定
2つのS3バケットを用意します。
- 入力バケット: 元画像のアップロード先（例:
iiif-input） - 出力バケット: 変換済みピラミッドTIFFの格納先（例:
iiif-output）
入力バケットのプロパティで「イベント通知」を設定し、「すべてのオブジェクト作成イベント」をトリガーとしてLambda関数を呼び出すように設定します。
4. Lambda関数の設定
以下の設定を行います。
- 環境変数:
iiif_bucket_nameに出力バケット名を設定 - アクセス権限: S3への読み書き権限を付与（IAMロールに
AmazonS3FullAccess等を追加） - 基本設定: メモリを1024MB以上、タイムアウトを60秒以上に設定
5. serverless-iiifとの連携
出力バケットをserverless-iiifの SourceBucket に指定します。これにより、元画像をアップロードするだけで以下のフローが自動実行されます。
- 元画像（JPEG, PNG等）がS3入力バケットにアップロードされる
- Lambda関数がトリガーされ、pyvipsでピラミッドTIFFに変換
- 変換済みファイルがS3出力バケットに保存される
- serverless-iiif経由でIIIF Image APIにより画像が配信される
Deep Zoomとの関係
ピラミッドTIFFと類似の概念として、Microsoft発の Deep Zoom があります。Deep Zoomは、ピラミッド構造のタイル画像を個別のファイルとして展開し、ディレクトリ構造で管理する方式です。
| 特徴 | ピラミッドTIFF | Deep Zoom |
|---|---|---|
| ファイル数 | 1ファイル | 多数のタイルファイル |
| サーバ要件 | IIIFサーバが必要 | 静的ファイル配信で可 |
| IIIF対応 | 直接対応 | 変換が必要 |
| 管理のしやすさ | 1ファイルで完結 | ディレクトリ構造の管理が必要 |
IIIFイメージサーバで使用する場合は、ピラミッドTIFF形式が標準的な選択です。CantaoupeやIIPImage、serverless-iiif等の主要なIIIFサーバがネイティブに対応しています。
ベストプラクティス
最後に、ピラミッドTIFF作成におけるベストプラクティスをまとめます。
変換ツールの選択
- libvips（vips/pyvips）を使う: ImageMagickではなくlibvipsを第一選択とする。ピラミッド構造の正確性、出力ファイルサイズ、処理速度のすべてにおいてlibvipsが優れている
圧縮設定
- Web配信にはJPEG Q=75: 品質とファイルサイズの最適なバランス。vipsのデフォルト値でもある
- アーカイブ保存にはDeflate: ロスレス圧縮で最小のファイルサイズ
- 4GB超の画像には
--bigtiffオプション: 通常のTIFF形式は4GBが上限
タイルサイズ
- 256x256を標準とする: serverless-iiifのドキュメントでも推奨されている値であり、多くのIIIFサーバ・ビューアで最適に動作する
品質検証
- tiffinfoで構造を確認: 変換後は必ず
tiffinfoで複数のTIFFディレクトリが存在することを確認する - IIIF対応ビューアで表示確認: 神崎正英氏のImage Annotator等を使って、実際にタイル配信が正しく行われるか確認する
カラースペース
- CMYK画像に注意: 印刷物スキャンのCMYK画像は、変換前にRGB（sRGB）に変換する。libvipsでは自動処理されるが、ImageMagickでは
-colorspace sRGBの明示が必要
自動化
- バッチ処理の自動化: 大量の画像を扱う場合は、シェルスクリプトやPythonスクリプトで一括変換する。AWS Lambdaを使えば、S3へのアップロードをトリガーとした自動変換パイプラインも構築できる
# ディレクトリ内のすべてのJPEGをピラミッドTIFFに一括変換
for f in ./images/*.jpg; do
output="./output/$(basename "${f%.jpg}.tif")"
vips tiffsave "$f" "$output" \
--tile --pyramid --compression jpeg \
--tile-width 256 --tile-height 256
echo "Converted: $f -> $output"
done
まとめ
ピラミッドTIFFは、IIIFによる高解像度画像配信の土台となる重要な技術です。libvipsを使って適切な圧縮設定で変換し、変換結果を検証するという基本的なワークフローを押さえておけば、Cantaloupeやserverless-iiifでのスムーズな画像配信が実現できます。
次章からは、IIIF Presentation APIによるマニフェストの作成に進み、画像をメタデータとともに構造化して提供する方法を学びます。