15: 2004-06-29 (火) 13:39:25  |
16: 2004-06-30 (水) 08:12:50 |
| | -画像形式は別に圧縮率が一番の売りでは無いと思います。例えばPNGにはαチャンネルやγ補正といった特徴がありますし、プログレッシブにも対応しなきゃいけないし、アニメーションへの応用(MNG)も当初から考えられていたので展開が早くないといけないし。 -- ''laira'' SIZE(10){2004-06-27 (日) 21:59:16} | | -画像形式は別に圧縮率が一番の売りでは無いと思います。例えばPNGにはαチャンネルやγ補正といった特徴がありますし、プログレッシブにも対応しなきゃいけないし、アニメーションへの応用(MNG)も当初から考えられていたので展開が早くないといけないし。 -- ''laira'' SIZE(10){2004-06-27 (日) 21:59:16} |
| | -おお、気がつけばたくさんの書き込みが。lzopのソースは既にダウンロードしています。ざっと見た範囲では、tek2を超えるような技術はなさそうでしたので、とりあえずそのままほったらかしています。 -- [[K]] SIZE(10){2004-06-27 (日) 22:20:00} | | -おお、気がつけばたくさんの書き込みが。lzopのソースは既にダウンロードしています。ざっと見た範囲では、tek2を超えるような技術はなさそうでしたので、とりあえずそのままほったらかしています。 -- [[K]] SIZE(10){2004-06-27 (日) 22:20:00} |
| - | -画像形式についてですが、僕の考えはこうなのです。画像専用形式だとするからには、画像特有の性質を利用して圧縮形式を決めることができ、それが展開速度や圧縮率で有利になることにつなげられると思うのですが、実際はPIを除けばそのような効果は期待できないようなのです。結局pngも内部に汎用圧縮形式を採用しただけで、イマイチの感が否めません。・・・で、結局そういう画像圧縮形式がそういうものであるならば、無圧縮形式にtekを適用したほうが圧縮率がよくなったり展開速度が上がったりするかもしれないわけです。・・・もう一つの論点であるアルファチャンネルやガンマ補正などはもちろん重要なことですが、それはここで話題になっている圧縮とは特に関係なく、むしろ無圧縮でそのような情報をもっている形式を最初に考えてそれを適当な汎用形式で圧縮すればいいだけのことです。僕が言っているのは、PNGの全てがダメだということではなく、PNGの圧縮周りがダメだということだけです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:38:13} | + | -画像形式についてですが、僕の考えはこうなのです。画像専用形式だとするからには、画像特有の性質を利用して圧縮形式を決めることができ、それが展開速度や圧縮率で有利になることにつなげられると思うのですが、実際はPIを除けばそのような効果は期待できないようなのです。結局pngも内部に汎用圧縮形式を採用しただけで、イマイチの感が否めません。・・・で、画像圧縮形式がそういうものであるならば、無圧縮形式にtekを適用したほうが圧縮率がよくなったり展開速度が上がったりするかもしれないわけです。・・・もう一つの論点であるアルファチャンネルやガンマ補正などはもちろん重要なことですが、それはここで話題になっている圧縮とは特に関係なく、むしろ無圧縮でそのような情報をもっている形式を最初に考えてそれを適当な汎用形式で圧縮すればいいだけのことです。僕が言っているのは、PNGの全てがダメだということではなく、PNGの圧縮周りがダメだということだけです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:38:13} |
| | -Chihayaさんへのレス：まず前に残していた問題の、展開時にCPUに多少の負荷がかかるという点ですが、それはそのとおりでしょう。それがよろしくない場合も当然ありますが、一般的に期待されるケースとしてはとりあえず公開するようなものについては圧縮しておくという基本方針で問題なかろうと思います。実際の使用時に無圧縮にしておくかどうかはユーザの自由ということで。 -- [[K]] SIZE(10){2004-06-27 (日) 22:44:11} | | -Chihayaさんへのレス：まず前に残していた問題の、展開時にCPUに多少の負荷がかかるという点ですが、それはそのとおりでしょう。それがよろしくない場合も当然ありますが、一般的に期待されるケースとしてはとりあえず公開するようなものについては圧縮しておくという基本方針で問題なかろうと思います。実際の使用時に無圧縮にしておくかどうかはユーザの自由ということで。 -- [[K]] SIZE(10){2004-06-27 (日) 22:44:11} |
| | -で、順序を入れ替えて「本来なら圧縮はHDDのコントローラでやるべき」という点についてです。僕は、これは条件付で賛成です。どういう条件かというと、圧縮・展開を伴わない読み書きもサポートされるなら、ということです。・・・ああでも、やっぱりHDDのコントローラじゃなくて、チップセットのオマケ機能とかのほうがありがたいですねえ。これならHDD以外のデバイスにも使えるわけですし。・・・もしChihayaさんの想像している「HDDのコントローラによる圧縮展開」が、OSから感知されないような内部で勝手にごにょごにょ形式であるなら、僕は賛成ではありません。それは結局ファイルシステムが圧縮展開をサポートする状況をハードウェアレベルでやったようなものであり、同じ欠点を持つからです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:50:57} | | -で、順序を入れ替えて「本来なら圧縮はHDDのコントローラでやるべき」という点についてです。僕は、これは条件付で賛成です。どういう条件かというと、圧縮・展開を伴わない読み書きもサポートされるなら、ということです。・・・ああでも、やっぱりHDDのコントローラじゃなくて、チップセットのオマケ機能とかのほうがありがたいですねえ。これならHDD以外のデバイスにも使えるわけですし。・・・もしChihayaさんの想像している「HDDのコントローラによる圧縮展開」が、OSから感知されないような内部で勝手にごにょごにょ形式であるなら、僕は賛成ではありません。それは結局ファイルシステムが圧縮展開をサポートする状況をハードウェアレベルでやったようなものであり、同じ欠点を持つからです。 -- [[K]] SIZE(10){2004-06-27 (日) 22:50:57} |
| | -クラスタギャップの問題については、僕はこう考えます。まず、Chihayaさんも結局根本的な解決はファイルシステムを改善することであって、アーカイブ形式によるフォローは次善の策でしかない、という点で納得していただいていると僕が思い込んでいるので、そこが違ったら指摘してください。・・・で、OSASKやKHBIOS的な発想では、たとえばFATファイルシステム内のディスクイメージファイルをパーティションの一つとして解釈するので（註：FAT以外のファイルシステムであってももちろんかまわない）、FATの中の一部にOSASKのファイルシステムをいれてしまうことはできます。つまり、新規にアーカイブ形式を考えるまでもなく、ディスクイメージがそのままアーカイブ形式なのです。これであれこれとフォーマットを乱発しないで済みます。OSASKではないOSではこのディスクイメージファイルをOSASKの規定するフォーマットで解釈してやれば、それでChihayaさんの目的は達せられるのではないでしょうか？ -- [[K]] SIZE(10){2004-06-27 (日) 22:58:11} | | -クラスタギャップの問題については、僕はこう考えます。まず、Chihayaさんも結局根本的な解決はファイルシステムを改善することであって、アーカイブ形式によるフォローは次善の策でしかない、という点で納得していただいていると僕が思い込んでいるので、そこが違ったら指摘してください。・・・で、OSASKやKHBIOS的な発想では、たとえばFATファイルシステム内のディスクイメージファイルをパーティションの一つとして解釈するので（註：FAT以外のファイルシステムであってももちろんかまわない）、FATの中の一部にOSASKのファイルシステムをいれてしまうことはできます。つまり、新規にアーカイブ形式を考えるまでもなく、ディスクイメージがそのままアーカイブ形式なのです。これであれこれとフォーマットを乱発しないで済みます。OSASKではないOSではこのディスクイメージファイルをOSASKの規定するフォーマットで解釈してやれば、それでChihayaさんの目的は達せられるのではないでしょうか？ -- [[K]] SIZE(10){2004-06-27 (日) 22:58:11} |
| | -ベイサイドさんのいう、「（tek3が）ロジックサイズがtek0の2倍になったことを考えるとあまりメリットは見出せない。」というコメントについて。これはつまり展開ルーチンが短いことが重要という考え方だと思いますが、その論で行くと、むしろstk1あたりがベイサイドさんのベストなんじゃないでしょうか。ソースが半分になるのに、圧縮ファイルは2割しかサイズが増えていませんから。・・・僕はそもそも展開ルーチンサイズにそれほどこだわるべきではないと思いますけどね（「展開ルーチンサイズ＋圧縮ファイルサイズ」の合計が小さくなりさえすれば、問題なし。むしろ展開速度のほうが重要だと思っています）。 -- [[K]] SIZE(10){2004-06-29 (火) 11:42:52} | | -ベイサイドさんのいう、「（tek3が）ロジックサイズがtek0の2倍になったことを考えるとあまりメリットは見出せない。」というコメントについて。これはつまり展開ルーチンが短いことが重要という考え方だと思いますが、その論で行くと、むしろstk1あたりがベイサイドさんのベストなんじゃないでしょうか。ソースが半分になるのに、圧縮ファイルは2割しかサイズが増えていませんから。・・・僕はそもそも展開ルーチンサイズにそれほどこだわるべきではないと思いますけどね（「展開ルーチンサイズ＋圧縮ファイルサイズ」の合計が小さくなりさえすれば、問題なし。むしろ展開速度のほうが重要だと思っています）。 -- [[K]] SIZE(10){2004-06-29 (火) 11:42:52} |
| | + | -Kタンが追求しているバイナリーの小ささに関していうとメリットが見出せないということです。多少サイズが大きくなっても展開速度も速いんだし、問題なしという考え方からいけばメリットは十分にあります。あと、stk3のデコードサンプルコードがほしいっす。 -- ''bayside'' SIZE(10){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'' SIZE(10){2004-06-30 (水) 08:08:20} |
| | + | -bim2bin.exe in:test.bmp out:test.bin -osacmp -tek2 BS:0 MD:0 だったらうまくいきました。clv:5 はつけてはいけないようです。 -- ''bayside'' SIZE(10){2004-06-30 (水) 08:12:50} |
| | | | |
| | #comment | | #comment |
