ハードディスク容量を節約する奇妙な方法について

別のユーザーは、新しいデータをハード ドライブに書き込みたいと考えていますが、これを実行するのに十分な空き容量がありません。 また、「すべてが非常に重要で必要なもの」なので、何も削除したくありません。 そしてそれをどうすればいいのでしょうか？

この問題を抱えている人はいません。 私たちのハードドライブにはテラバイト単位の情報があり、この量は減少する傾向がありません。 しかし、それはどれほどユニークなのでしょうか？ 結局のところ、すべてのファイルは特定の長さのビットのセットにすぎず、おそらく、新しいファイルはすでに保存されているファイルとそれほど変わりません。

ハード ドライブに既に保存されている情報を検索することは、失敗ではないにしても、少なくとも効率的な作業ではないことは明らかです。 逆に、差が小さい場合は、少し調整することもできます...

TL;DR - JPEG ファイルを使用してデータを最適化する奇妙な方法について説明する XNUMX 回目の試みで、よりわかりやすい形式になりました。

ビットと違いについて

完全にランダムな 00 つのデータを取得した場合、平均して、それらに含まれるビットの半分が一致します。 実際、各ペア ('01、10、11、XNUMX') の可能なレイアウトのうち、ちょうど半分が同じ値を持ち、ここではすべてが単純です。

しかし、もちろん、XNUMX つのファイルを取り出して XNUMX つを XNUMX 番目のファイルに当てはめると、そのうちの XNUMX つが失われます。 変更を保存すれば、単に再発明するだけです デルタエンコーディング、通常は同じ目的で使用されませんが、私たちなしでも完全に正常に存在します。 小さなシーケンスを大きなシーケンスに埋め込むこともできますが、それでも無謀にあらゆるものに使用すると、データの重要なセグメントが失われる危険があります。

では、何と何の間で差をなくすことができるのでしょうか？ つまり、ユーザーが書き込んだ新しいファイルは単なるビットのシーケンスであり、それ自体では何も実行できません。 次に、差分を保存せずに変更できるビットをハードドライブ上で見つければ、重大な結果を招くことなく紛失しても生き残ることができます。 そして、FS 上のファイル自体を変更するだけでなく、その中にある機密性の低い情報も変更することは理にかなっています。 しかし、どれをどのようにして？

フィッティング方法

非可逆圧縮ファイルが役に立ちます。 これらすべての JPEG、MP3 などは非可逆圧縮ではありますが、安全に変更できるビットが大量に含まれています。 エンコードのさまざまな段階で、コンポーネントを気づかれないうちに変更する高度な技術を使用することが可能です。 待って。 高度なテクニック... 目に見えない変更... 少しずつ別のものに... それはほとんどのようです ステガノグラフィー!

実際、ある情報を別の情報に埋め込むという手法は、他に類を見ない彼女の手法を彷彿とさせます。 また、私は人間の感覚に加えられた変化が知覚できないことにも感銘を受けました。 パスがどこで分岐するかは秘密です。私たちの仕事は、ユーザーがハード ドライブに追加情報を入力することになりますが、それはユーザーに害を及ぼすだけです。 彼はまた忘れてしまうだろう。

したがって、使用することはできますが、いくつかの変更を加える必要があります。 次に、既存の方法の XNUMX つと一般的なファイル形式の例を使用して説明し、示します。

ジャッカルについて

本当に絞ると、世界で最も圧縮しやすいものになります。 もちろん、JPEG ファイルについて話しています。 データを埋め込むためのツールや既存の方法がたくさんあるだけでなく、これは地球上で最も人気のあるグラフィック形式です。

ただし、犬の繁殖に従事しないためには、この形式のファイルでの活動分野を制限する必要があります。 過剰な圧縮によって表示される白黒の四角形を好む人はいないため、すでに圧縮されたファイルを使用するように制限する必要があります。 再コーディングの回避。 より具体的には、データ損失の原因となる操作 (DCT と量子化) の後に残る整数係数を使用します。これは、エンコード スキームで完全に表示されます (バウマン国立図書館の wiki のおかげで)。

jpeg ファイルを最適化するには、さまざまな方法が考えられます。 ロスレス最適化（jpegtran）あり、最適化あり」損失は​​ありません」、実際には他のことに貢献しますが、私たちはそれらを気にしません。 結局のところ、ユーザーがディスクの空き容量を増やすためにある情報を別の情報に埋め込む準備ができている場合は、ずっと前に画像を最適化したか、品質の低下を恐れてこれをまったく実行したくないかのどちらかです。

F5

アルゴリズムのファミリー全体がこれらの条件に適合するため、よく理解しておくことができます。 この良いプレゼンテーションで。 その中で最も先進的なのがアルゴリズムです F5 アンドレアス・ウェストフェルドによる、人間の目はその変化に対して最も鈍感であるため、明るさ成分の係数を操作します。 さらに、マトリックスエンコーディングに基づいた埋め込み技術を使用しているため、同じ量の情報を埋め込む場合、使用するコンテナのサイズが大きいほど、より少ない変更を加えることができます。

変更自体は、要約すると、特定の条件下 (つまり、常にではありません) で係数の絶対値を 5 減らすことであり、FXNUMX キーを使用してハード ドライブ上のデータ ストレージを最適化できるようになります。 重要なのは、JPEG の値の統計的分布により、そのような変更後の係数がハフマン エンコード後に占有するビットが少なくなる可能性が高く、RLE を使用してエンコードするときに新しいゼロがゲインを与えるということです。

必要な変更は、要するに、機密性を担う部分 (パスワードの再配置) を削除してリソースと実行時間を節約し、一度に XNUMX つずつではなく多数のファイルを操作するためのメカニズムを追加することです。 読者は変更プロセスの詳細には興味がないと思われるので、実装の説明に移りましょう。

ハイテク

このアプローチがどのように機能するかを実証するために、このメソッドを純粋な C で実装し、実行速度とメモリの両方の点で多くの最適化を実行しました (DCT を使用する前であっても、圧縮なしでこれらの画像の重さがどれほどになるか想像することもできません)。 ライブラリを組み合わせてクロスプラットフォームを実現 libjpeg, PCRE и 小さなディレクトリ、私たちは彼らに感謝しています。 これらはすべて「make」によってまとめられるため、Windows ユーザーは評価用に自分用に Cygwin をインストールするか、Visual Studio とライブラリを自分で扱う必要があります。

この実装は、コンソール ユーティリティおよびライブラリの形式で利用できます。 興味のある方は、Github のリポジトリにある Readme で後者の使用方法の詳細を確認してください。このリンクへのリンクは投稿の最後に添付します。

どのように使用する？

気をつけて。 パッケージ化に使用されるイメージは、指定されたルート ディレクトリで正規表現を使用して検索することによって選択されます。 完了すると、ファイルはその境界内で自由に移動、名前変更、コピーしたり、ファイルやオペレーティング システムを変更したりすることができます。ただし、細心の注意を払って、直接の内容を決して変更しないでください。 XNUMX ビットでも値が失われると、情報を復元できなくなる可能性があります。

完了すると、ユーティリティは、使用されたイメージに関するデータなど、解凍に必要なすべての情報を含む特別なアーカイブ ファイルを残します。 それ自体の重さは約数キロバイトで、占有されるディスク領域に重大な影響を与えることはありません。

「-a」フラグ「./f5ar -a [検索フォルダー] [Perl 互換の正規表現]」を使用して、可能な容量を分析できます。 パッキングはコマンド「./f5ar -p [検索フォルダー] [Perl 互換の正規表現] [パックされたファイル] [アーカイブ名]」で行われ、アンパックは「./f5ar -u [アーカイブ ファイル] [復元されたファイル名]」で行われます。 ]' 。

仕事のデモンストレーション

この方法の有効性を示すために、このサービスから完全無料の犬の写真 225 枚のコレクションをアップロードしました。 Unsplash そして文書の中に、第45巻のXNUMXメートルの大きなPDFが見つかりました。 プログラミングの芸術 クヌタ。

シーケンスは非常に簡単です。

$ du -sh knuth.pdf dogs/
44M knuth.pdf
633M dogs/

$ ./f5ar -p dogs/ .*jpg knuth.pdf dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 17.0s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 39.4s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar knuth_unpacked.pdf
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.4s
Decompressing... done in 21.0s
Writing extracted data... ok

$ sha1sum knuth.pdf knuth_unpacked.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth_unpacked.pdf

$ du -sh dogs/
551M dogs/

ファン向けのスクリーンショット

解凍されたファイルは引き続き読み取ることができます。

ご覧のとおり、ハードドライブ上の元のデータ 633 + 36 == 669 メガバイトから、より快適な 551 に到達しました。このような根本的な違いは、係数の値の減少によって説明され、係数の値に影響を与えます。その後の可逆圧縮: XNUMX つずつ減らすと、最終ファイルから数バイトを簡単に切り取ることができます。 ただし、非常に小さいとはいえ、これはデータ損失であることに変わりはなく、我慢する必要があります。

幸いなことに、それらは目にはまったく見えません。 スポイラーの下では (habrastorage は大きなファイルを処理できないため)、読者は、元のコンポーネントから変更されたコンポーネントの値を減算することによって得られる、目とその強度の両方で違いを評価できます。 原作, 中に情報が入っている, 違い (色がくすむほど、ブロックの差は小さくなります)。

代わりに、結論の

これらすべての困難を考慮すると、ハードドライブを購入するか、すべてをクラウドにアップロードする方が、問題に対するはるかに簡単な解決策のように思えるかもしれません。 しかし、今は素晴らしい時代に生きているとはいえ、明日もオンラインにアクセスして追加データをすべてどこかにアップロードできるという保証はありません。 あるいは、店に行って、さらに XNUMX テラバイトのハード ドライブを購入します。 ただし、既存の家をいつでも使用できます。

-> GitHubの

出所： habr.com