PNG 指定の利用先には PNG を維持し、明るい背景と暗い背景の両方で出力を確認します。PicZip はブラウザーでアルファチャンネルを再エンコードします。透過が維持されても、新しい PNG が小さくなる保証はありません。
操作手順
- 利用先が PNG を必要とする場合は、出力を PNG にします。
- 最初は目標容量と最大幅を 0 にし、元画像と出力の正確なバイト数を比較します。
- 明暗の背景で透明・半透明の輪郭を確認し、対応する利用先では WebP も比較します。
透過の維持とは何か
アルファは不透明度を表し、0 は完全透明、255 は完全不透明、その間の値は柔らかな輪郭、影、フェードを作ります。滑らかな曲線を持つロゴでは、完全透明の画素だけ残しても十分ではありません。
800 × 600 の RGBA 元画像には、完全透明 251,243、半透明 115,172、不透明 113,585 画素がありました。出力 PNG をデコードすると 3 区分の数が一致しました。これはこのテストのアルファ区分を確認したもので、すべての圧縮ツールや変換を保証するものではありません。
| ファイル | 寸法 | 容量 |
|---|---|---|
| 元の PNG | 800 × 600 | 1,617,783 バイト |
| PNG 出力 | 800 × 600 | 1,720,597 バイト |
| WebP・品質 82 | 800 × 600 | 96,120 バイト |
最初に PNG から PNG を試す
元画像を選び、PNG、最大幅 0、目標容量 0 にします。厳しい容量探索やリサイズを加えず、エンコーダーの結果を分けて確認できます。キャンバスとアルファ区分の数は保たれましたが、102,814 バイト増えて 1,720,597 になりました。
増えたら元を残します。元の方がフィルター、パレット、圧縮方式を効率よく使っている可能性があります。再エンコードは自動的な最適化ではありません。
空白だけでなく輪郭を見る
ダウンロードを白、黒、鮮やかな色の上に置き、100% で曲線、髪、影、光彩、滑らかな文字を確認します。白い縁は、事前に背景が合成されたり変換でアルファ情報が失われたりした可能性を示します。
MIME タイプと拡張子も確認します。JPG はアルファを持たず、透明部分を単色背景に置き換えるため、容量が小さくても透過 PNG の代わりにはなりません。
対応していれば WebP を比較
同じ画像を品質 82 にすると、800 × 600、96,120 バイトの WebP になりました。デコード後の透明、半透明、不透明の画素数は一致しました。
ただし、この設定の色チャンネルは非可逆圧縮です。アルファの区分が同じでも RGB が完全一致するわけではありません。Web サイト、アプリ、フォームが対応するときだけ使い、PNG 指定、正確な色、WebP 非対応のソフトには PNG を残します。
PNG で品質を下げても効かない理由
PicZip の PNG エンコーダーは固定の 8 ビット PNG エンコードを使い、品質スライダーの値を受け取りません。品質設定が作用するのは JPG と WebP で、この PNG を段階的に小さくすることはできません。
PNG で上限に届かない場合は、許される範囲でリサイズや形式変更を検討します。対照的な背景で透過を確認し、容量が増えたら原本を残します。WebP に置き換える場合は、透過と色の細部の両方を見直してください。
よくある質問
PNG を圧縮すると透明でなくなりますか？
今回の PNG 処理では、透明・半透明・不透明の画素数は元と一致しました。
透過 PNG の容量が増えたのはなぜ？
元がすでに効率よく符号化されている可能性があります。寸法と画素を保つ可逆表現でも、別のエンコードでは容量が増えます。
WebP も背景を透明にできますか？
はい。検証ではアルファの区分を維持しました。ただし品質 82 の色には損失があり、利用先の対応も必要です。
透過ロゴに JPG を使うべきですか？
単色背景にしたい場合に限ります。JPG にはアルファチャンネルがありません。