ノート:データ圧縮
そのデータの性質を保ったまま
[編集]「そのデータの性質を保ったまま」について云えば、「許せる範囲でデータを損なっても良い」という、ある意味相反する内容も含まれます。
可逆圧縮と非可逆圧縮で、詳細には解説されているわけですが、このページでも簡単に表現しておいた方が良い気がしました。私もまだ考えてませんが。-Adacom —以上のコメントは、202.213.4.16(会話/投稿記録/Whois)さんが[2003-07-07 04:36:36 (UTC)]に投稿したものです。
各種圧縮方式
[編集]各種圧縮方式については、コーデックにも似た内容があったのでそちらに移しました(Taka)。—以上のコメントは、203.138.86.170(会話/投稿記録/Whois)さんが[2005-01-05 02:54:52 (UTC)]に投稿したものです。
- 情報 上記投稿で報告されているのは、記事「コーデック」の2005年1月5日 02:38:54 (UTC)の版での編集(差分/1251656)です。当記事「データ圧縮」側では同日 02:53:56 (UTC)の版で節「主な圧縮フォーマット」にあった一覧リストの除去編集(差分/1267778)が実施されました。--Yumoriy(会話) 2024年8月26日 (月) 10:23 (UTC)
- 加筆お疲れ様です。ただ、どちらかというと、各種圧縮方式・技術についてはコーデックよりもデータ圧縮、または符号方式で説明したほうが良いように思います(さらに個別のものはMPEGなど個別項目内でしょうけれど)。コーデックは定義にあるとおりエンコーダとデコーダの両機能を持った装置あるいはソフトウェアというだけですから、そちらでは技術よりもむしろ各種圧縮技術に対応したコーデック製品の列挙と説明をするとバランスがよいように考えますが如何でしょうか? --sphl 2005年1月5日 (水) 16:14 (UTC)
- そうですね。こちらに技術的な説明の比重を多くして、コーデックの方には具体的な方式やソフト名の列挙と平易な説明を行うという方向でどうでしょうか?。データ圧縮の方がやや専門的な言葉、コーデックの方が広く認知されている言葉のように思います。ただ、データ圧縮、コーデック双方のページに同じような単語のリンクがたくさん並ぶのもさえないので、こちらからコーデックのページ内にリンクを張るというのでどうでしょうか? (Taka) 2005年1月21日—以上のコメントは、203.138.86.147(会話/投稿記録/Whois)さんが[2005-01-21T09:33:14 (UTC)]に投稿したものです。
- 良いと思います。コーデック→データ圧縮→符号化方式の順で技術的に詳しくなるイメージですね。もっとも最後のはかなり不消化で放置状態ですが。--sphl 2005年1月21日 (金) 12:46 (UTC)
- そうですね。こちらに技術的な説明の比重を多くして、コーデックの方には具体的な方式やソフト名の列挙と平易な説明を行うという方向でどうでしょうか?。データ圧縮の方がやや専門的な言葉、コーデックの方が広く認知されている言葉のように思います。ただ、データ圧縮、コーデック双方のページに同じような単語のリンクがたくさん並ぶのもさえないので、こちらからコーデックのページ内にリンクを張るというのでどうでしょうか? (Taka) 2005年1月21日—以上のコメントは、203.138.86.147(会話/投稿記録/Whois)さんが[2005-01-21T09:33:14 (UTC)]に投稿したものです。
上の話に関連して、コーデックとデータ圧縮をそれぞれ加筆修正しています。この項目内の、ファイル圧縮、静止画像圧縮、音声圧縮、動画圧縮の項目がどれもスカスカの状態になっております。大幅加筆の協力を求めます。ここでは、上の話のとおり、個別の方式の列挙や説明ではなくて、生い立ちや共通する要素技術の説明を期待しています。例えば、ファイルですと lz法やアーカイブをどのように組み合わせているとか、動画ですと動き補償やマクロブロックといったキーワードや、扱い上の利点・欠点(MPEGはコマ単位の編集には厳しいとか)などの概略を説明されることを期待しています。ページが大きくなるようでしたら、後からファイル圧縮、画像圧縮などの項目に分割できますので、文量は気にせず、どんどん加筆してください。 (Taka) 2005年1月21日—以上のコメントは、203.138.86.147(会話/投稿記録/Whois)さんが[2005-01-21 12:26:27 (UTC)]に投稿したものです。
- 同様にMPEG関係も小項目で分散しているのと、肝心の符号化の仕組みに殆ど触れていないため加筆が望まれるところなのですが、専門的に書くのは結構しんどいので専門家の登場に期待しているところです。あと、符号化方式#情報源符号化の諸方式に少し書いてあることも使えるならこっちに持ってきてよいかもしれません。--sphl 2005年1月21日 (金) 12:46 (UTC)
NTSC,PALで、YC分離も帯域圧縮?
[編集]あと、NTSC,PALで、YC分離も帯域圧縮と考えてよいのですか?。アナログ帯域圧縮の項目もスカスカの状態ですので、ご存知の方、加筆のご協力をお願いします。(Taka) 2005年1月21日—以上のコメントは、203.138.86.147(会話/投稿記録/Whois)さんが[2005-01-21 12:26:27 (UTC)]に投稿したものです。
- コンポジット映像信号そのものがアナログ帯域圧縮です。デジタルビデオ信号でもD2(コンポジット)はD1(4:2:2コンポーネント)の約半分の帯域です。効果としてはRGB→YCbCr(YIQ)にしてクロマの帯域制限をしたことと、輝度とクロマを多重化したことの両方です。--sphl 2005年1月21日 (金) 12:46 (UTC)
- RangeCoderについてですが、RangeCoderは確かに算術圧縮に似ていますが、算術圧縮とは別物です。算術圧縮の場合、課程上必ず浮動小数点計算が必要になります。それに対して、RangeCoderは整数計算のみでできるようになっています。さらに、算術圧縮では付きものの特許に関する規制が一切ありません。このことから、RangeCoderと算術圧縮を一緒にしてしまうと特に特許に関することに対することで誤解を招いてしまうのでないでしょうか? もし、このままで良いと言うなら手は出しません。--Lyiase 2005年11月19日 (土) 12:41 (UTC)
音声や画像の符号化に関して
[編集]音声や画像、ビデオなどの符号化方式は、符号化方式の名が示す通り、原理的にはPCMを介在させることなく符号化することが可能であるので、データ圧縮方式というのは厳密な意味では誤りです。しかし、同じ品質を再現するPCMのデータと比較すると能率が良いので、その面ではデータ圧縮方式であるという考えは誤りではありません。--以上の署名のないコメントは、Mickey-ikeda(会話・投稿記録)さんが 2006-05-02 08:41:33 (UTC) に投稿したものです。
コーデックとの統合 再提案
[編集]記事とノート、拝見しました。コーデックとまだ重複部分が多いように思います。 「データ圧縮・伸張を行う装置やソフトウェア」についての説明は基本的に「データ圧縮」に統合したいと思います。いかがでしょうか。--j8takagi 2006年9月15日 (金) 02:06 (UTC)
- ファイル圧縮の節をコーデックから移動しました。(参考:ノート:コーデック)
--220.212.78.218 2006年10月4日 (水) 13:40 (UTC)
compress、gzip
[編集]compress、gzip
フリーの UNIX ライク OS しか使ったことがない人は、compress はかつて使われていたもので、現在は gzip にその座を奪われたと思っていることがあります。しかし、商用 UNIX では compress が標準で、gzip はインストールされていないか、されていてもオプションの扱いになっているのが普通です。フリーの UNIX では確かに gzip や bzip2 が一般的ですが、商用 UNIX では compress を使うのが一般的です。--しまでん 2006年10月6日 (金) 14:10 (UTC)
外部リンク修正
[編集]編集者の皆さんこんにちは、
「データ圧縮」上の2個の外部リンクを修正しました。今回の編集の確認にご協力お願いします。もし何か疑問点がある場合、もしくはリンクや記事をボットの処理対象から外す必要がある場合は、こちらのFAQをご覧ください。以下の通り編集しました。
- http://mia.ece.uic.edu/~papers/WWW/MultimediaStandards/chapter7.pdf の書式設定/使用方法を修正
- http://www.testvid.com/index.html にアーカイブ(https://web.archive.org/web/20111201183842/http://www.testvid.com/index.html )を追加
- http://public.dhe.ibm.com/common/ssi/ecm/en/tsu12345usen/TSU12345USEN.PDF に
{{リンク切れ}}
のタグを追加
編集の確認が終わりましたら、下記のテンプレートの指示にしたがってURLの問題を修正してください。
ありがとうございました。—InternetArchiveBot (バグを報告する) 2017年9月15日 (金) 08:21 (UTC)