room​/000 のバックアップソース(No.5) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• room/000^[3] へ行く。

* 特別会議室
-詳しくは[[room]]参照
-(by [[K]], 2004.06.03)

*** 圧縮しないのは非常識か？
-過去ログリスト
--[[room/000a]] 2004-05-29 (土) 12:50:09　-　2004-05-30 (日) 01:55:06
--[[room/000b]] 2004-05-30 (日) 02:04:13　-　2004-05-30 (日) 13:39:33
--[[room/000c]] 2004-05-30 (日) 13:47:11　-　2004-05-30 (日) 17:13:27
--[[room/000d]] 2004-05-30 (日) 17:15:24　-　2004-05-31 (月) 12:00:47
--[[room/000e]] 2004-05-31 (月) 13:31:21　-　2004-05-31 (月) 23:00:21
--[[room/000f]] 2004-05-31 (月) 23:07:48　-　2004-06-01 (火) 12:48:41
--[[room/000g]] 2004-06-01 (火) 12:58:57　-　2004-06-02 (水) 01:37:30
--[[room/000h]] 2004-06-02 (水) 01:47:32　-　2004-06-02 (水) 04:02:39
--[[room/000i]] 2004-06-02 (水) 16:02:18　-　2004-06-03 (木) 05:34:10
-関連リンク
--[[tmp/圧縮について]]
--[[hideyosi]]
----

-自分で言っといてなんですが、果たして本当に僕が言ったとおりであるかはある程度の検証が必要ですよね。まあtek1の展開速度が常にHDDの転送速度（キャッシュがヒットしない場合）よりも速いっていうのはよほどちぐはぐなCPUを使わない限りはあっていると思うのですが（たとえHDDが1万回転でも）、微妙なのはBMP+tek1（むしろこの場合は圧縮率のほうが重要だろうからtek2でもいいけど）がPNGや圧縮TIFFやGIFや圧縮BMPに比べて本当に小さいかどうかってことです。もちろんGIFとかですとアニメーション形式などもありますので、BMP+tek1で何でも代用できるというわけではありませんが。まあそれなら単純で処理しやすい無圧縮のアニメーション形式があってもいいじゃないか、という話にはなるかもしれません。 -- [[K]] SIZE(10){2004-06-04 (金) 15:18:39}
-ということは、tek1/tek2の仕様を固めて、圧縮速度を上げたやつをリリースしなければ、話は前に進めないわけです。いやもちろん圧縮が遅くても圧縮率には影響しませんが、いろいろ圧縮して比べるのにくたびれてしまいますので。 -- [[K]] SIZE(10){2004-06-04 (金) 15:32:36}
-でももし本当にPNGや圧縮TIFFがtek1とかtek2に負けるようだと、ある意味情けないです。だってそれらは画像対象の専用圧縮形式なので、画像に固有の統計的性質をあてにして設計されているはずで、一般的なものはそれほど縮まなくて画像なら縮むというアルゴリズムを積極的に利用できるからです。tek1/tek2のような汎用型（しかも圧縮率よりも展開速度やアルゴリズムの簡単さを図ったもの）に同等くらいのところまで追いつかれたらちょっと情けないでしょう、rkなどの高圧縮率追求型に負けるのならまだしも。 -- [[K]] SIZE(10){2004-06-04 (金) 15:37:11}
-↑の件について実験しました。PNGやGIFやTIFはなんだったのかと思う結果が出ました。＞[[［OSASK 6972］>OSASK:6972]] -- [[K]] SIZE(10){2004-06-07 (月) 19:44:50}
-PNGとの差は画像の種類にもよるかも...(今回のケースでは色数も少なく同じ色が連続する部分が多いが、そうではない場合についても検討する必要あり) -- ''Zakky'' SIZE(10){2004-06-07 (月) 22:18:47}
-とてもいい意見でそのとおりだと思います。ぜひサンプルデータをください。tekやgzip、bzip2、rkなどについては僕のほうですぐにできますので。 -- [[K]] SIZE(10){2004-06-07 (月) 22:35:20}
-pngの圧縮はLZ77だったと思います。仕様公開されてます。[[5. 圧縮について:http://tech.millto.net/~pngnews/kndh/PngSpec/5.htm]]。そして、圧縮率変更も可能です。つまり、画像専用の圧縮形式という意味では、そうではないと思います。GIFもそうではなかったでしょうか。また、うちの環境ではPNGのファイルサイズがもっと小さくなりました。lh7はサイズがあいませんでした。7z形式では圧縮形式…LZMA:4496,bzip2:5021,deflate(gz相当?):6415,deflate:5899<高圧縮型。いそいでやってるので正確な値と違うかもしれませんし、バージョンが古いかもしれませんが。それにしても、tek1,tek2(tek0も)は(bmpに関しては)非常にいい結果なのではないでしょうか。 -- ''くーみん'' SIZE(10){2004-06-07 (月) 22:44:20}
-おお、訂正情報ありがとうございます。そうかPNGの圧縮コアは汎用コアの流用だったのか・・・。圧縮率が振るわないのはスライド辞書が32KB制限されているからなのね。ためしにtek2圧縮のオプションをMD:32kにしてみました。あれ？それでも5618・・・6バイトしか変わらない？うむう、なぞだあ。 -- [[K]] SIZE(10){2004-06-07 (月) 22:57:34}
-XP標準のペイントのPNG保存でも7508、GIMPで余計なデータを保存しなければ6484程度にはなりました。…でも大きいな。 -- ''くーみん'' SIZE(10){2004-06-07 (月) 23:12:22}
-LZMAってやっぱりスライド辞書法なのかな。スライド辞書だけでbzip2よりも小さくできるとは・・・。さすがだ。となるとやっぱりtek1/tek2もまだまだなんだなあ。LZMAのアルゴリズムって簡単なのかなあ？展開速度も興味あるなあ・・・。 -- [[K]] SIZE(10){2004-06-08 (火) 00:39:06}
-LZWなんてモロに汎用の圧縮じゃないんですか？画像の性質を圧縮に利用したのはPICやPI((C)やなぎさわ氏)とかJPGですよね。tekはこれらには勝てるのかな？ -- [[I.Tak.]] SIZE(10){2004-06-08 (火) 10:09:52}
-LZWそのものは汎用ですが、TIFFやGIFでの使い方は画像イメージ全体を汎用圧縮時のように扱うのではなく、ラインごとで周期的なものにあわせて工夫するとか、なんかそんな感じのことをやっているんだろうと勝手に思い込んでいました。JPGはたぶん自然画で圧倒的に強いと思うので、たぶんtekの出番はなさそうです。MAGとかならどうなのかな？しかし仮にこれらの形式のほうが圧縮率がよかったら、PNGってなんかすごく微妙ですね・・・。先発のフォーマットのほうが圧縮率がいい？ -- [[K]] SIZE(10){2004-06-08 (火) 11:21:23}
-どうやらPIが非常にいいようです。ついでBMP+LHA。 http://cclub-flying.dsl.gr.jp/~sage/sagepage/tec/imgspec/ より。ただPIはちょっと重いという人もいるみたいです。とりあえず、BMP＋汎用圧縮に勝てるのがPIだけなら、非自然画ではPI以外のフォーマットはあまり価値がない？（これまでのソフトウェア資産やビューアの対応度をべつにすれば）。 -- [[K]] SIZE(10){2004-06-08 (火) 11:52:52}
-さっそくVix 2.21でOSASKの壁紙をPI形式で保存させてみました。5625バイトでした。この例でもPNGには勝っているようです。さすがですね。ではtekはどうなのかというと、まずtek0とtek1では歯が立ちませんが、BMP+tek2ならMD:32kでも5618なので微妙に勝っております。これはなかなか悪くない気がしました。もっとも他のBMPファイルで試したらtek2惨敗の可能性はあります。 -- [[K]] SIZE(10){2004-06-08 (火) 13:30:00}
-2chのOSASKスレッドをみたらLZOという形式が紹介されていたので探してみました（できれば特徴と圧縮ツールのURLくらいは書いておいてほしいと思いました）。LZOはlzopというプログラムで圧縮展開でき、猛烈に展開が速いことが特徴のようです。多分tek1よりも速いです。ただ、圧縮率は結構犠牲になっています。LZOは圧縮もモードによってはかなり速くできるので、インターネットでのパケット圧縮などで活躍しているそうです。で、肝心の圧縮結果ですが、-9の最高圧縮率で次のようになりました。括弧内はtek1に対するパーセントです（対rkではないので注意）。bim2binc：16015(110.6%)、kdun00b：52148(123.9%)、osaskgo：1177820（107.3%）、osask.bmp：8618(145.2%)。展開が速いのがとてもありがたいことは間違いないですが、tek1はわずかなコードの追加で結構健闘しているtek2をサポートできるということもありますし、圧縮である以上やっぱりそれなりの圧縮率もほしい気がしますので（あまり圧縮率がよくないと結局は使ってもらえない可能性もある）、とりあえずLZOは見送りです。しかしファイルシステムで圧縮するときや、OSがRAM内部のデータを圧縮してスワップを減らすなどの、展開速度だけではなく圧縮速度もそれなりに重要なときは、LZOは大変ふさわしいアルゴリズムのような気がします。 -- [[K]] SIZE(10){2004-06-08 (火) 14:36:32}

#comment

• room/000 のバックアップ一覧^[6]
• room/000 のバックアップソース(No. All)
  • 1: 2004-06-03 (木) 12:45:08^[7]
  • 2: 2004-06-04 (金) 15:43:08^[8]
  • 3: 2004-06-08 (火) 00:39:06^[9]
  • 4: 2004-06-08 (火) 14:36:32^[10]
  • 5: 2004-06-08 (火) 14:36:32
  • 6: 2004-06-10 (木) 02:45:04^[11]
  • 7: 2004-06-10 (木) 02:45:04^[12]
  • 8: 2004-06-10 (木) 16:34:53^[13]
  • 9: 2004-06-10 (木) 16:34:53^[14]
  • 10: 2004-06-16 (水) 22:15:29^[15]
  • 11: 2004-06-22 (火) 22:10:16^[16]
  • 12: 2004-06-23 (水) 16:36:26^[17]
  • 13: 2004-06-25 (金) 21:51:57^[18]
  • 14: 2004-06-27 (日) 22:58:11^[19]
  • 15: 2004-06-29 (火) 13:39:25^[20]
  • 16: 2004-06-30 (水) 08:12:50^[21]
  • 17: 2004-06-30 (水) 11:13:46^[22]
  • 18: 2004-06-30 (水) 11:13:46^[23]
  • 19: 2004-07-02 (金) 03:38:04^[24]
  • 20: 2004-07-02 (金) 14:32:04^[25]
  • 21: 2009-11-17 (火) 12:07:17^[26]
  • 現: 2024-01-08 (月) 12:59:01^[27] k-tan^[28]