🧰 UtlKit

画像圧縮の使い方: ローカルファイルを品質 10 から 95 の JPEG に再エンコード, ブラウザ内で

ローカル画像ファイル 1 つを画面上で品質 10 から 95 の JPEG に再エンコードし, サイズの差は Base64 長の推定から読み取る, 全てブラウザ内で計算.

画像圧縮はローカル画像ファイル 1 つを読み, 画面上で JPEG に再エンコードし, ダウンロードの前にサイズ変化を表示します. ファイル選択器でファイルを選ぶと, ページは元の寸法で canvas に描画し, スライダーの品質, デフォルトは 70%, で再エンコードします. 読み取りは元のサイズ, 推定された圧縮後のサイズ, 割合を印字し, 例として 2,400,000B → 833,351B (-65%), 並列プレビューは元画像と結果を並べます. 全てブラウザ内の canvas 呼び出しで, ファイルのバイトは装置の外に出ず, アップロードは一切起きません.

受け取るものと出すもの

受け取りは画像ファイルだけを受け付ける 1 つのファイル欄で, それ以外は何も求めません. 元のサイズはディスク上の正確なバイト数なので, 読み取りの左半分は正確です. 出力は常に JPEG です. canvas がピクセルをブラウザの JPEG エンコーダに渡し, 出力形式は固定で選べず, 幅と高さは元のままです. 唯一の操作は品質スライダーで, 10 から 95 まで 5 刻み, 計 18 段階, 動かすと保持された元画像で即座に再エンコードし, 読み取りとプレビューはライブで更新されます. 納得できたら, ダウンロードボタンは結果を compressed.jpg としてディスクに書き, 実際に保存するファイルがバイト数の正解です.

なぜ出力は常に JPEG なのか

再エンコードは出力タイプが JPEG に固定された 1 回の canvas 呼び出しなので, PNG が入ると JPEG が出て, WebP が入っても JPEG が出て, GIF が入ると 1 枚目のフレームだけが残り, 画像要素がアニメーションファイルの最初のフレームしかデコードしないためです. 固定形式の帰結は 2 つあります. 第一, JPEG には alpha チャネルがないので, 透明な PNG は透明のまま残りません. 透明ピクセルはエンコード前に黒の上に合成され, ダウンロードしたファイルは元が透明だった場所に黒を持っています. 第二, ツールはブラウザ自身のデコーダを使い, 代替がないので, ブラウザがデコードできない形式, 多くのプラットフォームの HEIC など, は単純にデコードが終わりません. 何も表示されません.

サイズはどう読み取られるか

圧縮後のサイズは推定値で, 意図的にシンプルなものです. canvas は data URL を返し, 23 文字の data:image/jpeg;base64, プレフィックスの後に base64 が続き, ページは文字列全体の長さに四分之三を掛けます. base64 は 3 バイトに 4 文字を使うからです. この推定はプレフィックス分だけ実バイト数より 17 から 19 バイト大きくなり, 1,000,000 バイトの JPEG は 1,000,019B と, 999,999 バイトのは 1,000,016B と読まれます. 一通り通すと, 2,400,000B のファイルでエンコーダ出力が 833,333 バイトなら, 2,400,000B → 833,351B (-65%) と印字されます. 割合は丸めるので, 表示値と正確な計算は 1 ポイント違い得ます.

ファイルが大きくなったとき

削減率は (1 から圧縮後サイズを元のサイズで割ったもの) を 100 倍して丸めた値で, 負の時は + で表示され, 大きくなったファイルは例として 45,000B → 47,018B (+4%) と報じられます. これは小さい画像で, エンコーダの固定オーバーヘッドが支配的な場合に起き, 元が JPEG で既に選択した品質以下に圧縮済みでも起き, スライダーが元の保存品質より上でも起きます. 方向は不具合ではありません. 10 は出力が最も小さい段階で, 95 は最も大きいので, 品質を上げると読み取りが上がるなら, 元はエンコーダが想定するより既に薄いということです.

ピクセルはどこへ行くか

ファイルは FileReader でページ上の data URL に読み, 計算は canvas の描画と JPEG エンコードのみなので, バイトは装置の外に出ず, ネットワーク要求は一切ありません. 永続化もありません. ページが data URL を持つのは開いている間だけで, 履歴もキャッシュもなく, タブを閉じるなりリロードするなりすると画像も結果も捨てられます. 装置の外に出うる唯一の成果物は, 自分で選んでダウンロードした compressed.jpg です.

何ではないか

ツールは元の寸法をそのまま保つのでリサイザではありません. ピクセルサイズの変更は 画像リサイズ の仕事です. 出力が JPEG に固定なので形式コンバータでもなく, 出力形式の選択は 画像フォーマット変換 の仕事です. メタデータも読み表示せず, それは 画像情報ビューア が示すもので, フレームのトリミングもしません. 切り取りは トリミングガイド を見てください.

関連ツール

よくある質問

画像圧縮は私の画像をサーバーにアップロードしますか?

いいえ. ファイルは FileReader でページ上の data URL に読み, 計算は canvas の描画と JPEG エンコードのみなので, バイトは装置の外に出ず, ネットワーク要求は一切ありません. 外に出うるのは, 自分で選んでダウンロードした compressed.jpg だけです.

なぜ私の PNG の透明が失われて, 背景が黒になるのですか?

出力は常に JPEG で, JPEG には alpha チャネルがありません. エンコード前に, 透明ピクセルは canvas 上で黒の上に合成されるので, ダウンロードしたファイルは元が透明だった場所に黒を持ちます. 透明を保つ設定はありません. 出力形式が固定だからです.

なぜサイズ読み取りとダウンロードしたファイルが数バイト違うのですか?

読み取りは推定です. data URL の長さに四分之三を掛けた値を丸めたもので, 23 文字の base64 プレフィックスと base64 本体でできています. プレフィックスだけで数値は実カウントより 17 から 19 バイト上になります. ダウンロードしたファイルは canvas から直接エンコードされるので正解です. 読み取りは同じ形の見せで, バイト正確な約束ではないと扱ってください.

なぜ圧縮後のファイルが元より大きくなるのですか?

削減率は負になり得, 負の時は + で表示されます. 例として 45,000B → 47,018B (+4%). これは小さい画像でエンコーダの固定オーバーヘッドが支配的な場合に起き, 元が JPEG で既に選択した品質以下に圧縮済みでも起き, スライダーが元の保存品質より上でも起きます. 10 は出力が最も小さい段階で, 95 は最も大きいので, 品質を上げると読み取りが上がることがあります.

どの品質を選べばいいですか?

スライダーは 10 から 95 まで 5 刻みの 18 段階で, デフォルトは 70 です. 動かすと保持された元画像で即座に再エンコードされ, 読み取りとプレビューがライブで更新されます. その画像の用途で見た目がまだ許せる最低の品質を選び, その段階のサイズ読み取りを確認してください.

関連記事