300〜400dpiが一般的な「印刷物に用いる画像の解像度」

写真などの画像（ビットマップ／ラスター画像）をオフセット印刷に用いる場合、スクリーン線数の1.5〜2倍というのが一般的で、スクリーン線数は133〜200線が広く普及しています。このため、適正な画像の解像度は300〜400dpiあれば十分だと言われてきました。もちろんこれ以上の解像度の画像を用いても良いのですが、データサイズが大きくなるなどのデメリットもあるため、現実的な運用として400dpi程度を基準としてきた会社が多かったのではないかと思います。また、長きにわたって「Webなどで使う画像はそこまで解像度は高くなくてよいから、印刷データ用の画像の流用で間に合う」というのが常識として定着していました。ですが、相次ぐデバイスの高画素化で差はどんどん埋まり、どうやら今回の発表でついに常識が覆ってしまったのではないかと思われます。

画像のピクセル数よりもデバイスの画面ピクセル数が大きいとどうなるのか

試みに、文庫判（148×105mm）サイズ、縦300dpiで作られた1ページ大の画像を考えてみます。この判型だとピクセル数は縦1748ピクセル、横1240ピクセルになるようです。iPad Proのパネルのピクセル数をかなり下回ることがわかります。
このサイズで作った画像を通常のリフローの画像挿入方法でEPUB内に挿入しますと、普通に考えればビューアでピクセル数が不足するために画像は画面の上部中央に表示され、左右および下部にアキが出てしまうはずです。つまり1ページ全画面配置のレイアウトが保てなくなるのです。

1ページ大の画像配置は固定レイアウト指定による強制引き伸ばしを

これを防ぐために、一部ページをSVGを用いた固定レイアウトで表示させる（フィックスドハイブリッド）方法^※1を用いることが出来ます。KADOKAWAさんなどが取っている手法^※2ですが、この手法を取れば、とりあえずカバーの書影などどうしても1ページ全画面配置で表示したいページを強制的に引き伸ばして表示させることが可能なはずです。
ただ、これはあくまで「強制引き伸ばし」ですから、画像が引き伸ばされて甘くなるのは避けられませんし、挿入画像など文中に挟み込む形で入る画像にはこの手は使えません。

各ビューアの実際の挙動

この「固定レイアウト指定による強制画像引き伸ばし」を実際にどこまでのビューアがサポートしているのかちょっと調べてみました。結果は以下の通りです。

https://docs.google.com/spreadsheets/d/1eGIkZVb7RWg-8DkMNPLS1fXH4ozGJMP1qmc2hKhnGdM/pubhtml

どうやら通常のリフロー形式で画素数不足の画像を挿入しても、強制的に引き延ばして表示するRSが相当数あるようで、例えばKinoppyのiOS版およびMac版、KoboのiOS版および専用端末版は強制的に引き延ばして表示するようです。Kindleは「カバー画像のみ」必ず引き延ばします。いずれにせよ挙動が各社バラバラで、「固定レイアウト指定をしないとビューアによってはアキが出てしまう可能性がある」くらいに考えておいた方がよさそうです。

高解像度化は今後どこまで行くのか

では、デバイスの高解像度化は実際どこまで行きそうなのか。中短期的にはおそらく4K（3840×2160px）までは行きそうかなと思っています（8Kはちょっとまだ待って欲しい）。仮にこのピクセル数に対応させるために印刷用画像の解像度を定めるとしますと、文庫判で659dpiの解像度が必要になる計算になります。これはかなりの高解像度化であり、ファイルサイズの大幅な増加が予想されます。