‘2015/09’ カテゴリーのアーカイブ

デバイスの高解像度化が止まらない

2015/09/16

iPad Proが発表になりました。前々から噂は出ていましたが、やはり12.9インチの大型液晶デバイスがAppleから発表になったことはインパクトがあります。このデバイスの登場には電子書籍制作側としてずっと関心がありました。それは、「縦2048ピクセルを越えるパネルを搭載してくる可能性があり、印刷データで現在使用されている画像の電子書籍用の流用の分岐点を越える」可能性があったためです。iPad Proが2732×2048ピクセルのパネルを搭載して登場してきたことで、どうやらこれは現実になったと言えます。高解像度タブレットはこれまでもKindle Fire HDX 8.9などがありましたが、Appleがここのラインに足を踏み入れたことで、完全に一般化したと言えるでしょう。

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

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

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

画像ピクセル数が足りないために画像が中央に小さく表示される

画像ピクセル数が足りないために画像が中央に小さく表示される

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

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

SVG固定レイアウトの指定例

SVG固定レイアウトの指定例

これを防ぐために、一部ページを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の解像度が必要になる計算になります。これはかなりの高解像度化であり、ファイルサイズの大幅な増加が予想されます。

講談社とNECが共同で開発して発表したスマート・ソース・エディター(SSE)などの事例もあり、読み物を中心とした印刷物のテキスト側の上流分岐処理はそれなりに整い始めているようにも思えますが、こと画像に関する限りほとんど手つかずなのではないかと思います。解像度の問題だけでなく、CMYK/RGBカラーモデルの相互変換の問題、特色の処理※3の問題など、ここにはまだ考えなければならない問題がたくさんあります。早期の実用的なワークフローの普及を願ってやみません。

※1 参考:電書ちゃんねる「これでマスター! EPUB 3 固定レイアウト」

※2 参考:KADOKAWA EPUB-PORTAL

※3 参考:「特色」にご用心

(2015.9.17)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。