画像圧縮プログラム開発日記

1 ：無名：2013/09/15(日) 23:10:03.18

誰の得にもならなさそうなガラクタを開発中
現在の使用言語はJava

アルゴリズムとしては
・縦横に繋がっている同色のピクセルを圧縮する
　いにしえのPIC形式っぽいイメージ(PICのソース見たこと無いけど)
・色コードをキャッシュして24bit直書きを減らす
　直前の色からの変化をLRUテーブルで持っているので、同じ色変化パターンで圧縮がきく
　ただしLRUテーブルの更新に時間がかかる

現状
・クソ遅い
・PNG比125%〜200%位の低圧縮率
・エンコーダだけ書いてまだデコーダ書いていない(エンコーダのバグが取りきれていない)

TODO
・デコーダを書く
・レンジコーダの導入
　圧縮時に統計を取るのでその時間がどの程度になるかも要考慮
　LRUが要らなくなるのでその分早くなる・・・かも
・PNG同様に色の差分を圧縮する
・差分参照マップの導入
　色の差分をどのピクセル(左上/上/左/無参照)から取ったかの情報を保存
　有効性は未確認
・チャネル別に圧縮する(効率次第)
・Cのライブラリを書く
　malloc()とか面倒くさいのでC++で妥協する可能性大(というか書かない可能性の方が大)

とりあえず、PNGにないフィーチャーは効果が低いからPNGに導入されなかった可能性大

102 ：無名：2013/10/06(日) 12:49:28.22

ベンチとってみた　元画像：http://yui.oopsup.com/download.php/blogban/1381031209_0.xz
お糸地獄.bmp　　　 2,359,350
お糸地獄.cro　　　　1,553,640
お糸地獄.jls　　　　 1,063,358
お糸地獄.png　　　　991,342
お糸地獄.p2　　　　 778,565
お糸地獄.jp2　　 　 683,694
お糸地獄.webp　　　666,346

103 ：◆WxHhsot03c：2013/10/06(日) 21:26:28.00

>>102
検証ありがとう
やはり自然画は弱いか
webpは凄いな

やはりRGBチャネル別に分けて圧縮かけるしかないな
それしか思いつかない

104 ：◆WxHhsot03c：2013/10/06(日) 21:41:20.05

それにしてもPIC2とは懐かしい
ググってたら、自分の使っている符号化方式がWyle符号だと知った
後でソースのコメントを修正しなくては

105 ：◆WxHhsot03c：2013/10/07(月) 02:34:49.68

Irfanview4.36をインストールして手持ちのテスト画像をwebpで圧縮してみたが
圧縮率凄過ぎワロタ
何をしたらこんなに縮むんだよ

106 ：◆WxHhsot03c：2013/10/07(月) 03:24:55.74

アイデアらしきものはいくつか思いつきはするのだが、
実際に実装できるのかというと難しかったりする(又は、実装できても殆どor全く効果がない)
現状でさらに出来そうな事は
・さらにピクセルの連鎖を探す(方向コードの増加と引き換えに色コード/距離コードを減少させることが出来る。効果は不明)
・方向コードにブロックソートをかけてMTF-2→レンジコーダのコンボ

ブロックソートはソートアルゴリズムに特有の工夫があるとの事なので、その辺また勉強しなければならない
図書館からWin32 APIの本借りてきたけど読む暇が取れるのだろうか・・・

107 ：◆WxHhsot03c：2013/10/07(月) 18:27:41.21

さらなる改良のためにコードを改造中
方向コードからこれまでの-1056 <= dx <= 1056、1 <= dy <=10という制限を取り払って
それぞれ±32bit値の限界までに拡張することにする

108 ：◆WxHhsot03c：2013/10/08(火) 02:46:21.30

取っても取ってもバグが出る

109 ：◆WxHhsot03c：2013/10/08(火) 04:08:23.73

また初期バージョンから取り逃していたバグが見つかる
ビット単位でデータを書き込んだ後、バッファに取っておく分のデータのマスクが間違っていた
負数を書き込むと上位ビットが残ったままになりデータ化けが発生

とりあえず動く状態に復帰する
連鎖を総ざらえするクレイジーアルゴリズムにより実行速度が劇的に低下
そして圧縮率の低下
だがブロックソートを実装すればその分以上に取り返せるはず

110 ：◆WxHhsot03c：2013/10/08(火) 21:05:56.76

ふと思いついた
方向データはレンジコーダで圧縮するので、その値が出るのが1回だけとか少ない場合には
符号長が長くなって圧縮率が低下する
そこで、2回圧縮処理をするようにして、1回目の圧縮で方向データの統計を取り
2回目では、方向データの値が重複しないものについては連鎖として扱わない事にすれば
圧縮率が改善するかもしれない
処理時間が2倍＋αになるけど

後で検討するために書き記しておこう

111 ：◆WxHhsot03c：2013/10/08(火) 22:01:12.80

サンプルデータの1つから、連鎖総ざらえ方式への変更前と後で
方向データが20万個(dx、dy各10万個)増加して、色データが190KB減少した
総ファイルサイズは70KBの増加し、概算で
(190 + 70) * 1000 / 100000 = 2.6byte = 20.8bit
方向データ1つにつき20.8bit増加している

一方、連鎖1つに必ず付随するデータが、現状では
・色コードが14bit程度
・連鎖終了コードが3bit程度
・距離コードが2bit程度
の合計19bit

(dx, dy)で19bitを超えるようなデータは圧縮しないほうがマシという事になる

現状では、わざわざデータを総ざらえする手間と時間をかけた挙句、
ファイルサイズは増加するという結果になってしまっている

112 ：◆WxHhsot03c：2013/10/08(火) 22:04:01.51

ただ、ある程度複雑な画像では、総ざらえ以前では見つけられなかったような所でも
同じ値が固まって出てきているので、ブロックソート＋MTF法によってリカバーされる可能性は十分ある

113 ：◆WxHhsot03c：2013/10/09(水) 04:04:43.44

>>110のアイデアを試しに実装してみた
結論から言うと、効果があるのは色データのコストが小さいデータ
(＝色数の少ないデータ)に限られることが分かった
まあ、当たり前の結果が出ただけの話なのだが
この辺のバランスは結構タイトなようで、色データとしては圧縮が効くが、
方向データとしてはおいしくないというようなデータを上手く探し出してやらないと効果が出ない模様
あまり苦労に見合う結果は得られそうに無い

114 ：◆WxHhsot03c：2013/10/09(水) 19:04:15.85

今日はブロックソートの勉強を進める
ソートの効率化にsuffix arrayの効率的な作成アルゴリズムが使用できるとの事
suffix arrayの作成には分布数えソート、マルチキークイックソートとそれらを利用した
Larsson-Sadakane法が有効らしい
分布数えソートに関しては、レンジコーダの実装で出現頻度表を作成するコードがあるので
それを流用すれば良さそう(ただし、正規化を行う場合があるので場合分けが必要)

suffix arrayやブロックソートのような共有部分を持つデータのソートは
大まかな大小関係をまず確定して、再帰的に正確な大小関係を求めていく事ができる
この方法にクイックソートが相性が良いらしい

115 ：◆WxHhsot03c：2013/10/10(木) 21:15:43.99

ちょこちょことコードを書きつつ理解を進めていっているが
正直かなりわけわかめ

ブロックソートをかける時は、一度に処理するデータサイズを決めておかないと
えらいことになるので、とりあえず何も考えず512K個としておく
処理の流れとしては
1. 全データからユニークなものを抜き出してMTF法用テーブルを作成する
2. 総データ数を記録する
3. 512K個のデータにブロックソートをかける
4. ソート前と同じ並びのデータのインデックスを記録する
5. MTF法でデータを変換する
6. 全データを処理するまで3に戻って繰り返す
7. レンジコーダのために出現頻度テーブルを作成する
8. レンジコーダでデータを圧縮する

ファイルに記録すべきデータは
・MTF法用テーブル
・データのインデックス値の配列
・出現頻度テーブル
・レンジコーダで圧縮したデータ列
あと、後々のために、ブロックソートの処理単位(512K)も記録した方が良いのかな？

116 ：◆WxHhsot03c：2013/10/11(金) 21:16:11.46

殆どコピペでコードを書き進める
それだけだとあんまりなので、理解した限りの事をコメントに書き込む
コピペではあまりモチベーションが上がらないのと、
理解できない部分について考え込んだりするので極めて進行が遅くなる

117 ：◆WxHhsot03c：2013/10/11(金) 21:23:42.15

今やってる部分と関係ない事ばかり思いつく
色コードに関してだが、LRUテーブルを各色に持たせる現在方式に加えて
通常(？)仕様の単なるLRUテーブル(前の色コードに対して、という状態を持たせず、
単に何回前に出たか、という情報だけの奴)との選択制にする事を思いつく
どの方式にするかをある程度事前に選択する事も考えたほうが良いかもしれない
現在のLRUテーブルが256エントリなので、色数が数万色とかだと
メモリ使用量がバカにならない上効果も無いに等しいので

118 ：◆WxHhsot03c：2013/10/11(金) 21:26:38.33

まあ、いずれにせよ画像の特性をあらかじめ調べるのはやる事になるであろう
自然画とアニメ調画像とで処理を分けるべきだと思うので
ブロックソートとLRUテーブル辺りの事が片付いたら、いよいよ自然画用アルゴリズムをやる事になるだろう

119 ：◆WxHhsot03c：2013/10/11(金) 23:46:41.79

うーん、闇雲に同色ピクセルを連結していくのではなく、
圧縮が可能なのかどうかを判断しながら連結する方法がないものか

120 ：◆WxHhsot03c：2013/10/12(土) 00:39:00.48

連鎖ピクセルの終点を格納するコードの誤りを正したら、圧縮率が低下した・・・
すなわち、最も近い連鎖をちゃんと探せていない事が明らかになったという事・・・

121 ：◆WxHhsot03c：2013/10/12(土) 16:25:32.60

誤りだと思った事自体が誤りだった(わざわざ間違った方へ修正してた)
最も近い連鎖を探すようにコードに手を入れてみたが、
コードが醜くかつ遅くなった割に見返りは小さかった

122 ：◆WxHhsot03c：2013/10/12(土) 23:10:10.30

どうにかブロックソートのエンコード側が動くようになった
だがまだMTF法とか実装しなければならない

123 ：◆WxHhsot03c：2013/10/13(日) 01:09:45.41

出来たと思いきや、壮絶な勘違いにより後戻り
もう何がなんだか

124 ：◆WxHhsot03c：2013/10/13(日) 04:37:44.96

・・・くっ、もしかしてブロックソートって
同じ値が長く連続するようなデータは上手く並べ替えできないのか？

125 ：◆WxHhsot03c：2013/10/13(日) 21:41:45.57

参考にしている(というかここからコードをパクっている)のサイト
http://www.geocities.jp/m_hiroi/light/pyalgo48.html
にあるプログラムを使用して、ブロックソートの性質を調べると
・同じデータが6個以上連続するとソート結果が壊れる(普遍性は不明)
・全く法則の無いデータはソートしても無駄
という事が分かってきた

というか、そもそも、ブロックソートが上手く動作する原理は
・ある文字と、その次に現れる文字には法則性がある事を利用してデータを整理する
という事らしい
まあデータ圧縮の基本は、統計的な偏りを利用するという事だから当然の話なのだが

126 ：◆WxHhsot03c：2013/10/14(月) 03:35:26.72

ブロックソート前と後でデータの連続度を取ってみた
結論
当プログラムの出力データに対し、ブロックソートの効果は殆ど無いか逆に悪化していた
・・・・・・・・
ショーーーック

(ブロックソート自体は非常に優秀な圧縮支援アルゴリズムです、念のため)

127 ：◆WxHhsot03c：2013/10/14(月) 21:07:00.52

現状の出力データにさらに圧縮を掛けようというのが無謀な考えに思われてきた
どちらかというと出力するデータ数を削減する方向に向かうのが正しいような気がする
しかし、どうやってそんな事を実現するのか、想像がつかない・・・

128 ：◆WxHhsot03c：2013/10/15(火) 22:20:04.11

画像を色の差分に変換して、どの位色数が減るか調べてみた
結果として、自然画など数万〜数十万色の画像では、1/3〜1/7くらいにはなる事が分かった
しかし、それだけでどれ位縮むものだろうか

129 ：◆WxHhsot03c：2013/10/16(水) 21:30:14.85

行き詰ってきた・・・

130 ：◆WxHhsot03c：2013/10/17(木) 23:02:49.99

LRUテーブル参照をWyle符号化してセコく縮める
モチベーションが上がらないながらも、色差分で扱うためのコードをちまちま書く

131 ：無名：2013/10/17(木) 23:47:30.61

ガンバレ

132 ：◆WxHhsot03c：2013/10/18(金) 21:16:01.10

>>131
ありがとう

133 ：◆WxHhsot03c：2013/10/18(金) 21:17:45.88

Cプログラミング診断室を読んで普段の悪行を反省する
http://www.pro.or.jp/~fuji/mybooks/cdiag/index.html#mokuji3
だが身に付いた悪癖は油汚れのように染み付いて取れないのだった

134 ：◆WxHhsot03c：2013/10/19(土) 21:52:56.39

画像バッファクラスを、差分対応版に書き換える
エンコーダクラスとデコーダクラスは、最早構造的に寿命が来ているような気がするが、
強引に書き換えることにする

135 ：◆WxHhsot03c：2013/10/20(日) 22:07:22.36

差分バージョンを実装した
例によってバグの嵐に会う

136 ：◆WxHhsot03c：2013/10/20(日) 22:48:51.41

あからさまなバグは除去し、どうにか動くようになった
画像によっては幾分縮むようになった
しかし、圧縮率が悪化する画像もある
調べてみた結果、色情報の削減効果以上に、方向情報の増加の影響、
特に遠距離の連鎖データの増加が圧縮率の悪化を招いていることが分かった

色を差分データで扱うことで、色コードの分布がバラバラになってしまっているのだろうか
まさかこんな事になるとは思わなかった

137 ：無名：2013/10/21(月) 22:06:09.86

ぎゃんばって

138 ：◆WxHhsot03c：2013/10/21(月) 23:36:47.39

>>137
ありがとう
だがそろそろ限界が見えてきた模様

139 ：◆WxHhsot03c：2013/10/22(火) 00:00:13.53

色情報を圧縮できないかどうかを調査する
差分変換後の色情報(RGBそれぞれの差分dR、dG、dB)に対し
・値の分布
・1つ前の値との関連性(LRUテーブルの効果)
を調べた

結果は芳しいものではなく、値の分布は大体均等、
LRUテーブルに関しては3bit圏内(0〜7番)に約5%の分布、
5bit圏内(0〜31番)に約13%の分布というものだった
判別bitに1bitは必要なので、収支的に見合わない

140 ：無名：2013/10/22(火) 12:01:40.62

公開しないの?

141 ：◆WxHhsot03c：2013/10/22(火) 22:39:11.16

>>140
正直、新バージョンで確実に圧縮率が向上するわけではないので・・・
ファイル形式としても特別な旨みがあるわけでもなく、あくまで個人の研究レベルに留まっているので
でもひとまずうｐ

実行ファイル
http://yui.oopsup.com/download.php/blogban/1382448921_0.jar

ソース
http://yui.oopsup.com/download.php/blogban/1382448995_0.bz2

142 ：◆WxHhsot03c：2013/10/22(火) 22:55:46.12

連鎖とみなす範囲を-127 <= dx <= 127に限定してみた
下手に連鎖を繋げるより、制限した方が縮むというというのが何とも・・・
画像によって、以前のバージョンより圧縮率が向上したり低下したり
簡易的な判定メソッドは実装してはいるものの、色コードそのままと差分形式と
どちらが縮むのかという判定は想像以上に難しいようだ

143 ：◆WxHhsot03c：2013/10/23(水) 23:43:44.89

やべえ、何も思いつかない
PNGとWebP loselessの資料を読み返すか

144 ：◆WxHhsot03c：2013/10/23(水) 23:46:53.02

loselessじゃねえ、losslessか

145 ：無名：2013/10/24(木) 22:47:11.20

負けなしか

146 ：◆WxHhsot03c：2013/10/25(金) 02:35:27.47

負けなしどころか、ほとんど勝ってねえ

147 ：◆WxHhsot03c：2013/10/25(金) 02:41:04.34

さて、ひとまず、今の方式の限界が見えたので、ここらで一旦開発終了としたいと思います

作者のヘボさ故にバグを作りこんでは修正する毎日、ここを見てくださる方々のレスには大変励まされました
短い間でしたが、本当にありがとうございました

148 ：無名：2013/10/25(金) 11:50:40.08

おつかれ
次回も期待

149 ：無名：2013/10/25(金) 23:20:29.27

内容はわけわかめだったが情熱は伝わったぞ
お疲れさま！

150 ：無名：2013/10/28(月) 15:46:37.46

おつかれ

151 ：無名：2013/10/28(月) 17:32:03.12

乙乙！