room​/000

特別会議室

• 詳しくは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
  • room​/000j 2004-06-04 (金) 15:18:39　-　2004-06-10 (木) 02:10:57
• 関連リンク
  • tmp​/圧縮について
  • hideyosi

• すみません。改めてこちらに書きます。せんえつながら意見とか少し思った事です。・極々小さなファイルは逆に大きくなる。既にエントロピーの高いデータ(jpeg等)に圧縮を行うのは無駄⇒無圧縮形式もあるべき。・ファイルサイズだけでなくクラスタギャップも重要視すると完璧(FAT等も考慮)⇒小さいファイルはアーカイブも行う・大きなファイルの途中を開く時先頭セクタから順次見る必要が出る⇒大きなデータは複数チャンクに分けファイル先頭に索引つける・キャッシュファイルも圧縮？・ランダムアクセスは辛くないかな？・DMA転送のみで終わる無圧縮に比べ複数バスやCPUを使うので優しくない？⇔CPU、メモリとHDD容量のトレードオフ -- Chihaya 2004-06-22 (火) 21:12:30
• たくさんの論点がありますが、まずは簡単なものだけを。圧縮してもろくに小さくならないものについては、僕も圧縮するべきではないと思います（というか小さくならない時点で、既に圧縮ではなくなって、ただのエンコードになっている）。ファイルサイズではなくて消費クラスタの観点をということについては、OSASKのファイルシステムでカバーする予定（複数の小さいファイルを1つのクラスタにまとめる）ですので、圧縮の是非の問題からとりあえず切り離します。大きいファイルを開くときに前からアクセスしなければいけないという点については、それは他の圧縮形式に言えることであって、ランダムアクセス対策を施しているtek1～tek3には無縁です（内部がマルチブロック化されており、先頭にブロック先頭位置を高速に割り出すための階層構造のインデックスまでついています）。このおかげでランダムアクセス性能も問題ないでしょう。残りの論点はあとで。 -- K 2004-06-22 (火) 22:10:16
• クラスタギャップに関してはファイルシステムでの対応は知ってますし圧縮の是非とは多少離れてるのも分かってます。ですがFAT等にも適用出来れば鬼に金棒かなと。そしてOSASKの遅延書き込み機構を考えると実際のライトバック頻度はかなり軽減されると思うので管理領域変更やセクタ移動、フラグメンテーション等のペナルティも少ない気がするのでカーネルレベルでのアーカイブ機構も検討してないのならご一考と思った次第です。本来ならデータ圧縮はHDDのコントローラでやるのが常識。わたしも圧縮するのは至極当然だと思いますよ。 -- Chihaya 2004-06-23 (水) 16:36:26
• lzopはソースコード公開してますよ。 http://www.lzop.org/download/lzop-1.01.tar.gz -- laira 2004-06-25 (金) 21:51:57
• 画像形式は別に圧縮率が一番の売りでは無いと思います。例えばPNGにはαチャンネルやγ補正といった特徴がありますし、プログレッシブにも対応しなきゃいけないし、アニメーションへの応用(MNG)も当初から考えられていたので展開が早くないといけないし。 -- laira 2004-06-27 (日) 21:59:16
• おお、気がつけばたくさんの書き込みが。lzopのソースは既にダウンロードしています。ざっと見た範囲では、tek2を超えるような技術はなさそうでしたので、とりあえずそのままほったらかしています。 -- K 2004-06-27 (日) 22:20:00
• 画像形式についてですが、僕の考えはこうなのです。画像専用形式だとするからには、画像特有の性質を利用して圧縮形式を決めることができ、それが展開速度や圧縮率で有利になることにつなげられると思うのですが、実際はPIを除けばそのような効果は期待できないようなのです。結局pngも内部に汎用圧縮形式を採用しただけで、イマイチの感が否めません。・・・で、画像圧縮形式がそういうものであるならば、無圧縮形式にtekを適用したほうが圧縮率がよくなったり展開速度が上がったりするかもしれないわけです。・・・もう一つの論点であるアルファチャンネルやガンマ補正などはもちろん重要なことですが、それはここで話題になっている圧縮とは特に関係なく、むしろ無圧縮でそのような情報をもっている形式を最初に考えてそれを適当な汎用形式で圧縮すればいいだけのことです。僕が言っているのは、PNGの全てがダメだということではなく、PNGの圧縮周りがダメだということだけです。 -- K 2004-06-27 (日) 22:38:13
• Chihayaさんへのレス：まず前に残していた問題の、展開時にCPUに多少の負荷がかかるという点ですが、それはそのとおりでしょう。それがよろしくない場合も当然ありますが、一般的に期待されるケースとしてはとりあえず公開するようなものについては圧縮しておくという基本方針で問題なかろうと思います。実際の使用時に無圧縮にしておくかどうかはユーザの自由ということで。 -- K 2004-06-27 (日) 22:44:11
• で、順序を入れ替えて「本来なら圧縮はHDDのコントローラでやるべき」という点についてです。僕は、これは条件付で賛成です。どういう条件かというと、圧縮・展開を伴わない読み書きもサポートされるなら、ということです。・・・ああでも、やっぱりHDDのコントローラじゃなくて、チップセットのオマケ機能とかのほうがありがたいですねえ。これならHDD以外のデバイスにも使えるわけですし。・・・もしChihayaさんの想像している「HDDのコントローラによる圧縮展開」が、OSから感知されないような内部で勝手にごにょごにょ形式であるなら、僕は賛成ではありません。それは結局ファイルシステムが圧縮展開をサポートする状況をハードウェアレベルでやったようなものであり、同じ欠点を持つからです。 -- K 2004-06-27 (日) 22:50:57
• クラスタギャップの問題については、僕はこう考えます。まず、Chihayaさんも結局根本的な解決はファイルシステムを改善することであって、アーカイブ形式によるフォローは次善の策でしかない、という点で納得していただいていると僕が思い込んでいるので、そこが違ったら指摘してください。・・・で、OSASKやKHBIOS的な発想では、たとえばFATファイルシステム内のディスクイメージファイルをパーティションの一つとして解釈するので（註：FAT以外のファイルシステムであってももちろんかまわない）、FATの中の一部にOSASKのファイルシステムをいれてしまうことはできます。つまり、新規にアーカイブ形式を考えるまでもなく、ディスクイメージがそのままアーカイブ形式なのです。これであれこれとフォーマットを乱発しないで済みます。OSASKではないOSではこのディスクイメージファイルをOSASKの規定するフォーマットで解釈してやれば、それでChihayaさんの目的は達せられるのではないでしょうか？ -- K 2004-06-27 (日) 22:58:11
• ベイサイドさんのいう、「（tek3が）ロジックサイズがtek0の2倍になったことを考えるとあまりメリットは見出せない。」というコメントについて。これはつまり展開ルーチンが短いことが重要という考え方だと思いますが、その論で行くと、むしろstk1あたりがベイサイドさんのベストなんじゃないでしょうか。ソースが半分になるのに、圧縮ファイルは2割しかサイズが増えていませんから。・・・僕はそもそも展開ルーチンサイズにそれほどこだわるべきではないと思いますけどね（「展開ルーチンサイズ＋圧縮ファイルサイズ」の合計が小さくなりさえすれば、問題なし。むしろ展開速度のほうが重要だと思っています）。 -- K 2004-06-29 (火) 11:42:52
• Kタンが追求しているバイナリーの小ささに関していうとメリットが見出せないということです。多少サイズが大きくなっても展開速度も速いんだし、問題なしという考え方からいけばメリットは十分にあります。あと、stk3のデコードサンプルコードがほしいっす。 -- bayside 2004-06-30 (水) 08:03:19
• 割といい成績だったbim2bin4iについてですが、bim2bin.exe in:test.bmp out:test.bin -osacmp -tek2 BS:0 clv:5 MD:0 として圧縮したBMPを tstdstk2.exe test.bin output.bmp で解凍したらデコード画像が壊れてます。バグがありませんか？ -- bayside 2004-06-30 (水) 08:08:20
• bim2bin.exe in:test.bmp out:test.bin -osacmp -tek2 BS:0 MD:0 だったらうまくいきました。clv:5 はつけてはいけないようです。 -- bayside 2004-06-30 (水) 08:12:50
• 僕は展開ルーチンのサイズを追求していません。かつては追求していましたが。詳しくは[[［OSASK 6985］>OSASK:6985]]を参照してください。 -- K 2004-06-30 (水) 11:11:08
• bim2bin4iは既に過去の形式なのでバグが残っていたとしても直しません。でもbim2bin4kのtek2もたまに挙動不審です。昨日気がつきました。これは直します。ちなみにbim2bin4iのtek2の後継はtek4です。今のtek3はbim2bin4iでいうところのtek1相当です。bim2bin4iのtek1と今のtek3を比べて、これから出てくるtek4にわくわくするのが現時点でのbim2bin4iの使い方でしょう。 -- K 2004-06-30 (水) 11:13:46
• 今後tek1のフォーマットは変更になる可能性がありますか？ -- sakky 2004-07-02 (金) 03:38:03
• まあいかなる可能性もゼロではないのですが、tek1のフォーマットをいじる可能性はかなり低いです。というのは、tek1は展開速度重視型で、圧縮率を上げるために今よりも複雑にすれば展開速度が落ちてしまうだろうからです。もし圧縮率を改善できるよいアイデアをまた思いついたとしても、それはきっと多少の展開速度の低下を招くのでtek2以降にのみ適用されるということになると思われます。・・・まあ展開速度がほとんど落ちなくて劇的に圧縮率が改善するようなアイデアだったりしたらtek1にも入れるでしょうけど、もうそんな都合のいいアイデアは存在しない気がします。・・・ってな感じです。 -- K 2004-07-02 (金) 11:43:05
• それではもう安心して使用してもよいのでしょうか -- sakky 2004-07-02 (金) 12:00:52
• うーん、そうですねえ。tek1全体（補助バッファやマルチブロックを含む）のテストは不十分なので自信がないですが、stk1の範囲なら今後変更しない可能性は98％くらいです。・・・このようなイマイチはっきりしない回答ですみません。自分でも今までの前科があるので、どうも言い切りにためらいを覚えるのです。あと1週間待ってもらえれば、これが99％か0％なのかはっきりしますし、さらに2週間くらい待ってもらえれば、100％か0％になると思います（つまりそれくらいでstk1～4の仕様は固定されます）。 -- K 2004-07-02 (金) 13:23:05
• わかりました。ところでチェックサムとかCRCは無いのでしょうか？ -- sakky 2004-07-02 (金) 13:28:44
• CRC等はstk1の範囲に入っておりまして、まずdtk1s.cでhedのbit6（0x40）を1にして圧縮データ全体のサイズを圧縮データの直前に置かせます。これで末尾に追加情報を持たせられるようになって、その追加情報でCRCやECCなどの情報を何らかのフォーマットで記録しようと思っています。ということで、とりあえず将来CRCやECCをサポートしても、今のデコードライブラリで無事に展開できるというわけです（今のライブラリではチェックはできませんが）。追加情報というのは展開そのものには必要とされない情報の全てです（チェック情報とかコメントとか）。 -- K 2004-07-02 (金) 13:43:31
• わかりました。返答ありがとうございました。 -- sakky 2004-07-02 (金) 14:32:04
• Chihayaさんとのやり取りを読みつつ、結局僕がsarフォーマットの開発に至ってしまったところを見ると、結局はChihayaさんのセンスが最強だったのかなあと思う今日この頃。 -- K 2004-12-09 (木) 11:49:36