#5です。 > ポイントとしては、画像ファイルについて「圧縮」といったばあい、結局、何の操作もせずに、ソフト側で勝手に圧縮されていることを言っているのか、という点です。zipなど、手動で意識的に行う作業としての圧縮でもなく、またフルサイズの画像を、web用などに縮小変換することを言っているのでもなく、あくまで自動的に最小化される処理としての圧縮のことを言っているのか、という点です。 失礼しました。質問の真意を読み落としていたようです。上のポイントに関して言うと、アプリケーション内での圧縮やWebへのポストのときは、特に圧縮方法に関して説明がなければアプリやWebの表示に最適化したように非可逆に圧縮を勝手にやることが多いと思います。実際には元の画像が圧縮されていることがほとんどなのでそれに対して再圧縮かけても効果は低く表示に最適なように画素数を間引くことでサイズを小さくすると思います。2Kのディスプレイに全画面表示しても2Mピクセル程度なので、それに10Mピクセルのカメラでとった画像を表示するのは無駄。それに対して、画像編集ソフトなどで加工した場合は保存時に各圧縮フォーマットを選択でき、ユーザーが元データを保持したいか圧縮率を上げてファイルサイズを小さくしたいか選べるようになっているのが通常と思います。 >本質的に、それを数式化して保存するなどということは、基本、不可能ではないでしょうか。どれだけ隣同士の色が近くても、１ドットごと、24bit フルカラー（1677万色）であれば、各ドットの色はかなり違っているはずで、連続性や法則性を見つけることは基本不可能と思われます。となると、ある程度の大雑把さは許容範囲とし、どこまでを可逆圧縮とよび、どこからを不可逆圧縮とよぶのかで、何らかの人為的な線引きをしているのだろうと思うのですが、どうなのでしょう。 非可逆圧縮はデータ列に特定のパターンの繰り返しや出現頻度のばらつきに着目して出現頻度が低いパターンには多くのビットを割り振ったり、特定のデータの繰り返しはその繰り返しパターンをデータ化したり、隣り合うドットの値の差分をデータ化したりして圧縮します。だから特定のパターンが無い、隣接するドットの差分をとっても意味がないような画像の場合（例えば、極端な例ですが白(R:G:B 100%)のドットと黒(R:G:B 0%)のドットがチェッカー板の目の様にまだら模様になっているような画像を非可逆圧縮しようとすると圧縮どころかデータが膨れ上がります。 青空の場合それぞれのピクセルが全く同じ色でなかったとしても、RGBに分解してそれぞれの値の隣接の差分がそんなに大きく触れるわけではなく、RGBそれぞれの隣接ピクセルの差分で表せばフルのビット数を使わなくてすみます。自然界の画像は概ね隣接の空間内がそれほど大きな変化が無いパターンで構成されているので非可逆圧縮してもそれなりに大きなファイルサイズの圧縮が可能です。なんで自然がそうなっているかと言われればもはや神様に聞いてくれとしか言いようが無いです。それから、前の回答にも書いたようにもともとカメラで写した自然界の画像そのものが撮像素子の数やそれぞれのビット数に制限されているので（しかもたいていJPEG圧縮された状態で保存される）、元データが無限ではなく、すでにフィルターが多少かかった状態です。 ちなみにJPEGなどの非可逆圧縮は全く別の方式を使っています。ピクセルの色差（RGBではなく、より人間の目の間隔にわせた色の変化を表すデータ）の変化をコサイン数列で表して高い周波数成分（隣接のピクセル間のデータの変化が激しく変化するようなパターン）を切り落とす、離散コサイン変換と言う手法をメインで使っていますが、簡単に言うとあんまり細かい色差の変化は人間の目には感じられないしノイズの可能性もあるので無視することによって圧縮します。更にそのデータをPNGのようなピクセルデータの出現頻度や繰り返しパターンなどによって圧縮します。そう言う画像データがカメラから出力されてくるので、それをいったんビットマップに展開しても細かい変化のパターンはすでにフィルターされて落とされているので、上で極端な例で非可逆圧縮したら容量が増えてしまうようなパターンのデータはそもそも通常の使用では排除されていると言って良いと思います。ただ、圧縮技術は上だけでなく考えられる限りの手法が取られているので、圧縮されたデータを別の方法で再圧縮してもデータ容量を減らすことは期待できず、一般ユーザーが使う段では画素数を落としたり、細かいデータの変化をよりたくさん無視することによってデータ容量を減らすと言うのが主な作業になると思います。