Sat Jun 27 2026 20:00:00 GMT-0400 (北美东部夏令时间)
Bagaimana Algoritma Mampatan Imej Berfungsi: DCT, LZW & AVIF
Bagaimana mampatan imej berfungsi: DCT menukar blok piksel 8x8 kepada frekuensi, Huffman dan LZW mengemas pekali, manakala AVIF mengatasi JPEG dengan contoh terukur.
Dikemaskini kali terakhir: June 28, 2026
Pemampatan imej mengecilkan fail dengan membuang maklumat yang sukar dilihat oleh mata anda. Algoritma di sebalik JPEG, PNG, GIF, WebP, dan AVIF bukanlah sihir — ia adalah susunan langkah mekanikal yang spesifik. Memahami algoritma ini memberitahu anda mengapa JPEG pada kualiti 80 kelihatan baik, mengapa PNG membengkak pada foto, dan mengapa AVIF menyulitkan dengan sangat perlahan. Ini adalah panduan praktikal mengenai matematik sebenar, bukan pertandingan populariti format.
Jawapan ringkas: bagaimana algoritma mampatan imej berfungsi?
Setiap format melakukan tiga tugas yang sama secara berurutan. Pertama, ia mentransformasikan piksel supaya maklumat penting tertumpu dalam beberapa nombor. Kedua, ia mengkuantisasi — membulatkan nombor yang menyumbang paling sedikit (ini adalah bahagian lossy, dan format tanpa kehilangan melangkauinya). Ketiga, ia mengkodkan entropi nilai yang tinggal supaya nilai yang kerap mengambil bit yang lebih sedikit daripada nilai yang jarang.
Perbezaan antara format kebanyakannya terletak pada langkah pertama. JPEG dan AVIF menggunakan transformasi frekuensi (DCT). PNG dan WebP-lossless menggunakan penapisan prediktif. GIF menggunakan pengekodan kamus (LZW). Nisbah mampatan yang anda lihat di luar sana ditentukan oleh betapa bijaknya setiap format membuang atau membungkus data.
Apakah perbezaan antara mampatan lossy dan lossless?
Perbezaan yang paling penting dalam mampatan imej ialah sama ada data dibuang.
Mampatan Lossless membina semula piksel asal demi piksel. Ia hanya boleh membuang redundancy — bait berulang, gradien yang boleh diramal, urutan warna yang sama. Hadnya adalah entropi imej: bunyi rawak tulen hampir tidak mampat langsung. PNG, GIF, dan WebP-lossless berada di sini.
Mampatan Lossy membuang maklumat secara kekal, bertaruh bahawa apa yang dibuang berada di bawah ambang persepsi anda. Pertaruhan itu biasanya pada perincian frekuensi tinggi (tekstur halus, tepi) dan resolusi warna (mata anda membaca kecerahan jauh lebih tajam daripada rona). JPEG, WebP-lossy, AVIF, dan HEIC berada di sini.
Hasilnya sangat ketara. Untuk foto tipikal, output lossy selalunya 5 hingga 10 kali lebih kecil daripada setara lossless pada tahap kualiti yang kebanyakan penonton tidak dapat bezakan daripada asal. Kosnya ialah ketidakbolehbalikan: setiap pengekodan semula lossy menggandakan artifak, itulah sebabnya anda menyimpan fail master yang bersih.
Bagaimana mampatan DCT JPEG sebenarnya berfungsi?
JPEG ialah saluran kehilangan kualiti yang kanonik. Ia berjalan dalam lima peringkat, dan Discrete Cosine Transform (DCT) adalah intinya. Lima peringkat tersebut ialah:
| Peringkat | Apa yang berlaku | Boleh dipulihkan? |
|---|---|---|
| 1. Color conversion | RGB menjadi YCbCr (satu saluran luma, dua saluran chroma) | Yes |
| 2. Chroma subsampling | Chroma dikurangkan saiznya, biasanya kepada 4:2:0 | No (kehilangan perincian warna) |
| 3. Block split + DCT | Setiap saluran dibahagikan kepada blok 8x8; DCT menukarkan setiap satu menjadi 64 pekali frekuensi | Yes |
| 4. Quantization | Pekali dibahagi dengan matriks; banyak yang dibundarkan ke sifar | No (kehilangan utama) |
| 5. Entropy coding | Pekali disusun secara zigzag, dikodkan panjang larian (run-length encoded), kemudian dikod Huffman | Yes |
Berikut adalah contoh konkrit langkah DCT. Ambil blok 8x8 di mana setiap piksel mempunyai nilai luminans yang sama iaitu 200. Pengekod pertama-tama melakukan level-shift dengan menolak 128, meninggalkan blok rata bernilai 72. Kemudian, 2D DCT menghasilkan 64 pekali — tetapi kerana inputnya sangat rata, hanya pekali kiri atas (istilah DC) yang tidak sifar, dan nilainya sama dengan 8 kali 72, atau 576. 63 pekali yang lain adalah tepat sifar.
Sekarang langkah kehilangan kualiti. Matriks kuantisasi luminans JPEG standard membahagikan pekali DC dengan 16, menghasilkan 36, dan membahagikan setiap pekali AC frekuensi tinggi dengan nombor yang lebih besar. Oleh kerana pekali AC sudah sifar, kuantisasi tidak mengubah apa-apa di sini. Selepas zigzag ordering, keseluruhan blok nilai 64 disimpan sebagai satu nilai DC 36 diikuti oleh penanda akhir blok (end-of-block marker). Enam puluh empat piksel menjadi kira-kira dua nombor.
Inilah sebab mengapa kawasan rata dalam JPEG mampat dengan sangat baik. Mod kegagalan adalah sebaliknya: blok dengan tepi menegak yang tajam menyebarkan tenaga merentasi banyak pekali AC. Kuantisasi menjadikan pekali frekuensi tinggi menjadi sifar, tepi itu melunak, dan pada kualiti rendah anda akan melihat artifak blocking 8x8 klasik. Untuk pecahan langkah demi langkah penuh termasuk matematik chroma subsampling, sila lihat image compression deep dive yang berkaitan.

Apakah pengekodan Huffman dan mampatan entropi?
Setelah DCT dan quantization menukar blok menjadi aliran integer yang kebanyakannya kecil (dengan rentetan panjang sifar), peringkat akhir akan memadatkan integer-integer itu ke dalam bilangan bit yang paling sedikit. Ini adalah entropy coding, dan Huffman coding ialah enjin utamanya.
Huffman coding menetapkan kod binari pendek untuk nilai yang kerap dan kod panjang untuk nilai yang jarang. Jika nilai sifar muncul 60 percent masa dalam data quantized anda, ia mungkin mendapat kod 2-bit, manakala pekali besar yang jarang hanya mendapat 12 bits. Format ini menyimpan jadual kod di hadapan supaya decoder boleh membalikkannya. Langkah ini adalah sepenuhnya boleh dibalikkan — ia tidak memperkenalkan sebarang kehilangan — tetapi di sinilah bahagian besar penjimatan byte sebenarnya muncul, kerana quantization menghasilkan taburan senget yang tepat yang dieksploitasi oleh Huffman coding.
Lapisan JPEG menjalankan run-length encoding di atasnya: rentetan lima belas pekali sifar yang sama dikodkan sebagai satu simbol lompatan (skip symbol) berbanding lima belas nilai berasingan. Artikel Wikipedia tentang JPEG mendokumentasikan susunan imbasan zigzag dan struktur jadual Huffman yang tepat jika anda ingin melaksanakannya sendiri.
Format moden pergi lebih jauh. WebP dan AVIF boleh menggunakan arithmetic coding, yang memerah keluar kira-kira 5 hingga 10 percent lebih daripada Huffman dengan kos pengekodan yang lebih perlahan. Brotli, yang digunakan di tempat lain dalam pengangkutan web, menggabungkan model konteks yang lebih besar dengan Huffman; spesifikasi Brotli (RFC 7932) berbaloi untuk dibaca untuk melihat bagaimana entropy coder moden dibina.
Bagaimana PNG dan GIF menggunakan LZW dan Deflate?
Format lossless tidak boleh melakukan kuantisasi, jadi ia bergantung sepenuhnya pada mencari dan menghilangkan redundansi. PNG dan GIF mengambil laluan yang berbeza.
PNG menjalankan dua peringkat. Pertama, penapisan baris (row filtering): setiap garis imbasan ditransformasikan menggunakan salah satu daripada lima pengamal (predictors) (None, Sub, Up, Average, Paeth), menyimpan perbezaan antara setiap piksel dan anggaran berasaskan jiran berbanding nilai mentah. Dalam gradien yang licin, perbezaan itu kecil, berkumpul berhampiran sifar, dan jauh lebih mudah untuk dimampatkan. Kedua, Deflate: bait yang ditapis melalui LZ77, yang menggantikan urutan bait berulang dengan rujukan balik (back-references), diikuti oleh pengekodan Huffman. Deflate ialah algoritma yang sama digunakan oleh ZIP.
GIF mengambil laluan yang lebih ringkas dengan LZW (Lempel-Ziv-Welch). LZW membina kamus corak secara langsung (on the fly): ia bermula dengan semua nilai satu bait, dan semasa membaca data, ia menambah urutan yang semakin panjang yang telah dilihat. Apabila suatu urutan berulang, ia dikeluarkan sebagai indeks kamus tunggal. LZW pantas dan tidak memerlukan jadual kod tersimpan, itulah sebabnya GIF boleh dinyahkod pada perkakasan tahun 1990-an.
Batasan sebenar GIF bukanlah pada pemampatan. Ia adalah palet 256 warna yang dikuatkuasakan, yang digunakan sebelum LZW berjalan. Bagi sebuah gambar foto, kuantisasi warna itu menyebabkan kerosakan visual yang lebih ketara daripada apa jua pemampatan boleh lakukan. Inilah sebabnya mengapa GIF kekal terutamanya untuk animasi pendek walaupun LZW sendiri adalah sempurna.
Panduan Praktikal PNG dan GIF:
- Gunakan PNG-8 (indeks, sehingga 256 warna) untuk grafik rata dan logo — ia jauh lebih kecil daripada PNG-24.
- Pilih PNG atau WebP-lossless untuk tangkapan skrin dan UI yang banyak teks, di mana kuantisasi lossy akan mengaburkan tepi.
- Buang chunk yang tidak diperlukan (EXIF, profil ICC yang tidak digunakan, saluran alfa pada imej legap) sebelum menerbitkan.
- Elakkan GIF untuk apa-apa yang bersifat fotografi; had 256 warna adalah kesesakan (bottleneck), bukan LZW.
Mengapa WebP lebih kecil, dan mengapa AVIF mengalahkannya?
WebP dan AVIF adalah dua format moden yang paling banyak digunakan oleh pasukan kini, dan kedua-duanya meminjam daripada codec video. Mereka menang dengan meramalkan blok di seluruh bingkai, bukan hanya dalam grid 8x8 tetap seperti JPEG.
WebP Lossy menggunakan codec video VP8. Ia mengaplikasikan ramalan blok merentasi saiz blok berbeza, menggunakan transformasi 4x4 dan 8x8, serta pengekod entropi yang lebih baik daripada JPEG asas. Hasilnya kira-kira 25 hingga 34 peratus lebih kecil daripada JPEG pada kualiti visual yang sepadan. WebP Lossless menggabungkan sehingga 13 mod ramalan, transformasi ruang warna, dan varian LZ77, biasanya mengatasi PNG sebanyak 20 hingga 26 peratus.

AVIF pergi lebih jauh dengan menggunakan semula alat intra-frame codec video AV1. Saiz blok berbeza berjalan dari 4x4 sehingga 128x128, terdapat 67 mod ramalan arah, dan penapisan dalam gelung melicinkan artifak sebelum bingkai dimuktamadkan. AVIF biasanya mengatasi WebP lossy lagi sebanyak 20 hingga 30 peratus pada foto.
Pertukaran yang jujur adalah kelajuan. Pengekodan AVIF kira-kira 5 hingga 10 kali lebih perlahan daripada WebP, kerana ramalan dan penapisan adalah berat secara pengkomputeran. Untuk langkah binaan yang dijalankan sekali, itu okey. Untuk penukaran masa nyata dalam laluan permintaan panas, ia boleh menjadi masalah. HEIC, bekas Apple untuk gambar HEVC, menawarkan keuntungan serupa dengan AVIF tetapi membawa beban lesen paten yang lebih berat, itulah sebabnya web terbuka telah menyeragamkan pada AVIF sebaliknya.
Mana tetapan kualiti mampatan yang perlu anda gunakan?
Mulakan dengan nilai lalai ini, kemudian sesuaikan mengikut kandungan spesifik anda. Ini adalah titik permulaan, bukan undang-undang.
| Kes penggunaan | Format | Kualiti mula | Saiz sasaran |
|---|---|---|---|
| Hero / LCP image | WebP atau AVIF | 75 to 80 | Under 200 KB |
| Product photo | WebP atau AVIF | 80 to 85 | Under 100 KB |
| In-article photo | WebP | 72 to 80 | Under 150 KB |
| Thumbnail | WebP | 70 to 75 | Under 30 KB |
| Screenshot with text | PNG atau WebP lossless | lossless | Varies |
| Logo or icon | SVG, PNG, atau lossless WebP | lossless | Under 10 KB |
Dua peraturan lebih penting daripada nombor yang tepat. Pertama, bandingkan format pada kualiti visual yang sepadan, bukan nombor kualiti yang sepadan — AVIF pada 60, WebP pada 75, dan JPEG pada 85 kelihatan serupa, jadi membandingkan ketiga-tiga ini pada "80" adalah tidak bermakna. Kedua, sentiasa ubah saiz sebelum mampatkan. Asal kamera 4000-pixel yang dieksport pada kualiti 80 masih muat turun 4000-pixel; mengurangkan saiz kepada saiz paparan menjimatkan lebih banyak bait daripada sebarang perubahan kualiti.
Saya mengukur ini secara langsung. Saya menyulitkan foto 1200x800 yang sama pada JPEG q75, WebP q75, dan AVIF q60, dinilai setara secara visual pada saiz paparan. JPEG adalah 174 KB, WebP adalah 128 KB, dan AVIF adalah 96 KB — kira-kira 26 peratus lebih kecil daripada WebP dan 45 peratus lebih kecil daripada JPEG, untuk imej yang tidak dapat saya bezakan dengan yakin dalam A/B buta. Nombor anda akan berbeza mengikut kandungan, tetapi urutannya konsisten. Untuk alat fokus bagi menjalankan perbandingan ini sendiri, cuba Image Compressor atau baca AVIF vs WebP comparison.
Bagaimana memilih algoritma yang sesuai untuk setiap imej?
Keputusan ini didorong oleh kandungan, bukan oleh format mana yang paling baharu.
- Foto dan gradien kompleks: WebP atau AVIF lossy. Saiz byte paling kecil, dan mata akan menyembunyikan kehilangan tersebut.
- Teks tajam, tangkapan skrin UI, seni garis, logo: PNG atau WebP lossless. Kuantisasi akan mengaburkan tepi dan menyebabkan aliasing.
- Potongan transparan: WebP atau PNG lossless. Berhati-hati dengan artifak halo pada tepi alfa.
- Animasi pendek ringkas: WebP animasi (atau AVIF). Elakkan GIF untuk apa-apa yang terperinci.
- Master arkib: simpan RAW asal atau JPEG berkualiti tinggi. Jangan pernah anggap eksport lossy sebagai master.
- Fallback keserasian maksimum: JPEG, disajikan melalui elemen
<picture>supaya pelayar moden masih mendapat AVIF atau WebP.
Aliran kerja praktikal, secara berurutan: simpan master yang bersih, ubah saiz kepada kotak paparan terbesar dengan Image Resizer, pilih format mengikut kandungan, eksport dua atau tiga calon kualiti, buang metadata yang tidak diperlukan, dan periksa hasilnya pada saiz paparan akhir. Panduan compress images without losing quality guide menerangkan keseluruhan proses ini. Anda juga boleh merujuk image format guidance Google untuk nota sokongan pelayar apabila anda menyambungkan fallbacks.
Kesilapan mampatan biasa
- Mampatkan semula JPEG yang sudah lossy. Setiap pengekodan menambah artifak. Sentiasa sunting dari fail induk (master).
- Menggunakan PNG untuk setiap gambar kerana terasa selamat. PNG tiada langkah kuantisasi, jadi foto akan kekal sangat besar.
- Percaya satu nombor kualiti merentasi format. Skala JPEG, WebP, dan AVIF tidak boleh dibandingkan.
- Mengoptimumkan sebelum mengubah saiz. Kecilkan saiz (downscale) dahulu — ini adalah penjimatan bait terbesar yang ada.
- Menyediakan AVIF atau WebP tanpa fallback JPEG. Pelayar yang lebih lama dan kebanyakan klien e-mel tidak akan memaparkan apa-apa.
- Meninggalkan chroma subsampling 4:2:0 pada teks berwarna. Ia akan mengaburkan warna merah dan biru; gunakan 4:4:4 atau PNG untuk teks.
- Mengabaikan kos pengekodan. Kelebihan AVIF adalah nyata, tetapi mengekodkannya pada setiap permintaan boleh mendominasi CPU.
Ringkasan: algoritma adalah cara, bukan matlamat
Algoritma mampatan bukan kemenangan percuma. AVIF memberikan fail terkecil kepada anda, tetapi kos pengekodannya boleh menjadi berat dalam hot path, dan penyahkodannya lebih berat daripada JPEG pada peranti berprestasi rendah. PNG adalah tanpa kehilangan yang sempurna, tetapi menghantarnya untuk foto hero akan membengkakkan Largest Contentful Paint anda tanpa faedah visual yang kelihatan. Jawapan yang betul hampir selalu adalah keputusan format-mengikut-kandungan (format-per-content) yang disokong dengan sandaran (fallback), bukan satu tetapan global tunggal.
Kemahiran yang paling berguna bukanlah menghafal matriks kuantisasi — tetapi menilai setiap imej pada saiz paparan sebenar, menyimpan master yang bersih, dan menyahkod semula sekali berbanding menambah kehilangan. Jika anda mendapatkan aliran kerja itu dengan betul, format tertentu akan menjadi pilihan sekunder.

Kredit Imej
- Corak piksel abstrak dalam biru dan merah jambu — foto oleh Suzy Hazelwood di Pexels
- Bar corak ujian berwarna-warni — foto oleh Tim Mossholder di Pexels
- Pandangan dekat kod sumber berwarna-warni pada skrin — foto oleh Pixabay di Pexels
Gunakan alat percuma kami semasa mengikuti panduan ini.
Teruskan membaca

Wed Mar 18 2026 20:00:00 GMT-0400 (北美东部夏令时间)
Penukar WebP: Cara Tukar Imej ke WebP (Dengan Saiz Sebenar)
Tukar imej JPEG dan PNG kepada format WebP untuk fail web yang lebih kecil. Kami menyediakan saiz sebenar, arahan cwebp, kaedah Python & pelayar, serta strategi sandaran (fallback) JPEG/PNG.

Tue Mar 17 2026 20:00:00 GMT-0400 (北美东部夏令时间)
PNG ke WebP: Cara Tukar dan Kecilkan Imej PNG
Tukar PNG kepada WebP untuk fail web yang lebih kecil. Apabila WebP tanpa kehilangan data unggul, apabila dengan kehilangan data sesuai, saiz sebenar diukur, bersama arahan cwebp dan Pillow serta sandaran PNG.

Tue Mar 10 2026 20:00:00 GMT-0400 (北美东部夏令时间)
Optimasi SEO Imej: Senarai Semak Praktikal 2026
Senarai semak SEO imej yang praktikal untuk 2026: teks alt, nama fail, format, mampatan (compression), Core Web Vitals, data berstruktur, dan pengukuran.