結論から言うと私が多く扱うような自然画像では劇的な圧縮効果はなく、こちら界隈でおなじみの 4:4:4、4:2:2、4:2:0 と言った色信号の圧縮もテレビ信号ほどの圧縮効率を感じなかった。動画じゃないから時間軸方向の圧縮ができないから仕方ない。それでも静止画としてJPEGよりは高画質のままデータ量を減らせてるし、無劣化圧縮という選択肢も増えてる。高圧縮に向いている画像もあるため、それは下記で示す。

　エンコードに使える元画像がJPEGとPNGだけのため、写真のオリジナルデータからテレビの720pサイズ（1280x720）に縮小し、PNGにしてからBPGのエンコーダーに通して試してみた。色の取り扱いなど特に書いてない部分はデフォルト設定である。

　4:2:2だが、現在バージョン0.9.4では bpgdec8b.js で表示できず、bpgdec.js なら表示できた。尚、4:2:0はあるが4:1:1 は実装されていない。わかる人だけわかって、この違い。

　このエンコード、デコードプログラムは特許にひっかかるらしく、ここでは出力結果は示せない。個人での実験に留まってるようだ。ということは GIF のときの問題や MPEG のときみたいにライセンス料を払えとなり、出る前から廃れる可能性が言われ始めている。

　現在、ウェブサイトで公開するには、JavaScriptをアップロードし、実行可能としなければならない。これは小さい画像はJPEGにすることによって当方の主義に反しないよう作ることができるが、JavaScriptを実行させないと大きな画像は見えないことになる。

　JPEGまたはPGN画像からの変換は昔ながらのコマンドラインから指定する必要がある。これは有名になれば誰か有志が GUI としたプログラムを作るだろうから、多数画像の一括自動変換も可能となるはずだから大きな問題ではない。

　品質設定は、0-51まであって初期値は28である。数字が少ないほうが高画質。圧縮率の悪そうな画像にて、品質設定を40にしてみたら潰れた部分が多発して実用性なし、35あたりが限界であったが画像によっては上下するのかもしれない。


本当の問題は使う必要性があるかだ


どういう画像を使ったかと各種圧縮後のデータを示す。ライセンスに引っかかる可能性から当サイト上にデコードプログラムは実装しておりません。最下部にJPEG化した比較画像を追加した。
元データは1280x720 @ RGB 8bit
PNG - 2.2MB
loss less - 1707KB
JPEG 70% - 540KB
BPG 4:4:4 - 306KB / 4:2:2 - 281KB / 4:2:0 - 266KB

Quality 10 - 966KB / Q20 - 549KB / Q35 - 150KB / Q40 - 76KB



元データは1280x720 @ RGB 8bit
PNG - 1.5MB
JPEG 70% - 344KB
BPG 4:4:4 - 156KB / 4:2:2 - 150KB / 4:2:0 - 144KB



元データは1280x720 @ RGB 8bit
PNG - 764KB
JPEG 70% - 133KB
BPG 4:4:4 - 27KB / 4:2:2 - 25KB / 4:2:0 - 23KB



元データは1280x720 @ RGB 8bit
PNG - 728KB
loss less - 568KB
JPEG 70% - 177KB
BPG 4:4:4 - 63KB / 4:2:2 - 57KB / 4:2:0 - 52KB



　大きな画像と同系色の部分が多い画像での圧縮率の高さが目立ったが、細かい花が入り乱れた花畑や森の大量な葉っぱ、電飾（イルミネーション）、水滴などビデオでボロボロになるような画像の圧縮率はよくなく、やはりそういう画像にはデータを食わしてやりたい。現在のハイビジョン放送で使われてる時代遅れなMPEG-2の基礎となる圧縮方法に比べたら劇的に綺麗でした。

　GIFで高い圧縮率となる256色な線画データであると、BPGでの圧縮率を上げても耐えられた。そのような場合、若干データ量は増えるが、Y Cb Crじゃなく RGB にすると文字の輪郭とかが綺麗になった。このテストには当方が熱海の地図として使ってる1600ｘ1500サイズのGIF画像を使った。170KBのGIF画像が、BPGで100KBまでなら遜色なく、80KBまでがパッと見で区別がつかない画像だった。ロスレスも作ってみたが、色数の少ない線画像のようなら高い圧縮の画像でも十分だった。

　データ量は、ちりも積もれば山で、利用者としてパケット料金もあるが見た目に遜色なくデータ量を減らすことに意味がある。固定料金だから関係ないということはない。全体的なデータ量が増えてるから固定料金が高いんだから。

　小さい画像では圧縮率が上がらないためJPEGと大差なくなる。多くの画像を配置すると現状ではJavaScript実行による表示のため遅くなる。サムネイルはJPEGで、大きな画像を綺麗に表示するにはBPGと言った使い方が考えられるが、それも “フリー（使用料無料）” でなくてはダメだ。普及するわけがない。

方式なんてなんでも構わないから、早いところ標準化された新しいものが欲しいところ。
JPEG2000ってどうなった？

---

＜追記 2015年1月4日 18時　　研究結果＞

百聞は一見にしかずってことで試験画像をアップロードしてみた。ウェブサイト上ではプログラムは使用せず、各種品質で圧縮した画像のデコードは内部のパソコンで行い、画面キャプチャーして同一の圧縮率にてJPEG画像を作った。

元画像PNG → 各圧縮率にて BPG生成 → 表示 → 画面キャプチャー → JPEG

→ 品質設定 Q=40 （低画質、.BPGのとき 76KB）

→ 品質設定 Q=35 （低画質、.BPGのとき 150KB）

→ 品質設定 Q=28 （初期値、.BPGのとき 306KB）

→ 品質設定 Q=20 （高画質、.BPGのとき 549KB）

→ 品質設定 Q=10 （更に高画質、.BPGのとき 996KB）

→ 品質設定 LossLess （無劣化、.BPGのとき 1707KB）

→ 元画像 （PNG 2.2MB）

Q=35までギリギリ耐えている花の部分とかがQ=40だと潰れてしまってます。画面右側の水面および堤防の部分の劣化もわかりやすい。でもそれは非圧縮のファイルサイズからしておよそ30分の1になってるので、JPEGより高性能だといえる。

※ 表示はBPGの時のファイルサイズで、アップロードした画像は同一の圧縮率にてJPEGにしたもの