shi3zさんの通信上の圧縮アルゴリズム利用の認識と、big_brosさんによる指摘及び圧縮アルゴリズムの解説
- takagiichiro
- 217481
- 98
- 791
- 608
むしろ不要な要素を切り捨てて非可逆で圧縮するのがやりやすいのでDCTを選ぶ、という理由ならば非可逆圧縮として使うことになるので、そこについてはあながち間違いともいえないのだけども。
2015-07-15 18:32:07ここで重要なのは、圧縮アルゴリズムを選定する上で「それが可逆/非可逆の時にどうなるか」なのだよね。具体的なアルゴリズムがどうであれ、可逆の場合、非可逆の場合それぞれで同じ問題を引き起こしうるわけで。
2015-07-15 18:33:52可逆、非可逆の線引きは明確で「元のデータ列と寸分たがわぬデータ列が再現できるか否か」。hash関数の種類もいろいろあるけども、その特性は同じで、理解しておかなければならないのは「あるデータ列から求められたhash値と同じ値は、他のデータ列では滅多に出ない」という点。
2015-07-15 18:37:57つまり「非可逆圧縮で改変されたデータ」からは、「改変前のデータから計算されたhash値」と同じ値はまず得られない、というところね。
2015-07-15 18:39:39通信の両端でデータ列に変化がなければ、同じhash関数を通した結果の値は同じになるので、「同じデータと思って良い」という結論が導ける。しかし、途中意図しない非可逆圧縮がかかったデータについてはhash値がまず一致することはないので「明らかに異なるデータである」となるんだな。
2015-07-15 18:42:35@big_bros 各キャリアは無線の資源を有効活用するのが目的です多分。データ圧縮によって節約できた分は他のユーザーに回せます。圧縮で逆にサイズが大きくなった場合、増収に繋がります。なんてゲスい。
2015-07-15 18:44:22@AZANYANG もちろんそれはわかるのですが、その手段が非可逆なデータ改竄となるとアプリケーション側は「何を正しいデータとすれば良いのか」の基準を失うことになります。やるならせめて可逆にしろという話ですね。
2015-07-15 18:46:06ちなみに @shi3z 氏の言うように私が「同人の人」だったら、これも同人ゲームですかねw youtube.com/watch?v=LwaYwO… これの11:32あたりにいます。
2015-07-15 18:50:54名前の出たLZ法だけども、アルゴリズムがシンプルでなおかつ展開に要する資源も非常に少なく高速であるため8bit時代から使われてた。反復の多いデータ列の圧縮率が非常に高くて実装も簡単なので、ゲーム作る人はぜひ勉強してみてほしいと思ったり。
2015-07-15 19:19:11@askn37 yes. しかも可逆圧縮ときている。同じ色のpixelが続くアニメ絵であるとか8bit時代のマップデータのような反復の多いデータ列には最適というね。
2015-07-15 19:35:19.@big_bros あー、あのAIがAIと呼べないレベルのゲームの関係者の方ですか。僕もMGSは好きだったんですけど、上月さんはそうでもなかったようですね
2015-07-15 19:45:31. @shi3z ここでは「データのリビジョン」の話をしています。ハードウェアのリビジョンはネットワーク経路上の意図しない非可逆圧縮とは無関係な話です。そんなこともわからずWeb屋さんのCEOとやらやってらっしゃる?
2015-07-15 19:48:24. @shi3z 2001年のゲームですからもちろん2001年の水準ですけどもね。ちなみに同年度の社内タイトルでは最高の賞を会社からいただきましたよ。それで? 非可逆圧縮によってデータ列が改変されることによってhash値による同一性チェックが出来なくなってしまう問題については?
2015-07-15 19:52:01. @shi3z あ、当時AIを手掛けたのは私ではないので、瑕疵のない他人を勢いにまかせて侮辱したことをちゃんと謝罪しておいていただきたいですね。後ででよいので。
2015-07-15 20:15:22まあ、@shi3z 氏がこの程度の考えの下にデータ最適化と称する改竄行為を容認する意見を主張していた、ということを充分参考になる程度に白日の下に晒し、それと並行して何が問題なのかを解説する機会が得られた時点で、俺の目的は達成されているのだけどもね。
2015-07-15 20:22:14