前の2編は「何 GB 節約できたか、いくらの価値があるか」でした。この記事では請求書の話はせず、写真家が真に気にする1つの質問だけに答えます：JPEG を ImgZilla に渡したとき、何が変わったのか、その変更が Lightroom / Photoshop / Capture One でどのような代償を払うのか。データは前の2編と同じ32188枚のカメラ/スマホ直出し JPEG から採取し、そのうち200組以上のファイルについてバイト単位の比較も行いました。
一、最も鋭い質問への答え：ビット深度は削られたか
写真界では「圧縮」に対する最も一般的な警戒心は、「私の 12 bit、14 bit が 8 bit にまで圧縮されてしまうのではないか」 です。
この懸念は対象を間違えています。まず2つを分けて考える必要があります：
- 色のビット深度（bit depth）：各色チャンネルが何ビットで記録されるか。8 bit＝各チャンネル256段階、14 bit＝16384段階。ビット深度は、暗部や空をどれだけ押し込んでもノイズが出ないかを決定します。
- ファイル密度（ピクセルあたりビット数 / bpp）：ファイルサイズ ÷ ピクセル数。前の記事では bpp で区分けしました——これは「この画像が1ピクセルあたり何バイト使っているか」を測るもので、圧縮の対象であり、色のビット深度とは別物です。
ImgZilla は後者（密度）を圧縮し、前者（ビット深度）を動かしません。また、JPEG の場合、ビット深度という問題自体が成立しません：
サンプリング209組の元画像/圧縮画像について、JPEGのSOFマークを逐個読み取ったところ、圧縮前後の精度はすべて8 bitでした。
理由は簡単です——ベースラインJPEGは標準で各チャンネル8 bitと定義されているからです。カメラ直出しJPEGには12 bitの話はなく、ImgZillaも「下げる」ことができません。
では12/14 bitのデータはどこにあるのか？RAWファイルのみです。そして ImgZilla がサポートする形式は gif / png / jpg / jpeg / svg / heic / heif / webp / avif——RAW形式（CR2、CR3、NEF、ARW、RAF、DNGなど）は含まれていません（これらをドロップしても無視されます）。デジタルネガはそもそも処理フローに入らず、天然の安全地帯です。
この節の結論：JPEGには下げるビット深度がなく、8 bit入力・8 bit出力；RAWは触れられません。ビット深度はこの記事で心配すべきことではありません——本当に見るべきなのは以下の2節です。
二、では何が変わったのか：完全な有損再エンコード
ImgZilla がJPEGを処理する方法は、「元ファイル上で無損最適化を行う」ではなく、画像全体をデコードして再エンコードし直すことです。完全なプロセスは以下の通りです：
JPEGを読み込む
→ 8 bit RGBピクセルにデコード
→ 再びYCbCrに変換
→ 固定量子化表で再量子化（有効品質は約quality 70）
→ 最適なHuffman表を再計算
→ プログレッシブJPEGとして出力
この中で「再量子化」というステップが有損です。量子化表が粗くなると、周波数の高い詳細が失われ、ファイルサイズが小さくなります。サンプリングファイルの量子化表の強度（量子化ステップの合計、数字が大きい＝量子化が厳しい）で測ると：
| 量子化表強度（中央値） | |
|---|---|
| カメラ / スマホ直出し元画像 | 1858 |
| ImgZilla 圧縮後 | 6852 |
量子化強度は約3.7倍。これは実質的な二次量子化です——「無損再構成」ではなく、高周波情報を再び失うプロセスです。
2つは変わっていません：
- 解像度は1ピクセルも動きません。全部の32188枚の画像について
dimensions_changedフィールドを調べたところ、例外なくfalseでした。ImgZillaはリサイズもクロップもせず、節約されたサイズはすべて再エンコードによるものです。 - ビット深度は不変（前の節を参照）、8 bit入力・8 bit出力。
1つだけ変わり、画質には影響しないもの：出力はプログレッシブJPEG（元画像はほぼベースライン）。プログレッシブはウェブの読み込み体験を向上させますが、画質にコストはかかりません。Lightroom / Photoshop / Capture Oneは正常に読み込めます——古いソフトの中には認識しないものもあります。
三、後編集に最も影響する項目：クロマサンプリングが強制的に4:2:0に
写真家が知っておくべき最重要点です。
JPEGは「クロマサンプリング」で容量を節約しています——人間の目は明るさに敏感で色の解像度に敏感ではないため、色情報の解像度を明るさより下げることができます：
- 4:4:4：色と明るさが同じ解像度、色情報が最も完全。
- 4:2:2：色の水平方向が半分。多くのカメラ、一部スマホの直出しJPEGで使われています。
- 4:2:0：色の水平・垂直が両方半分、明るさの1/4解像度。ほとんど「容量最適化」されたJPEGで使われています。
209組のファイルについて、圧縮前後のクロマサンプリングを見ると：
| クロマサンプリング | 元画像 | ImgZilla 圧縮後 |
|---|---|---|
| 4:4:4 | 1 | 0 |
| 4:2:2 | 128（61%） | 0 |
| 4:2:0 | 80（38%） | 209（100%） |
圧縮後100%が4:2:0。そのうち61%の画像は4:2:2から落ちてきています——色の垂直解像度が半分になり、かつ元に戻せません。
これが後編集でどう現れるか
クロマ解像度が下がると、肉眼で未修正の画像を見たときは多くの場合気づきません。問題は編集をしたときに出ます：
- 色調補正 / 分離色調：彩度を上げたり、HSLをいじったり、色分級を行うとき、色ブロックの境界が見え始めます。特に肌の明暗の移行や空から地平線へのグラデーションのような広範な滑らかな領域で顕著です。
- 色で選択 / マスク / マット抽出：Lightroomの色範囲マスク、Photoshopの色範囲、緑幕抽出——これらはクロマのエッジの精度を食います。4:2:0以降、エッジが荒れたり、ギザギザが現れたりします。
- 高コントラストの彩色エッジ：赤黒い文字、ネオン、逆光の枝——4:2:0はこれらの場所に彩色の「溢れ」を残します。
重なり効果
有効品質は約quality 70 + 4:2:0です。これはあくまで「圧縮寄り」のワークポイントです。元画像がquality 92、4:2:2だったとしても、後編集で押し込める幅は、同じ画像をquality 70、4:2:0に圧縮した後の方が明らかに小さくなります。さらに「圧縮してから編集して、もう一度保存する」というプロセスを重ねると——2回の有損再エンコードが重なったことになります。
この項目が無視できる場合
元画像がすでに4:2:0だった場合（多くの中低価格スマホや旧機種の直出し、あるいはすでにウェブ最適化された画像）、ImgZillaの再エンコードはクロマについて追加的な損失を与えません——ただ画像を元と近いワークポイントに収束させるだけです。これがこのような画像の圧縮率が低い理由でもあります（第6節の解像度区分を見てください：iPhone直出しでは70.7%しか節約できず、より「肥大」な汎用12MPでは80%節約できます）。
四、メタデータ：EXIF / XMP / ICC 全て失われます
ImgZillaはデフォルトでメタデータを除去します。209組のファイルについて圧縮前後を比較すると：
| メタデータ | 元画像にあり | 圧縮後に残る |
|---|---|---|
| EXIF（撮影パラメータ） | 204 | 0 |
| XMP（評価 / キーワード / 著作権） | 134 | 0 |
| ICC（カラープロファイル） | 2 | 0 |
項目ごとに失われているものを明確にします：
- EXIF：絞り、シャッタースピード、ISO、焦点距離、レンズ型番、ボディ型番、撮影時間、GPS座標、著作権フィールド——全て消えます。画像アーカイブのカタログ化、撮影パラメータの振り返り、あるいは著作権情報をファイルに持たせたい写真家にとっては致命傷です。
- 向きマーク（EXIF Orientation）：これは単独で取り上げます。なぜなら表示に直接影響するからです。多くのカメラや旧スマホは「撮影時にピクセルを物理的に回転せず、向きマークだけ書く」方式です。マークが消えると、縦向きの写真が横向きで表示されることがあります——libjpegの再エンコードはピクセルを自動的に正すわけではありません。最近のフラッグシップスマホは物理回転＋マークの修正が済んでいることが多いので影響はありませんが、カメラを使ったり、古いデバイスを使っていたりする場合は、圧縮前に確認しておくのが安全です。
- XMP：Lightroom / Bridgeでつけた星評価、旗印、キーワード、タイトル、著作権表示——これらがファイルに書き込まれているXMPの場合（サイドカーファイルやカタログデータベースではなく）、圧縮後は消えます。
- ICCカラープロファイル：このサンプルにはほとんどICCが埋め込まれていません（多くはマークなしのsRGB）でしたので、今回の実測ではこの項目は基本的にトリガーされませんでした。しかし広色域（Display P3やAdobe RGB）で納品する場合、埋め込まれたICCが削除され、再生側はsRGBとして解釈することになり、色がくすんだりずれたりします。広色域ワークフローではこの点に特に注意が必要です。
設定に「メタデータを保持する」というオプションがありますが、メタデータが重要な場合、最も確実な方法は：メタデータを保持したい画像は、ここでそのまま圧縮しない——元画像を残すことです。
五、これらのコストはいつなら受け入れられるか
上記3節を合わせると、ImgZillaのJPEG処理は：8 bit不変、解像度不変、クロマを4:2:0に、品質を約70に、メタデータをクリアし、平均体積−76.8%を得るものです。
このトレードオフは以下のシナリオで有利です：
- クライアントへの閲覧用サムネイル、ウェブポートフォリオ、SNS投稿。これらの画像は元々プラットフォームによって再圧縮されるため、4:2:0 + quality 70は視聴側ではほとんど無感で、サイズは4分の3削減できます——アップロードが速く、読み込みが速く、画像ホストとCDNの請求が低くなります（前の2編で計算済み）。
- 選別で除外後、長期アーカイブに残すJPEG。記録として残し、もう一度編集しない画像。
- WeChat / メールでの画像送信、同僚への素材送信——転送時間はサイズに比例して短縮されます。
前提として：まず内蔵比較ウィンドウ（⌘D）で自分で検証することです。ImgZillaは圧縮前/圧縮後を左右に分割して表示し、実際のピクセルまで拡大して1点ずつ比較できます。画質に敏感な人は「違いがわからない」という言葉を鵜呑みにせず、自分で100%まで拡大して最も気になる部分——肌、空、髪の毛のエッジ——を見てください。
六、使ってはいけない場合
- Lightroom / Photoshop / Capture One で大幅な調整を行うJPEG——特にJPEGしかない、RAWがない画像。この画像は編集の許容範囲が貴重で、事前に使い果たさないでください。元画像を残し、編集が終わってからエクスポートするときに圧縮版を作ってください。
- EXIF / 著作権 / GPS / 星評価キーワードを保持するアーカイブが必要。
- Display P3 / Adobe RGB 広色域での納品——ICCが削除されます。
- RAWファイル——影響を受けません（ImgZillaはそもそも触りませんが）、RAWをこのツールで圧縮しようと期待しないでください。その仕事ではありません。
一言で言えば：ImgZillaは「成果物」の圧縮には適していますが、「さらに加工する中間素材」の圧縮には不向きです。
七、データ付録：この32188枚の直出しJPEG
前の2編と同じサンプル、16個のサブディレクトリ、フィルタリングなし、そのまま圧縮。
全体
| サイズ | 元画像に対する比率 | |
|---|---|---|
| カメラ / スマホ直出し元画像 | 99.9 GB | — |
| ImgZilla 圧縮後 | 23.1 GB | −76.8% |
平均1枚あたり2.96 MB → 0.69 MB。ファイルごとの圧縮比の算術平均は76.6%節約、中央値は77.3%、全体のバイト数から計算した76.8%とほぼ一致します。
解像度で区分け：デバイスごとに節約できるサイズが異なる
| 解像度 | 枚数 | 比率 | ファイルごとの平均節約 |
|---|---|---|---|
| 4000×3000（汎用12MP、主にAndroid/コンパクトカメラ） | 19867 | 61.7% | 80.1% |
| 4032×3024（iPhoneメインカメラ12MPデフォルトサイズ） | 3529 | 11.0% | 70.7% |
| 3456×4608（16MP縦長） | 2631 | 8.2% | 76.9% |
| 4608×3456（15.9MP） | 903 | 2.8% | 54.8% |
| 1600×1200 | 257 | 0.8% | 51.4% |
（機種は解像度から推測したもので、EXIFを読み取ったものではありません——EXIFは圧縮データではもう利用できません。）
同じツール、同じ誰も触っていない元画像で、最も圧縮しやすい区分（80%）と最も圧縮しにくい区分（55%）では25ポイントの差があります。違いはすべて元画像そのものにあります。AppleのカメラJPEGパイプラインの量子化がより積極的で、エンコーディングがよりコンパクトで、出荷時点ですでに妥当な下限に近いです。大量の安価/古いデバイスの直出しは、保守的な固定量子化表を使用しており、まだ圧縮されていない「肥った」部分があります。より新しい大センサーのフラッグシップは、直出しがより「痩せて」おり、二次圧縮の余地が小さい——これは悪いことではなく、元画像自体がもったいないということです。
ファイルごとの分布
| 節約率 | 枚数 | 比率 |
|---|---|---|
| 90%–100% | 866 | 2.7% |
| 80%–90% | 11375 | 35.3% |
| 70%–80% | 15244 | 47.4% |
| 60%–70% | 3349 | 10.4% |
| 50%–60% | 398 | 1.2% |
| 50%未満 | 956 | 3.0% |
82.7%の写真で70%–90%節約されています。四分位数で見ると、半数以上が77%以上節約、最も利益が少ない10%でも約68%節約、p99（99パーセンタイル）では約1%の画像が40%未満の節約率です。
极端なケース
| 元画像 | 圧縮後 | 節約 | |
|---|---|---|---|
| 圧縮比が最高 | 3.55 MB（4000×3000） | 100 KB | 97.2% |
| 1枚あたり最大節約 | 17.9 MB（4000×3000） | 1.13 MB | 16.8 MB |
| 節約が最も少ない | 70 KB（1242×1242） | 68.8 KB | 2.1% |
八、データとテストの説明
- サンプル範囲：全体の圧縮率、解像度区分、ファイルごとの分布といった数字は、この32188枚のカメラ/スマホ直出しJPEGの実測に基づいています。これはこのサンプル群の結果を反映しており、「ImgZillaは平均76.8%圧縮できる」ということではありません。カメラ、機種、エクスポート設定によって結果は異なります。
- サンプルの選び方：ファイル全体はフィルタリングやクリーンアップを行わず、元の16個のサブディレクトリごとに圧縮しました。
- 機種の帰属：解像度区分のデバイス判定は解像度から推測したもので、EXIFを読み取ったものではありません（EXIFは圧縮後のデータではもう利用できません）；同じ解像度は複数のデバイスから来る可能性があります。
- バイト単位の比較はサンプリング：クロマサンプリング、ビット深度、量子化表、メタデータの結論は、ランダムに抽出された209組の元画像/圧縮画像についてJPEGマークをバイト単位で解析したものです。これはサンプリングに基づくもので、全量の32188枚に当てはまるわけではありません。
- 統計の定義：全体の76.8%は「総節約バイト ÷ 総元バイト」です。ファイルごとの圧縮比の算術平均は76.6%、中央値は77.3%を本文で記載済みです。サイズ単位は1 GB = 10⁹バイトとして換算しています。
- 圧縮パラメータ：パラメータは固定されており、UIに品質/サンプリングのスライダーはありません。これは設計上の選択です——パラメータは視覚的に無損と思われる範囲のバランス点に調整されています。自分で品質/サンプリングを手動で調整する習慣のある写真家は、この点に注意が必要です。
- 「視覚的に無損」は「無損」ではない：本当の無損（ピクセルが完全に変わらない）はPNGとSVGだけです。JPEGは有損再エンコードであり、パラメータは肉眼でほぼ区別できない範囲に選択されています。内蔵比較ウィンドウでピクセル単位で確認できます。
- 実行環境：すべてローカルで完結し、画像はネットワークに接続せずアップロードされません（App Storeの購入検証を除く）。
自分で検証してみませんか？ ImgZillaの無料版は1日10枚まで圧縮でき、成功した場合にのみクォータが消費されます。一番気にする画像を数枚——ポートレート、空、逆光の髪の毛——持ってきて、圧縮後に比較ウィンドウで100%まで拡大して自分で確認し、画像ライブラリ全体を任せるかどうかを決めてください。
Mac App Store： https://apps.apple.com/app/apple-store/id6749323539?pt=127227004&ct=v2&mt=8
詳細： https://imagetool.app/ImgZilla
システム要件：macOS 12.3以降。