サイトトップへ
OSASK.NET
  サイトトップへ       新掲示板(閉鎖済)   Wiki(凍結済)   旧掲示板(廃止済)   ニュース(廃止済)  
ページ内コンテンツ

tekのページ anchor.png

  • (by K, 2004.11.15)
  • ここは対外的なページではなく、いろいろな議論とか不確定情報とかも話題にできるページ。
    • 対外的なページは[[Z:tek]]。
Page Top

Kの基本方針 anchor.png

  • つまり他の人にとっては「Kが推奨する方針」くらいの意味です。
  • l2d3とtek0はフェードアウト。
    • ただし過去のバージョンでl2d3やtek0をサポートしたことあるアプリについては、例外的にサポートを続ける。
Page Top

tek対応状況 anchor.png

  • 厳密にはosacmp対応状況
  • Windowsアプリ
    • edimg0h以降で l2d3/tek0/tek1/tek2/tek5 に対応。
    • obj2bim4b以降で tek0/tek1/tek2/tek5 に対応。
      • このobj2bim4は、tolset08に入っている。
    • sartol0i以降で tek1/tek2/tek5 に対応。
    • Susieプラグイン spibmpk1.spi で tek1/tek2/tek5 に対応。
      • このプラグインはBMPのプラグイン（8bitカラー、24bitカラー）。
      • Susieは拡張子ではなくファイルの中身でフォーマット判定をする仕様なので、.bmpでも、.bmp.tek5とかでもどちらでもOK。
  • POSIX（Linuxとか）アプリ
    • (まだ書いてない)
  • そのほか
    • OSASK
      • OSASK ver.4.6以降で tek0/tek1/tek2/stk5 に対応。
      • OSASK ver.4.7（Twicth4）以降で tek0/tek1/tek2/tek5 に対応。
      • shibai1aが、 tek1/tek2/tek5 の2重圧縮に対応。
    • Mona
      • 拡張子の変更が必要になるが、Mona 0.2.0では stk5 に対応。
Page Top

リンク anchor.png

  • [[Z:tek]]
    • 対外向けtekページ。他の圧縮形式との定量的な比較あり。
  • tek5​/rangecoder
    • tek5で使われているレンジコーダの紹介。
  • room​/000
    • 圧縮しないのは非常識か？
  • why_sar
    • sarの紹介だが、一番下に他の圧縮形式との定量的な比較がある。
  • tek1
    • かなり古い内容のページ（tek1​/comp以外はほとんど現状を反映していない）。
      • tek1​/compにも、他の圧縮形式との定量的な比較がある。
  • tek2、tek3
    • これもまた古い内容のページ。全く現状を反映していない。
  • tek​/history
    • これはおすすめしません（これを読んだらかえって混乱すると思う）。
  • (まだ他にもたくさんあるのでちょくちょく書き足します。)
Page Top

その他のリンク anchor.png

  • 自分でtekに関するページを作ったら、自発的にURLとちょっとした紹介（1行程度）を書き足そう！
    • この欄に限り、書き足し自由＆自分が書いた文章の編集も自由。
  • たまにKがこの欄にあるリンクを上のリンクへ引き上げます。



  • [[dev-j:t5exe]] 大したものじゃないから追加するのも引けたけど。Unix風味環境(ELFとかPEとか関係ないのでcygwinでも動くのかな?)で実行ファイルを圧縮できます。
Page Top

OS-Wikiのtekのページの旧内容 anchor.png

  • 一時退避的にここにおきます。
Page Top

tekフォーマット誕生のいきさつと目的など anchor.png

  • もともとtekはOSASKの実行ファイル内の.dataセクション内の0x00のかたまりの部分を、他のOSと同等程度の手ごろな大きさにまとめたいという必要から開発がはじまった。
    • この問題はOSASKに限らず他のOSでも発生している。win32やLinuxでは、.bssセクションは必ずゼロクリアされるというルールを設けることで、この問題を解決しているようである。
  • ただ0x00をまとめるだけならランレングス圧縮でもつければそれでよかったのだが、.dataセクション内の初期値群はもしかしたらintで1のかたまりの部分があったりするかもしれず、そういう場合も圧縮できたらちょっとかっこいいかなと思い、軽い気持ちでごく簡単なスライド辞書式のLZ圧縮を採用してみた。OSASKのAPIにはLZ圧縮を解くためのAPIがあり、アプリのスタートアップルーチンがこのAPIを呼んで.dataセクションを初期化するという仕組みになっている。
  • これで結果的にOSがサービスの一部として圧縮展開用のルーチンを持つことになった。どうせならもっとこのルーチンを活用してやろうということで、ファイルアクセスの際に圧縮されているかどうかのチェックを自動でやるようにして、圧縮されていればOSが内部で自動展開し、圧縮の有無をアプリに感知させることなくシームレスにアクセスできるようにしてみた（圧縮しても拡張子を変える必要はない）。これが大成功で、あらゆるアプリもあらゆるデータもコンパクトになった。ディスクアクセス時間も大幅に短縮された。
  • またアプリも単純化された。たとえば画像ファイルを考える場合、OSASKではBMPだけをサポートしていればたいていの用途にかなう。しかもBMPもRLE圧縮のサポートはなくてもそれほど問題ではない。もちろん、TIFやGIFやPNGなどもサポートすればそれに越したことはないが、そんなものがなくても、適当なツールで画像を一度無圧縮BMPに変換し、それをtekで圧縮すればそれでいいわけである。一般的な傾向として、tek圧縮のほうがTIFやGIFやPNGよりも圧縮率がよく、展開も速いからである。
  • こうしてOSが圧縮を積極的にサポートする効用に気がついたため、この技術をOSASKというOSに限定されない技術とし、展開ルーチンライブラリの開発や、フォーマットの改良などを行っている。
  • このようないきさつのため、tekフォーマットの目的は次のようになっている。
    • 汎用圧縮フォーマットであることを追及する。特定の対象にのみ強いフォーマットにはならないようにする。
    • 展開に必要なリソースに配慮する。tekフォーマットの意図するところは、GIFやTIFなどの代用的なものであり、アーカイバのような書庫管理ではない。つまり展開速度は十分に速くなくてはならないし、展開時に大量のワークエリアが必要であったりしてもいけない（もし展開のためのリソースが多ければ、その画像やデータなどを直接閲覧できない場合が発生してしまう）。もちろんtekは画像ファイル限定ではなく、テキストも実行バイナリも各アプリのセーブデータも、その他のなんにでも適用可能で、一様に利益をもたらす。
      • なおアーカイブ用途としては、sarという形式を提唱している（sarはtarのような無圧縮規格であるがもちろんtekを適用してもよく、実際sarファイルのほとんど全てはtekが掛かった状態で扱われている）。 参考→why_sar
    • 非常に著名な圧縮形式では、圧縮を明示的に解かなくても内容を自由に閲覧できるツールが開発されているが、tekはそういう利用を最初から前提にして、この分野でのデファクトスタンダードなフォーマットになるのを目指している。圧縮しても拡張子を変えないでよい（＝それくらい冗長なシグネチャがある）というのもそのためである。OSASKのようにOSレベルでの自動展開サポートが普及するか、それが無理なOSでは各アプリがファイルオープンの際に先頭16バイトをチェックし、tekであれば展開した後に扱う機能が普及してほしいと思っている。
    • この流れにより、現在のように多種多様な形式が乱立するのではなく、シンプルなフォーマットを（必要に応じて）共通の汎用アルゴリズムで圧縮する、という流れになればと思う。もちろんtek圧縮は完璧ではないし、対象によってはより圧縮率の高いものやより高速に展開できるものもあるだろうが、現状ではtekに劣るものがまだたくさんあるというのも事実である。tekに劣る形式が徐々にフェードアウトしてtekに一本化されれば、展開ルーチンの最適化はさらに進むであろうし、もしかしたらJPEGやMPEGのようにデコード支援用のハードウェアが開発されるかもしれない（tekの展開アルゴリズムはワークエリアが少なくて済むので、ハードウェア化もしやすいかもしれない）。
    • なお今のところ圧縮時間に関してはほとんど配慮していない。それは目的とは直接関係ないからである。したがって、圧縮時間も重要になるような用途には多分向かない。まあしかし、圧縮率を犠牲にしてもいいのなら、いくらでも圧縮時間は短縮できるであろう。
    • そして圧縮の世界もtekを超える基準での競争に限定されることで、より発展していくだろう。
Page Top

バリエーション anchor.png

  • 開発済みの形式
    • tek0：tek系初代の形式
      • 展開アルゴリズムの単純さ、展開速度、圧縮率、の3つのどれにおいてもいまいちぱっとしない。補助バッファ利用圧縮やマルチブロック拡張機能などもない。
    • tek1：展開速度・展開アルゴリズムの単純さをもっとも追求した形式
      • 圧縮率はかなり低い。
      • stk1仕様なら展開ルーチンは270バイトで書ける。
      • フルセット仕様の中には未だ開発検討中で確定していない部分もある。
    • tek2：tek1の展開速度を2～5割ほど犠牲にして圧縮率を改善した形式
      • stk2仕様なら展開ルーチンは531バイトで書ける。
    • tek5：圧縮率をもっとも追求した形式
      • その圧縮率はほとんどのケースでgzipやbzip2を超える。展開速度の点でもこれらに対して引けを取らない。LZMAをアルゴリズムの基礎においているが、改良を加えているためLZMAよりも高速・高圧縮率になる傾向が強い（LZMAより高速なのはstk5のみ）。
      • stk5仕様なら展開ルーチンは1426バイトで書ける。
Page Top

ベンチマーク anchor.png

  • tekのそれぞれについての簡単なベンチマークです
zero64k0x00が65536個並んだだけのファイル。人間の目にはこれはすごく圧縮できそうな感じがする。
bim2binc日本語を含むCのソースファイル。
osaskbmp16色ビットマップファイル。
osaskgo実行ファイル。
kdun00bRPGゲームに必要な複数のファイルを収めたディスクイメージ。実行ファイルやデータなどが混在している。


tek0上記参照
stk1tek1のサブセット版
stk2tek2のサブセット版
stk5tek5のサブセット版
tek5上記参照
lh7LHAのlh7形式
gzip有名な形式
bzip2有名な形式
LZMA7-zipの中の形式の一つ　かなり良い
PPMd7-zipのPPMdの192MBオプション
LZO展開速度に特化した形式
dgcDGCA 1.06
paqarpaqar 1.3のオプション-5
      • paqarは展開時間がきわめて長く、さらに膨大なワークスペースを要求するために、上記の形式と同列で比較するべきではないと思うが、それぞれのデータがどこまで圧縮できるかを示す指標として導入した。まだ圧縮の余地があるのに圧縮できていない場合を発見するのに役立つ。

  • サイズ
    osaskbmpkdun00bbim2bincosaskgozero64k
    無圧縮39333465536053792197374165536
    LZO861852148160151177820422
    stk177404985517166127493127
    stk271354679416323117234429
    lh7646745520141811099064117
    tek063894624615019114966228
    gzip568742553134671087874108
    PPMd56093954611099966659151
    dgc50724321612624986880528
    bzip249064730612903104741143
    LZMA4236340371270894236990
    stk53860335491271294237529
    tek53669329091257993692829
    paqar242929157921574851243
  • 規格化指数（上記でそれぞれの一位が100になるように規格化しただけのもの）
    osaskbmpkdun00bbim2bincosaskgozero64k
    無圧縮161932248583.7263.7242726
    LZO354.8178.9173.8157.41563
    stk1318.6171.0186.3170.3100.0
    stk2293.7160.5177.1156.6107.4
    lh7266.2156.1153.9146.8433.3
    tek0263.0158.6163.0153.6103.7
    gzip234.1145.9146.1145.3400.0
    PPMd230.9135.6120.4129.1559.3
    dgc208.8148.2137.0131.81956
    bzip2202.0162.2140.0139.9159.3
    LZMA174.4116.7137.9125.9333.3
    stk5158.9115.1137.9125.9107.4
    tek5151.0112.9136.5125.2107.4
    paqar100.0100.0100.0100.0159.3
    • tek5については、why_sarにも圧縮率比較データがあります。
    • さらにテスト：[[Z:tek/dump]]
  • 展開速度
    • （準備中）
Page Top

解説 anchor.png

  • 圧縮率比較方法に関するKの主張。
  • 一般的には圧縮の比較といえば圧縮率の比較をすると思うが、これはあまりよい指標ではないと考える。上記に挙げた規格化指数でも圧縮率でも、どちらも分母が違うだけであって相対的な比較の際には本質的な違いはないが、しかしどちらがより有用な知識を与えてくれるかという観点では異なる。まずは、以下の2つの印象を比べてほしい。

      • 規格化指数
        osaskbmpkdun00bbim2bincosaskgozero64k
        LZO354.8178.9173.8157.41563
        stk1318.6171.0186.3170.3100.0
        stk2293.7160.5177.1156.6107.4

      • 圧縮率
        osaskbmpkdun00bbim2bincosaskgozero64k
        LZO2.19%7.96%29.8%59.7%0.644%
        stk11.97%7.61%31.9%64.6%0.412%
        stk21.81%7.14%30.3%59.4%0.443%

  • 圧縮率だけ見てしまうと、どうしても数値の大きいosaskgoのところを改善したいと思ってしまう。しかしここは規格化指数で分かるとおり、圧縮限界に対して1.6倍程度であり、むしろ改善の余地が大きいのはosaskbmpなのである。
  • 圧縮率が小さい値になるということは、要するにもとのファイルが「すかすか」で本来持っている情報量に対して非常に巨大であったということでしかない。ここで規格化指数の無圧縮の部分を見ると、無圧縮のosaskgoは本来の情報量の2.6倍、無圧縮のosaskbmpは162倍ということが分かる。こういう差を考慮に入れずに、単に元のファイルに対する大きさだけで判断するのは、市場価値1万円のものがあって、A店はこれに100万円の値札をつけ、B店はこれに2万円の値札をつけているときに、A店で値引き交渉して10万円に負けさせて購入した場合（9割引）と、B店で値引き交渉して1万2千円にした場合（4割引）とで、A店での取引のほうが得だと判断するのと同じことである。・・・値札に惑わされてはならない（笑）。
  • いくつかの種類のファイルを適当に混ぜて、この合計サイズによって比較をする人もあるが、これもいかがなものかと思う。実用上の参考になるようなブレンド比は人によって大きく異なるだろう（画像を多く持つ人もいるし、ログなどのテキストをたくさん持つ人もいる）。またたとえばosaskbmpとosaskgoとを足してしまえば、大幅に小さくなるosaskbmpの部分はosaskgoのサイズの前に埋没してしまい、その優劣は全く分からなくなるだろう。したがって勝手に混ぜることなく、それぞれを提示するのが好ましい方法だと考えている（kdun00bの例は統計的性質が大きく異なるデータが混在した一つのファイルをどれだけうまく圧縮できるかというところを見たいのであえて混ぜてある。それぞれを圧縮して合計するのとは意味が大きく異なることに注意）。
Page Top

ダウンロード anchor.png

  • （準備中）
Page Top

課題 anchor.png

  • マルチブロックサポートがまだできてない
  • ECCレコード・リカバリーレコード（エラーチェック＆修復機能）のサポートがまだできてない
  • フレーズモードのサポートができてない
    • これができると、たとえばtek1​/compの「おまけ」にある minna.sar の圧縮率が9%くらいよくなる。tek5のbim2bincも136.5→132.8と3%ほど改善する。
  • 差分モード（補助バッファ）のサポートができてない
  • ファイル分割サポートがまだできてない
    • これはtekではなくsarでのサポートになる可能性もある。
  • まともな圧縮ツールがない
    • bim2binはしょせんOSASKリンカであって、いつまでもそのおまけ機能でごまかすのは難がある。
Page Top

こめんと欄 anchor.png

  • http://compression.ca/act/ 圧縮率、速度の比較で有名なサイト。比較のテストデータも入手可能。 -- 名無しさん 2004-10-17 (日) 10:07:22
  • ↑過去にそこのサンプルを使おうと思いましたが、比較のテストデータがまともに入手できたためしがないです。たとえばtextのサンプルを例にとりますが、ページの説明ではサイズが[1344739, 586960, 2988578]のはずなんですが、僕がダウンロードして解凍すると[1344739, 586969, 3005020]になります。textに限らず他のファイルでも同じ傾向で、いつもなぜかちょっと違います。 -- K 2004-10-17 (日) 12:13:39
  • http://www.maximumcompression.com/data/bmp.php こんな比較はどうでしょう？ -- 名無しさん 2004-10-26 (火) 09:24:00
  • 題材はいいのですが、tekにはこのような写真系画像に向いた拡張が予定されており（差分値を使った圧縮：tek1​/adv2）、できればそれができてからやってみたいです。・・・でもまあとりあえず今やっても悪いことはないと思ったのでやってみました。tek5で967384バイトでした。 -- K 2004-10-26 (火) 12:46:30
  • そのページのほかのものと比べるとこんな感じです。太字は僕がテストしたものです。 -- K 2004-10-26 (火) 14:54:02
    フォーマットサイズ指数
    BMF 2.0669016100.0
    PAQAR 4.0688977103.0
    7-ZIP 4.09b (PPMd)764420114.3
    WINRAR 3.40789353118.0
    bzip2890161133.1
    tek5967384144.6
    LZMA978124146.2
    DGCA 1.061004896150.2
    CABARC 1.00.0106 (CAB LZX:21)1036845155.0
    WINZIP 9.01225734183.2
    LHA32 1.88.3.141241336185.5
    GZIP 1.2.41256638187.8
    • tek5の拡張版（差分値を使った圧縮）では指数換算で138くらいになる見込み
  • http://www.maximumcompression.com/ 画像以外の題材（テキスト, EXE）もテストされていますよ。 -- 名無しさん 2004-10-26 (火) 19:11:33
  • それはわかっていますが、そんなこといっていたらきりがありません。ここは圧縮比較サイトではなく、tekの紹介ページです。既にここに書いた内容だけで傾向はつかめると思います。徹底比較がしたい人は比較サイトを作ればいいでしょう。 -- K 2004-10-26 (火) 19:32:55
  • 徹底比較がしたいのではなくて、テストの参考にこんなのありますよという情報提供のつもりでしたが。どこに書けば良いか分からなかったので、色々な形式との比較があったここに書きました。場違いと判断された場合はコメントごと削除して頂いて結構です。 -- 名無しさん 2004-10-26 (火) 20:34:08
  • 前から疑問に思っていたのですが、tekって語源は何かの略でしょうか？どこかに説明があったような気がしないでもないですが、僕には見つけられませんでした。 -- ZwergSpitz 2004-12-16 (木) 13:21:29
  • ご推察のとおりtekは何かの略ですが、それが何の略であるかは今のところ秘密になっています。 -- K 2004-12-16 (木) 16:39:05
  • そうなんですか、なんだか少しだけ気になります（笑） -- ZwergSpitz 2004-12-16 (木) 18:02:40
  • バリエーションのtek5の中にstk5ってのがあるんですけどtek5のことですよね？ -- 名無しさん 2005-03-13 (日) 16:48:45
  • tek5はstk5を含みますが、それ以外の高度な形式も含んでいます。 -- K 2005-03-13 (日) 17:06:30
  • それではLZMAより速いのはstk5to -- 名無しさん 2005-03-13 (日) 18:35:59
  • ↑ごめんなさい打ち間違えました。LZMAより速いのはstk5とtek5ということでいいのでしょうか？ -- 名無しさん 2005-03-13 (日) 18:38:08
  • tek系とLZMAを速い順に並べるとこうなります。 stk1 tek1 stk2 tek2 stk5 LZMA tek5 -- K 2005-06-29 (水) 02:43:04
  • このページは、OS-Wikiに置いておくにはちょっと大きすぎるので、近いうちに整理します。このページをトップページ的扱いにして、コンテンツをOSASK-Wikiに移動させます。原則として削除はしません。 -- K 2005-06-29 (水) 03:21:33
Page Top

こめんと欄 anchor.png

  • LZMA SDK が Ver4.62 以降でパブリックドメイン扱いになっているそうなので、tek5 圧縮ソフトは脱GPLができる？ -- 名無しさん 2012-01-27 (金) 23:56:51
添付ファイル:
トップ   凍結解除 差分 バックアップ 複製 名前変更 リロード印刷に適した表示   ページ新規作成 全ページ一覧 単語検索 最新ページの一覧   ヘルプ
Counter: 248, today: 1, yesterday: 1
初版日時: 2004-11-15 (月) 14:29:53
最終更新: 2012-03-31 (土) 00:00:00 (JST) (319d) by ゲスト
 ぺージ情報 閲覧可 編集可
ぺージ名 :tek グループ :すべての訪問者 グループ :すべての訪問者
ページ作成 :ゲスト ユーザー :すべての訪問者 ユーザー :すべての訪問者
ページ別名 :未設定
新着

［目次］
［メンバー一覧］

最新の20件
2016-10-01 2016-09-08
  • @MenuBar.
2016-09-07 2016-09-04 2016-08-15 2015-09-23 2014-07-30 2014-07-04 2014-02-04 2013-10-26 2013-06-21 2013-06-17 2013-06-15 2013-04-02 2013-02-09 2013-02-04 2012-12-25 2012-12-01 2012-05-28 2012-03-31
トピック一覧
一般用コメント最新
新掲示板lina
2016/9/5 20:58
SandBoxゲスト
2016/9/4 12:01
RecentDeletedlina
2015/6/2 19:29
Old-OSASK-MLlina
2014/6/29 9:14
hideyosi/メールhideyosi
2014/1/6 20:17
hideyosi/募集中lina
2013/11/8 19:56

このサイトは川合秀実から委託を受けて、OSASKコミュニティによって管理・運営されています。