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

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

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

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

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

 ほほぅ。

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

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

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

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

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

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

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

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

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

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

スポンサーリンク

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

まずは現状確認

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

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

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

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

Kindle
Kinoppy
iBooks
GALAPAGOS
ニコニコ静画
Yahoo!ブックストア
LINE マンガ
eBook Japan
honto
BookWalker
kobo
BookLive!

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

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

 という前提を踏まえた上で、それにしても 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 のみ使用しています。

-qset quantizer parameter (smaller gives better quality,range: 0-51, default = 28)
-mselect the compression level (1=fast, 9=slow, default = 8)
元画像
BPG High
BPG Default
BPG Low

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

画質オプションサイズ
元画像2,066KB
High-q = 0, -m = 9913KB
Default全てデフォルト値151KB
Low-q = 51, -m = 116KB

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

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

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

おまけ(2014/12/29追記)
 どうやら Mac で BPG のエンコード・デコードをしたい方がそこそこいらっしゃるようなので、バイナリを作るまでの手順をごく簡単に追記しておきます。あ、Linuxer は、自分で適当になんとかしてください(ほぼ同じですけども)。

 ほとんどの人には関係無いので、デフォルトでは閉じておきますね。

▼追記を表示▼

 以上、分かる人には不要で、分からない人には通じない、無駄なことこの上ない説明でした。

利用を考えている方への追記
 内容的には、上の「おまけ」の続きになります。

 BPG から JPEG に変換したい場合は、bpgdec で一旦 PNG 出力してから JPEG に変換すればいいと思います。PNG を経由するのがかったるかったら、bpgdec.c をちょろっといじって対応でしょうか。逆向きの JPEG から BPG は、bpgenc がそのまま読めます。

 それから、巨大なファイルを読み込むと強制終了することがあります。おおよその目安としては1辺を 8000 ピクセル以下くらいに抑えるか、もしくはソースを修正するといいと思います。

 というか、もしあなたが開発者ではない場合、いまの時点でお手元の画像ファイルを BPG に変換してしまうと、たぶん想像されている以上に物凄く不便になってしまうと思います。もう少し待って、一般に普及するかどうか見極めてから利用しても遅くありません。

 例えばウチで変換機能がついた簡単なビューワ作ったとして、いちいちそれを経由しないと扱えない内は、取り回しが面倒臭くて仕方ないでしょう。なので、現状では「ほんじゃ UI は、いっちょ自分で用意するかー」で実際に用意できる人か、もしくは使用にあたって何か明確な目的がある人以外は、ちょっと試してみるくらいにとどめて、ガッツリ使うのはまだ控えておいた方が良いと思います。

 差し出がましいようですが、老婆心ながらに。

追記:0.9.5 から bpgview という Viewer が付いたので、試しにデコード程度ならば簡単に行えるようになりました。とはいえ、ごく簡易的なものなので、実用上はそれだけでは厳しいかと思います。

JPEG だとどうなの?

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

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

PS jpeg(画質 10)
PS jpeg(画質 30)
PS jpeg(画質 60)
PS jpeg(画質 80)

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

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

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

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

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

.NET jpeg(画質 10)
.NET jpeg(画質 30)
.NET jpeg(画質 60)
.NET jpeg(画質 80)

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

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

ひとりごと
 普段は JPEG と十把一絡げにされていますが、実際はパラメータはもちろんエンコーダーの処理によっても画質がだいぶ異なる場合があるですよ。この記事は JPEG のエンコードが主題ではないので、画質以外のパラメータはなるべく指定せずにプログラムまかせで出力しています。

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

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

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

フォーマットサイズ
元画像(1536x2048 PNG。参考)2,066KB
Photoshop PNG 出力 (24bit)1,446KB
Photoshop PNG 出力 (8bit)1,266KB
Photoshop JPEG 出力 (画質 80)690KB
Photoshop JPEG 出力 (画質 60)474KB
.NET JPEG 出力 (画質 80)386KB
.NET JPEG 出力 (画質 60)288KB
BPG Default151KB

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

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

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

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

元画像が悪いよ

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

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

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

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

元画像(1200dpi)
BPG(画質 default)
.NET jpeg(画質 10)
.NET jpeg(画質 80)

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

GS 2400x3840
BPG(画質 default)
.NET jpeg(画質 10)
.NET jpeg(画質 80)

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

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

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

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

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

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

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

(一般的にグレースケールならば 8bit ですが、ここでは .NET の 8bit PNG 以外は 24bit のデータを元画像としてエンコードしています。元画像が 8bit であることは、JPEG や BPG の場合は特に有利に働きません、というか、むしろデータサイズが増えてしまう傾向にあります)
フォーマットサイズ
Windows Bitmap (24bit)27,000KB
Windows Bitmap (8bit)9,002KB
.NET PNG 出力 (24bit)5,762KB
.NET PNG 出力 (8bit)3,502KB
Photoshop PNG 出力 (24bit)3,455KB
Photoshop PNG 出力 (8bit)3,413KB
Photoshop JPEG 出力 (画質 100)2,671KB
.NET JPEG 出力 (画質 100)2,349KB
BPG Lossless2,153KB
BPG High2,087KB
Photoshop JPEG 出力 (画質 80)1,439KB
Photoshop JPEG 出力 (画質 60)987KB
.NET JPEG 出力 (画質 80)798KB
.NET JPEG 出力 (画質 60)608KB
Photoshop JPEG 出力 (画質 30)592KB
.NET JPEG 出力 (画質 30)446KB
Photoshop JPEG 出力 (画質 10)433KB
.NET JPEG 出力 (画質 10)284KB
BPG Default243KB
BPG Low28KB

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

 うへぇ、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 ならばあえてわざわざ計測しようという気が起こらない程度には高速にエンコードできる環境であっても、以下くらいの時間がかかってしまいます。

画質エンコードデコード
ロスレス1分51秒652.6秒
High2分30秒792.66秒
Default1分48秒302.28秒
Low1分31秒111.86秒
上の表で使用した 2400x3840 の 24bit データを、bpg-0.9.4-win32(本家で配布されている Windows 用のバイナリ)で処理した時間を計測。CPU は Intel Core i7-860 @ 2.80GHz。かなり古いですが、全体としての CPU 使用率は、せいぜい 10~20% 程度です。公開当初1日ほど CPU の表記が間違ってました、申し訳ありません。

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

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

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

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

Mac でも計ってみました(2014/12/30)
 それにしたって、いくらなんでも遅すぎる気がしたので、ウチのデスクトップの環境のせいかもしれんと思い、make したついでに Mac mini Late 2012 でも時間を計測してみました(メモリ 8GB。ちなみに、上の Windows デスクトップもメモリは 8GB で、監視してましたがオンメモリで処理されてます。というか、この程度のデータなら、そもそもそこまでメモリを喰わない)。

画質エンコードデコード
ロスレス56秒880.46秒
High1分19秒320.43秒
Default55秒460.20秒
Low46秒210.09秒

 こっちはソースをちょい弄って計測したので、ほぼ BPG 自体のエンコード・デコードにかかった時間のみです。

 あー......そろそろ、デスクトップ買い替えなきゃダメかなぁ......というボヤきはさておき、上の Windows 版ほどではありませんが、やっぱりエンコードはそれなりにかかりますねぇ。

 最新のハイエンド機ならばもっと全然速いでしょうが、それでもたった1枚の画像のエンコードにこんだけかかるのはスゴいですねぇ。まぁ、まだ全然最適化されてないんだろうし、config もなんも弄ってないから仕方ないのかなぁ。

 ん~......もうちょいなんとかなるやろ、ということで、まぁ、ついでだし、USE_JCTVC=y だと best quality but slow らしいので、USE_X265=y にしてコンパイルし直して、Mac mini Late 2012 で再度計測した結果は、以下の通り。

画質エンコードデコード
ロスレス6秒191.02秒
High7秒270.43秒
Default2秒920.21秒
Low1秒190.10秒

 あー、やっぱ全然速いッスね。まぁ、まだまだ遅いですけど、無調整でこの状態なので、マジメに調整すればもっといけるんじゃないでしょうか。動画じゃなくて静止画の話ですから、この程度でも使い物にはなるでしょうということで、とりあえず今回はここまでとします。

 注意点として、-q 51 (Low) を指定したらエンコードエラーになってしまったので、x265 の場合のみ -q 50 でエンコードしています。

 ちなみに、x265 のソースは、本家のリンクを辿ってここから取りました。こっちと微妙に中身が違うんですが、念の為に計測したところ、今回程度の処理だと所要時間に大きな差は見受けられませんでした(ソースは DIFF を取っただけで、中身まで詳しくは見てないです、すみません)。

 build/xcode の方でビルドすると、x265 や libcommon、libencoder は問題無いんですが、おまかせのままだと肝心の libx265 が吐かれなくて、なんとかするのが面倒臭かったので build/linux の方でビルドしました。せっかくなので Yasm @1.3.0 も前もってインストールしてあります。

 ......もう、ここまできたら Yasm が入っていない状態でも計測してみましょうか。

画質エンコードデコード
ロスレス7秒541.02秒
High9秒560.43秒
Default4秒860.21秒
Low2秒620.10秒

 差が出るのはエンコードだけです。USE_JCTVC=y の遅さを考えれば大した差ではありませんね。環境次第では、こちらで代替できそうです。

 それから、USE_X265=y でも、肉眼レベルだと USE_JCTVC=y の場合と比べて著しい画質の劣化は見受けられませんでした(多分、微妙に落ちてるんだとは思いますが)。

(追記)と思ったけど、しまった、データサイズが違いました。USE_X265=y を指定したバイナリでエンコードすると、データサイズが大きくなってしまうことがあるようです。

 まぁ、ロスレス以外はデータの中身次第という感じですけどね。傾向としては、おそらく USE_JCTVC=y の方が小さくなる(≒圧縮率が高い)ことが多いのだと思われます。

画質USE_JCTVCUSE_X265
ロスレス2,153KB6,951KB
High2,087KB2,053KB
Default243KB268KB
Low28KB42KB

 以上、追加情報として。この追記までご覧になっている方には余計なお世話かと思いますが、それぞれのライブラリのライセンスに関しては、各人で適切に判断してご利用ください。

Windows でも速くなりました(2015/01/02)
 Windows でも x265 + Yasm でソースからコンパイルすれば、同程度の率で高速化できることがざっくり確認できましたので、結果を追記しておきます。

 例えば、本家で配布されている Windows バイナリを使用して上で計った時は 1 分半以上もかかっていたデフォルト画質でのエンコードが、こちらだと 5 秒以下になります(もちろん、計測には同じマシンを使用しています。但し、Mac と同じくソースに仕込んで計ったので、こちらの結果はほぼ BPG のエンコード・デコードにかかった時間のみになります)。

画質エンコードデコード
ロスレス8秒861.31秒
High11秒160.53秒
Default4秒500.28秒
Low1秒730.15秒

 あれこれ試したんですが、VC だと却って面倒臭そうだったので、MinGW の gcc でコンパイルしました(Cygwin だと、なんかのライブラリのコンパイルが上手くいかなかった)。

 Mac の時と同じく、とりあえず make を通しただけの無調整です。コンパイラ替えて最適化してオプションをいじって呼び出し方を調整してソースを弄れば、多分もっと速くなるんじゃないでしょうか。

 というか、いじり甲斐がありそうなのは、やたら時間のかかる USE_JCTVC=y の方でしょうか。マルチコア対応もされてないっぽいですし(x265 は 8 コアを 100% 使う)。

 まぁ、どちらも私はやりませんけど(笑)

 必要なライブラリは、zlib (1.2.8)、libjpeg-turbo (1.3.1)、libpng (1.6.16) くらいなので、今回はソースからコンパイルしましたが、多分バイナリでも問題無いと思います(x265 に関しては、上の Mac の追記を参照してください)。

 場合によって必要になる CMake (3.1.0) や NASM (2.11.06)、Yasm (1.3.0) は exe があれば良いので、これらは Windows 用のバイナリを使いました。

 さらになんだかんだしたい人は、適当に dll 化しちゃえば、少しは使いやすくなるんじゃないかと。

ひとりごと
 ちなみに、この記事では暗号化のことまでは考慮していません。

おわりに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この記事をシェア
  • このエントリーをはてなブックマークに追加
  • Share on Google+
  • この記事についてツイート
  • この記事を Facebook でシェア