新画像フォーマット「BPG」は電子書籍のコミックに良いのでは（2014年末時点の各ストアの画質比較を添えて）

　久し振りに、電子書籍のコミックに関連した与太話でも。

　本当は、この記事は１週間以上前に公開している筈だったんですが、なんだかんだ中途半端にやる事があって、ここまでズレ込んでしまいました。息を吸って吐くだけのぐーたらした生活が送りたい。

　えー、そんなだらしのない個人的な願望はともかく、つい先日のことになりますが、以下のような記事を見かけました。

• Fabrice Bellard氏、JPEGの置き換えを目指す新画像フォーマット「BPG」を開発

　FFMPEGやQEMU、JSLinuxの開発者として知られるFabrice Bellard氏が、JPEGを置き換える新しい画像フォーマットとして、BPG(Better Portable Graphics)を提案している。BPGは同品質のJPEG画像と比較して、ファイルサイズはおよそ半分になる。

　ほほぅ。

　当ブログのこんな記事をご覧になっている皆さんと同様に、引用元を目にして私が真っ先に考えたのが、「これ、電子書籍のコミック用の画像フォーマットに良いんじゃね？」ということでした。

　BPG のデモを少し見ただけで分かるのですが、H.265(HEVC)のサブセットをベースにしているとのことで、どうやらノイズに強いフォーマットのように見受けられます。ということは、自然画よりも情報量の少ないのっぺりとした「描き絵」とも相性が良さそうです。

　商用であるにも関わらず、モスキートノイズやブロックノイズがバリバリだったり、あからさまに解像度が低くてボケボケだったりと、私のような「読めればいいや」と考えがちなユーザーですら、思わず眉を顰めたくなるような低品質のデータが、さも当たり前のように流通していることのある日本の電子書籍コミック事情ですが、これにはある程度仕方のない部分もあります。

　なぜなら、画質とデータサイズは現状においてトレードオフの関係にあり、基本的に高品質なデータというのはサイズが大きいからです（当たり前の話ですが）。

　もっと画質を良くして欲しいからといって、あまりにもデータが大きくなってしまい、転送（ダウンロード）に物凄く時間がかかったり、買ったコミックを１冊読もうと端末に保存しただけで何百 MB もストレージを占有されてしまったら、ちょっと困っちゃいますよね。

　なので、各ストアともユーザーが許容できるデータサイズと画質のバランスを探りつつ、解像度や圧縮レベルについて苦心している訳です。

　この辺りの話は、以前の記事にも書きましたので、詳しくはそちらをご覧いただくとして、とはいえ、ユーザーとして現状の日本式の電子書籍版コミックが、絵を見せる「漫画」のデータとして満足できるレベルかといえば、必ずしもそうではないと思います（同一ストアでも本によって品質がまちまちだったりするので、一概に言うのは難しいのですが）。

　まー、要するに、「サイズを小さく保ったまま、もうちょっと綺麗にしてくんないかなー」というのが、ユーザー側としての忌憚のない本音であり、その要望を多少なりとも満たせそうな画像フォーマットがあるのならば、それを使わない手は無いだろうと身勝手なことを思う訳です。

　詳しくは後述しますが、別に BPG そのものをいますぐ使えと言うつもりはさらさらありません。この先まだ数年は、2014年の現状のように紙の本と同じ画像を単純に並べるだけであろう日本式の電子書籍版コミックに、より適した圧縮画像フォーマットがあるんではなかろうかという疑問がまずありまして、それについて考えることの一端として、BPG がどんなもんだか見てみようというくらいの記事です。

　大した内容ではありませんが、よろしければ、しばしお付き合いくださいませ。

読み込み中です。少々お待ち下さい

まずは現状確認

　さて、それではまず、現状を確認していきましょう。

　商用を含む二次利用が許可されていて、ほとんどの電子書籍ストアから無償でダウンロードできる「ブラックジャックによろしく（著作者名：佐藤秀峰、サイト名：漫画 on web）」の第 1 巻、10 ページを iPad mini 2（2,048 x 1,536ピクセル解像度、326ppi）で表示し、2 コマ目の一部を引用して並べてみると、ストアによってデータの作り方がかなり異なることが分かります。

（拡大しないとノイズが視認し難いと思いますので、クリックで整数倍に拡大するようになっています。拡大表示を閉じるには、もう一度クリックするかスクロールしてください）

（また、一部のモバイル回線や Web アクセラレータ等、ネットワーク（プロキシ）を経由すると、画像が再圧縮されて劣化してしまう場合があり、以下の画質比較があまり意味を成しません。可能であれば、ご自宅の光回線など完全な形でデータが中継される環境でご覧ください）

　ちなみ、以下が分かる範囲での各ストアのデータサイズになります（１冊分）。

　注意点として、同一ストアの電子書籍であっても、例えば出版社によって、あるいはデータが作られた時期により、諸々の事情で個別の本ごとに品質はまちまちな現状ですので、これはあくまでこの本における各ストアの画質比較という意味しか持ちません。ここで画質があまり良くないように見えるストアが、他の本では最も高品質なデータを提供している場合もあったりしますので、あくまで参考程度にご覧ください。

　という前提を踏まえた上で、それにしても LINE マンガの画質はヒドいッスね（笑）
　まぁ、ターゲットはスマホでお手軽に読むライトユーザー層だと割り切っているのでしょう。データサイズは不明ながら、おそらく画質よりもサイズ優先で相当に小さく抑えていると思われます（モバイル通信でデータを転送することが多いユーザー層であると見越しているのかも知れません。このようなデータの作り方から、そのサービスの意図するトコロを汲み取ってみるのも面白そうですが、今はさておくとしましょう）。

　個々の画質について言及するのが目的ではありませんので軽く流しますが、個人的に気になった点についてざっと挙げていくと、Kinoppy はノイズが多過ぎ、iBooks はデータサイズの割りに画質が悪過ぎ、GALAPAGOS は綺麗だけど画質の割にはデータサイズが大き過ぎ、ニコニコは解像度が低すぎ、Yahoo!ブックストアはサイズの割には画質が良いですがもう少しサイズよりも画質を優先すべき、LINE マンガは論外、eBook Japan はデータを作る過程のどこかで画質が極端に悪くなってるかも？ honto、BookWalker は可もなく不可もなし、kobo はノイズ多過ぎ、BookLive! は解像度低過ぎ、といったところでしょうか。

　ノイズや解像度などに不満を覚えるストアが多く、例えば iPad mini Retina のようなディスプレイの解像度が 300ppi を超える端末では、もう少し良い画質でコミックを楽しみたいという希望を、ユーザー側が抱いたとしても仕方がないように思います（許容できないほどノイジーだったり、Retina で見ているのにドットが容易に判別できてしまうようなジャギジャギなデータは、マジ勘弁です）。

BPG の画質はどんなもん

　現状をざっくり把握したところで、高画質を保ったままより小さいサイズにデータを圧縮できそうな画像フォーマットである BPG について見て行きましょう。

　元画像としては、上で並べた中から、データサイズが少々大きめですが解像度がそれなりでノイズの少ない Kindle 版のスクリーンショットを採用しました。

　ソースからライブラリを make してテストプログラムを書いても良かったのですが、今回はバイナリが用意されている Windows 版を利用して、ぐーたらお手軽に検証しました。

　エンコードを行う bpgenc.exe には、いくつかオプションが提供されていますが、ここでは -q と -m のみ使用しています。

　まず 1536x2048 PNG フォーマットの元画像を BPG に変換し、同じ箇所を同じサイズ（150x240）で切り出しました。また、High、Default、Low は、次の設定を指します。

　ご覧のように、デフォルト設定でも十分に綺麗というか、肉眼だと元画像や High とほとんど区別がきません。にも関わらず、データサイズが非常に小さく圧縮できているのが分かると思います。

　Low は画質こそ目も当てられないものの、代わりにデータサイズが異常なほど小さいです。

　これは、かなり有望な感じがしますね。

JPEG だとどうなの？

　比較のために、現在利用されている非可逆圧縮画像フォーマット中でも代表格といえる JPEG で、同じ元画像に対して画質を変えつつ幾つか圧縮した例を見てみましょう。

　一般的な手段として、ここでは Adobe Photoshop CC で「Web 用に保存...」から全体（1536x2048）を圧縮して、同じ部分を切り出してみることにします（バージョンは 20141204.r.310 x64。「Web 用に保存...」ダイアログのオプションチェックは全てオフ）。

　おっと、これは......

　あれぇ？ Photoshop の JPEG 出力って、前より頭良くなりましたか？

　昔は、低画質を選択したら、もっとひっどい出力だったような気がするんですけど......普段は 10 やら 30 みたいな低画質で出力しないから、よく分からんですねぇ。

　最低画質の 10 でも、クリックで拡大してようやくモスキートノイズが確認できる程度で、案外綺麗なのですが。画質 30 だと、もはやトーン部分くらいでしか見分けがつきません。

　こりゃ、思ったよりも綺麗過ぎる、ということで、急遽、適当にプログラムをでっちあげまして、Windows では標準的な手段であろう .NET の API を利用して JPEG 出力した結果が、こちらになります（System.Drawing.Image.Save で System.Drawing.Imaging.Encoder.Quality のみ指定）。

　あぁ、やっぱり、こっちの方がいくらか汚いですね。よしよし（良くない）

　とはいえ、それでも画質 60 以上なら、まぁ実用的と言えるくらいには綺麗かなぁ。でも、若干不満が無くはないので、以降の比較では JPEG の画質は 80 を指定することとします。

データサイズを簡単に比較しよう

　あれ、JPEG で十分じゃね？ という気分になってきますが、それではここでデータサイズを比較してみましょう。

　より詳しい比較については最後にまとめて行うことにして、まずは各フォーマットにおいて、画質とデータサイズのバランスが実際に使い物になりそうな結果のみ取り上げます。

　こうして見ると、BPG は飛び抜けて優秀ですね。

　可逆圧縮である PNG が、ある程度データサイズが大きくなってしまうのは仕方がないとしても、BPG と同じく非可逆である JPEG の 60、80 辺りと比べても、画質は遜色無く映るのに、データサイズは遥かに小さくなっています。

　ちなみに、BPG は通常は非可逆ですが、オプションでロスレスを指定することが可能で、この場合も PNG よりデータサイズがずっと小さくなります（約 900KB）。

　その代償として、エンコードにやたらと時間がかかるんですけどね。それについても、最後にまとめて言及することにします。

元画像が悪いよ

　うーん、でも、元画像が単なるスクリーンショットで、解像度が低い上に画質も大して良くないから、いまいちピンとこない部分がありますね。困りました。

　繊細な線を描くことに定評があるタイプのプロ少女漫画家の手による 1200dpi マスターデータでもあれば良いのですが、あいにくとそんな都合の良いものは手元にありません。

　仕方がないので、とりあえずスクリーントーン的な処理についてだけでも見てみることにしましょう。

　具体的には、10% グレーで塗り潰した B4 1200dpi のグレースケールデータをモノクロ２値化し、スクリーントーンの 61 番を擬似的に再現した一部を 150x240 ピクセルで切り出して変換してみました（実際に紙に印刷すると、61 番は 15% グレーくらいがちょうどいいらしいのですが、まぁ、とりあえず）。

　で、B4 1200dpi のモノクロデータをマスターとして、最近の Amazon Kindle の推奨サイズらしい 2400x3840 までグレースケールで縮小し、同じように切り出してみたのが、こちら（あまり綺麗な縮小ではありませんが、この方が分かり易いので）。

　あぁ、デフォルト設定の BPG で、十分いけそうですね。

　まー、一面同じパターンに圧縮かけてみてもあまり意味は無いかもですが、元画像さえ潰れていなければ、トーン処理もそれなりに綺麗に表現できそうです。

　それから、ご覧のように BPG は左右の端っこの処理に難がありますが、この程度ならアプリの表示の仕方次第で対処できそうですね（というより、これは表示に利用した本家に添付されている JavaScript デコーダーの問題なのかな。普通にコードを書いて展開すれば、問題無さそうな感じです）。

より詳細にデータサイズを比較しよう

　それでは、最後にデータサイズをより詳細に比較していきましょう。

　中身がある程度マンガっぽいデータの方が具合がよろしいので、上で利用した Kindle のデータを一旦 B4 1200dpi まで引き伸ばし、それを 2400x3840 に縮小したデータで比較することにします（正直、この拡縮に大した意味はありませんが、気分だけでも実際のデータに近づける感じで）。

　ちなみに、一番上の Windows Bitmap は、無圧縮な状態の参考値として記載しています。つまり、2400x3840 の 24bit データは、圧縮しないと１枚だけで約 27MB にもなるんですね（笑）

　各フォーマット毎に画質とデータサイズのバランスが実際に使い物になりそうな結果について、背景色を変えてあります。

　うへぇ、BPG は呆れるくらい優秀ですねぇ。

　今回例として使用したコミックの総ページ数がだいたい 200 として（ストアによって、奥付の有無その他で多少上下します）、2014 年における商用の電子書籍コミックのデータサイズは 50MB 前後であることが多いので、1 ページあたりでは大体 200～300 KB が目安ということになります（1 冊 100MB の場合は、1 ページ 500KB 前後）。

　それを踏まえた上で表をご覧いただくと分かるように、現状で広く利用されている画像フォーマットだと、JPEG でも画質か解像度を大幅に落とさない限り 1 ページ 200～300KB に収まりそうにありません。

　つまり、当記事の冒頭で行った比較で「解像度が低過ぎ」みたいに言及したストアは、2400x3840 どころか、下手をすると 1200x2048 よりもさらに小さいサイズを採用しているのかも知れません（800x1280 とかありそう）。

　そんな低解像度のデータを最近の高精細なディスプレイを備えたタブレットで閲覧しても、全く性能を活かせないので、なんだかもったいないですよね。

　ですが、例えばここで取り上げた BPG のように、日本のマンガ事情により適した画像フォーマットを採用すれば、データサイズを抑えつつ、より高解像度の綺麗な画像でマンガを読むことができるかも知れない訳です。

　ていうか、この結果からいくと、BPG なら 2400x3840 でも 200 ページで 50MB 程度に収まる可能性があるってことですよね。マジすごい（いまのインフラを考えると、1 冊 50MB 前後は適正なサイズかな、と思います）。

エンコード重すぎ

　とはいえ、その分エンコードにかかる時間もマジすごくて、PNG や JPEG ならばあえてわざわざ計測しようという気が起こらない程度には高速にエンコードできる環境であっても、以下くらいの時間がかかってしまいます。

　まぁ、この辺りの値はライブラリとしてこなれてくれば、どんどん改善されていくでしょうし、そもエンコードに関しては基本的にユーザーには関わりのない部分なので、多少時間がかかろうとも自動化してしまえば大した問題ではありませんが、いまのところデコードにもそこそこ時間がかかっちゃうんですよね（上の処理時間は、プロセスの起動と入出力の分を含んでいるとはいえ）。

→ 追記：もうちょっと詳しく見たら、BPG のデコード自体は、そこまで遅くもなかったです。

（上記の配布バイナリによるデコードの処理時間には、出力時の PNG エンコードが含まれており、画質というかデータの中身によって多少上下しますが、上の例の場合では、そこにおおよそ 1500 ～ 1800 ミリ秒ほどが掛かっていたようです。ということは、BPG のデコード自体にかかった時間は、非常に大雑把になりますが、上の表の数字マイナス 1600 ミリ秒くらいと考えると、そこまで遅くないですよね。いや、遅いけれども。より細かい数字は、下の追記をご覧ください）。

　将来的には多くの環境でハードウェアの支援も期待できるフォーマットだと思いますし、最終的には現行フォーマットの数倍程度に落ち着くんじゃないかと思うので、現状での計測値を必要以上に気にすることも無いとは思うのですが、BPG の場合はこのコストが画質やデータサイズとトレードオフになっている訳ですね。

おわりに

　いやぁ、予想以上に優秀ですね、このフォーマット。

　ていうか、今回作業をしていて思ったのですが、大して工夫もせずに出力した低画質の JPEG ですらあのくらい綺麗なのに、どうしてとんでもなく低品質なデータが商用で流通しているのをタマに見かけるのか、不思議でなりません（解像度が低すぎて、文字がボケて判読できないデータと出くわしたことありますからね。しかも、ノイズもすんごいの）

　具体例は避けておきますが、一体どの段階であれほど汚くなってしまうのか。表示するときの拡大縮小は他のデータと同条件ですから除外するとして、マスターデータから縮小する時にまず必要以上に劣化して、非可逆圧縮でさらに劣化の合わせ技かなぁ。もうひとつくらい、なんらかの劣化を挟んでそうですが（減色？）。業界で標準的に利用されているツールがいくつかあると思うんですけど、そのいずれかのどこかしらに致命的な問題でもあるんでしょうか。

　現行の範囲内でも、データサイズを維持したまま、もう少し高品質なデータを作れそうな感じがするのですが。

　ともあれ、この記事で言いたかったことは、別にいますぐ BPG を採用しろという無茶振りではなくて、現状で利用されることの多い圧縮画像フォーマット（PNG、JPEG）よりも、より日本のコミックに適したフォーマットがあるのではないかという疑問であり、今回の検証でそれに対する可能性くらいは見ることができたのではないかと思う次第です。BPG は、商用で使うには特許周りもどう転ぶか良く分からんですしね（HEVC に倣うなら、使用料はほどほどで済みそうですが）。

　いっその事、日本のマンガにカリカリに特化したフォーマットを、国内の誰か頭の良い人に関係各社みんなで沢山お金を払って作ってもらうのもいいんでないのと、個人的には思ったり（というか、モノクロ二値化した 600dpi くらいのデータを可逆圧縮して、そのまま使えばいいんでないのとも思うのですが。それって、なんて TIFF。いや、さらにもっとマンガに特化した形で。表示時にうまいこと縮小すれば、綺麗に見えると思うのですが。カラーは 300dpi くらいで勘弁してください）。

　とはいえ、（BPG に限らず）これまでにない新しいフォーマットを取り入れるとなると、デコーダーをクライアントに組み込むだけなら実装的には特に問題ありませんが、電子書籍としての仕様の標準化とかの方で問題視されそうです。

　が、以前の記事にもちょろっと書きましたが、個人的には日本の場合はコミックは別枠で考えちゃっていいんじゃないのと思っているクチなので、そこら辺は実際に携わっている方々が上手い具合に調整してくれることを期待したいところです（他人事）。

　だって、電子書籍の市場がそれなりの規模で、かつその売上の８割をコミックが占めるような、こんなヘンテコ特殊な国、他にないですもん。別枠扱いでいいですって。

　それに、いくら電子化されたからといって、日本式のコミックの国外市場が、現状よりも爆発的に大きくなるとは考え難いですし。そりゃ電子化は国際化と相性が良いので、多少は国外市場の拡張に貢献するでしょうけれども、そもそも風俗や感性を越えて世界に広がるような引っかかりのない普遍的なモンは、ハナからディ○ニー辺りに任しときゃいいんですよ。

　コテコテのサブカルである日本のマンガが強い部分は、「そこ」ではないでしょう。

　未熟だろうが洗練されていなかろうが、極めて個人制作に近い環境が生み出すインディビジュアルな掘り下げこそが魅力なのであって、「本当に面白いものは世界で受け入れられる」みたいな、イチからモノを作らない割りに作家に多くを求め過ぎな空論には個人的に全く賛同できないので（結果的に、そういうことはあるにしても）、日本式の電子書籍版コミックに関してはあくまで日本主導で、せいぜい日本の業界内でコンセンサスが取れてればいいんでないのというか、むしろそれを押し付けて武器にするくらい強気なつもりでよろしいのではないかと無責任に思っております。

　余談になりますが、国際化をしないで良いと思っている訳ではなく、例えばマンガボックスでやっているような多言語対応は素晴らしいので是非とも積極的にワークフローに取り入れて推し進めるべきだと考えていますが、読者層や市場規模を考慮して国内市場を最優先とすることだけは変わらずにお願い申し上げますといいますか、すみません話が逸れました。

　まぁ、なんというか、やっぱりもう少し画質どうにかなるんじゃないの？ というユーザーとしての身勝手な要望を迂遠に述べさせていただいた記事ということで。

　正直、売り物として見た場合、今の状態はちょっとどうなの？ と思います。レベルに達してないと思う。てか、ぼやっとしたデータ多すぎ。

　電子書籍として売れているのは、現状ほぼコミックだけなんですから、ここは投資しなきゃいけないところでしょう。それなのに、単純に並べてるだけの画像の作り方すら手を抜いてどうすんスか。個人的には、いま程度の画質で臆面もなく紙の本と同じ値付けをしている KAD○KAWA とか○○じゃないのと思います。紙と価格が同じは中小出版社でもありがちですが、紙と比べて費用のかからない電子書籍だからこそ、もっと攻めた値付けをすればいいのに。すぐ横でメジャーな名作が半値で売られてるのに、誰が（以下、自粛）

　当ブログの電子書籍関連記事における現場の実情にそぐわない的外れな内容が関係諸氏を苛つ立たせてしまうこともあるかと思いますが（申し訳ありません）、ヘタに内情を知ってしまうと「そうだよねー、仕方ないよねー」と自縛してしまうタイプだと自分で分かっているので、電子書籍に関しては、あえて単なるいち消費者の立場を貫きつつ、今後も外野から適当な野次をアレコレ飛ばしていきたいと思います。

　お気が向きましたら、また来年もお付き合いくださいませ。