Bagaimana Algoritma Kompresi Gambar Benar Berfungsi: DCT, LZW & AVIF

Terakhir diperbarui: June 28, 2026

Kompresi gambar mengecilkan ukuran file dengan menghilangkan informasi yang sulit dilihat oleh mata Anda. Algoritma di balik JPEG, PNG, GIF, WebP, dan AVIF bukanlah sihir—mereka adalah tumpukan langkah mekanis spesifik. Memahami hal ini memberi tahu Anda mengapa JPEG pada kualitas 80 terlihat baik, mengapa PNG membengkak pada foto, dan mengapa AVIF mengkodekan begitu lambat. Ini adalah panduan praktisi mengenai matematika sebenarnya, bukan kontes popularitas format.

Jawaban singkat: bagaimana algoritma kompresi gambar bekerja?

Setiap format melakukan tiga pekerjaan yang sama secara berurutan. Pertama, ia mentransformasi piksel sehingga informasi penting terkonsentrasi dalam beberapa angka. Kedua, ia mengkuantisasi—membulatkan angka-angka yang berkontribusi paling sedikit (ini adalah bagian lossy, dan format lossless melewatinya). Ketiga, ia mengkodekan entropi nilai yang tersisa sehingga nilai yang sering muncul membutuhkan bit lebih sedikit daripada nilai yang jarang.

Perbedaan antar format sebagian besar terletak pada langkah pertama. JPEG dan AVIF menggunakan transformasi frekuensi (DCT). PNG dan WebP-lossless menggunakan predictive filtering. GIF menggunakan dictionary coding (LZW). Rasio kompresi yang Anda lihat di lapangan ditentukan oleh seberapa cerdas setiap format membuang atau mengemas data.

Apa perbedaan antara kompresi lossy dan lossless?

Perbedaan paling penting dalam kompresi gambar adalah apakah datanya dibuang.

Kompresi Lossless merekonstruksi piksel asli demi piksel. Ia hanya dapat menghilangkan redundancy—byte yang berulang, gradien yang dapat diprediksi, atau deretan warna identik. Batas atasnya adalah entropi dari gambar: noise acak murni hampir tidak terkompresi sama sekali. PNG, GIF, dan WebP-lossless hidup di sini.

Kompresi Lossy membuang informasi secara permanen, bertaruh bahwa apa yang dibuang berada di bawah ambang batas persepsi Anda. Taruhan ini biasanya pada detail frekuensi tinggi (tekstur halus, tepi) dan resolusi warna (mata Anda membaca kecerahan jauh lebih tajam daripada rona). JPEG, WebP-lossy, AVIF, dan HEIC hidup di sini.

Hasilnya sangat dramatis. Untuk foto biasa, output lossy seringkali 5 hingga 10 kali lebih kecil dari setara lossless pada tingkat kualitas yang tidak dapat dibedakan oleh sebagian besar penonton dari aslinya. Biayanya adalah irreversibilitas: setiap re-encode lossy memperparah artefak, itulah sebabnya Anda menyimpan file master yang bersih.

Bagaimana sebenarnya kompresi DCT JPEG bekerja?

JPEG adalah pipeline lossy kanonik. Ia berjalan dalam lima tahap, dan Discrete Cosine Transform (DCT) adalah intinya. Lima tahap tersebut adalah:

Berikut adalah contoh konkret dari langkah DCT. Ambil blok 8x8 di mana setiap piksel memiliki nilai luminansi yang sama yaitu 200. Encoder pertama-tama melakukan pergeseran tingkat (level-shifts) dengan mengurangi 128, meninggalkan blok datar 72. DCT 2D kemudian menghasilkan 64 koefisien—tetapi karena inputnya benar-benar datar, hanya koefisien kiri atas (istilah DC) yang tidak nol, dan nilainya sama dengan 8 kali 72, atau 576. 63 koefisien lainnya tepat nol.

Sekarang langkah lossy. Matriks kuantisasi luminansi JPEG standar membagi koefisien DC dengan 16, menghasilkan 36, dan membagi setiap koefisien AC frekuensi tinggi dengan angka yang lebih besar. Karena koefisien AC sudah nol, kuantisasi tidak mengubah apa pun di sini. Setelah pengurutan zigzag, seluruh blok 64 nilai disimpan sebagai satu nilai DC tunggal sebesar 36 diikuti oleh penanda akhir blok. Enam puluh empat piksel menjadi kurang lebih dua angka.

Inilah sebabnya mengapa area datar pada JPEG terkompresi dengan sangat baik. Mode kegagalannya adalah sebaliknya: blok dengan tepi vertikal tajam menyebarkan energi ke banyak koefisien AC. Kuantisasi membuat yang frekuensi tinggi menjadi nol, tepian melunak, dan pada kualitas rendah Anda melihat artefak blocking 8x8 klasik. Untuk rincian langkah demi langkah termasuk matematika subsampling chroma, lihat image compression deep dive terkait.

Apa itu Huffman coding dan kompresi entropi?

Setelah DCT dan kuantisasi mengubah blok menjadi aliran integer yang sebagian besar kecil (dengan deretan nol yang panjang), tahap terakhir mengemas integer-integer tersebut menjadi bit sesedikit mungkin. Ini adalah entropy coding, dan Huffman coding adalah alat utamanya.

Huffman coding menetapkan kode biner pendek untuk nilai yang sering muncul dan kode panjang untuk nilai yang jarang muncul. Jika nilai nol muncul 60 persen dari waktu dalam data kuantisasi Anda, ia mungkin mendapatkan kode 2-bit, sementara koefisien besar yang jarang muncul mendapatkan 12 bit. Format menyimpan tabel kode di awal sehingga decoder dapat membalikkannya. Langkah ini sepenuhnya dapat dibalik—tidak memperkenalkan kerugian apa pun—tetapi di sinilah sebagian besar penghematan byte benar-benar terlihat, karena kuantisasi menghasilkan distribusi miring yang dieksploitasi oleh Huffman coding.

Lapisan JPEG menjalankan run-length encoding di atasnya: deretan koefisien nol identik selama lima belas kali dikodekan sebagai satu simbol skip daripada lima belas nilai terpisah. Artikel Wikipedia JPEG mendokumentasikan urutan pemindaian zigzag dan struktur tabel Huffman yang tepat jika Anda ingin mengimplementasikannya sendiri.

Format modern melangkah lebih jauh. WebP dan AVIF dapat menggunakan arithmetic coding, yang mengeluarkan sekitar 5 hingga 10 persen lebih banyak daripada Huffman dengan biaya decoding yang lebih lambat. Brotli, yang digunakan di tempat lain dalam transportasi web, menggabungkan model konteks yang lebih besar dengan Huffman; Spesifikasi Brotli (RFC 7932) layak dibaca untuk melihat bagaimana entropy coder modern dibangun.

Bagaimana PNG dan GIF menggunakan LZW dan Deflate?

Format lossless tidak dapat mengkuantisasi, jadi mereka sepenuhnya bergantung pada menemukan dan menghilangkan redundancy. PNG dan GIF mengambil rute yang berbeda.

PNG menjalankan dua tahap. Pertama, row filtering: setiap garis pemindaian ditransformasikan menggunakan salah satu dari lima prediktor (None, Sub, Up, Average, Paeth), menyimpan perbedaan antara setiap piksel dan tebakan berbasis tetangga alih-alih nilai mentah. Dalam gradien halus, perbedaan tersebut kecil, bergerombol di dekat nol, dan jauh lebih mudah dikompresi. Kedua, Deflate: byte yang difilter melewati LZ77, yang mengganti urutan byte berulang dengan back-references, diikuti oleh Huffman coding. Deflate adalah algoritma yang sama yang digunakan ZIP.

GIF mengambil jalur yang lebih sederhana dengan LZW (Lempel-Ziv-Welch). LZW membangun kamus pola secara langsung: ia dimulai dengan semua nilai satu-byte, dan saat membaca data ia menambahkan urutan yang semakin panjang yang sudah dilihatnya. Ketika sebuah urutan berulang, itu dikeluarkan sebagai indeks kamus tunggal. LZW cepat dan tidak memerlukan tabel kode yang disimpan, itulah sebabnya GIF dapat didekode pada perangkat keras tahun 1990-an.

Keterbatasan nyata GIF bukanlah kompresinya. Itu adalah palet warna 256 warna yang dipaksakan, diterapkan sebelum LZW berjalan. Untuk foto, kuantisasi warna itu menyebabkan kerusakan visual lebih besar daripada yang pernah dilakukan oleh kompresi. Inilah sebabnya mengapa GIF tetap ada terutama untuk animasi pendek meskipun LZW sendiri sempurna secara teori.

Panduan praktis PNG dan GIF:

• Gunakan PNG-8 (indeks, hingga 256 warna) untuk grafis datar dan logo—jauh lebih kecil daripada PNG-24.
• Pilih PNG atau WebP-lossless untuk tangkapan layar dan UI yang banyak teks, di mana kuantisasi lossy akan mengaburkan tepi.
• Hapus chunk yang tidak diperlukan (EXIF, profil ICC yang tidak digunakan, saluran alfa pada gambar buram) sebelum dipublikasikan.
• Hindari GIF untuk apa pun yang bersifat fotografi; batas 256 warna adalah hambatan, bukan LZW.

Mengapa WebP lebih kecil, dan mengapa AVIF mengalahkannya?

WebP dan AVIF adalah dua format modern yang paling sering digunakan tim saat ini, dan keduanya meminjam dari codec video. Mereka menang dengan memprediksi blok di seluruh bingkai, bukan hanya dalam kisi 8x8 tetap seperti JPEG.

WebP Lossy menggunakan codec video VP8. Ia menerapkan prediksi blok di berbagai ukuran blok, menggunakan transformasi 4x4 dan 8x8, serta entropy coder yang lebih baik daripada baseline JPEG. Hasilnya sekitar 25 hingga 34 persen lebih kecil dari JPEG pada kualitas visual yang sama. WebP Lossless menumpuk hingga 13 mode prediksi, transformasi ruang warna, dan varian LZ77, biasanya mengalahkan PNG sebesar 20 hingga 26 persen.

AVIF melangkah lebih jauh dengan menggunakan alat intra-frame dari codec video AV1. Ukuran blok variabel berkisar dari 4x4 hingga 128x128, ada 67 mode prediksi arah, dan in-loop filtering menghaluskan artefak sebelum bingkai diselesaikan. AVIF biasanya mengalahkan WebP lossy dengan tambahan 20 hingga 30 persen pada foto.

Pertukaran yang jujur adalah kecepatan. Encoding AVIF sekitar 5 hingga 10 kali lebih lambat daripada WebP, karena prediksi dan filtering sangat berat secara komputasi. Untuk langkah build yang dijalankan sekali, itu baik-baik saja. Untuk konversi on-the-fly dalam jalur permintaan panas (hot request path), itu bisa merugikan. HEIC, wadah Apple untuk gambar HEVC, menawarkan keuntungan serupa dengan AVIF tetapi membawa beban lisensi paten yang lebih berat, itulah sebabnya web terbuka telah menstandarisasi pada AVIF sebagai gantinya.

Pengaturan kualitas kompresi mana yang harus Anda gunakan?

Mulai dari default ini, lalu sesuaikan untuk konten spesifik Anda. Ini adalah titik awal, bukan hukum.

Dua aturan lebih penting daripada angka yang tepat. Pertama, bandingkan format pada kualitas visual yang sama, bukan pada angka kualitas yang sama—AVIF di 60, WebP di 75, dan JPEG di 85 terlihat kurang lebih serupa, jadi membandingkan ketiganya pada "80" tidak berarti apa-apa. Kedua, selalu ubah ukuran sebelum mengompresi. Asli kamera 4000 piksel yang diekspor pada kualitas 80 masih unduhan 4000 piksel; downscaling ke ukuran tampilan menghemat lebih banyak byte daripada penyesuaian kualitas apa pun.

Saya mengukur ini secara langsung. Saya mengkodekan foto 1200x800 yang sama pada JPEG q75, WebP q75, dan AVIF q60, dinilai setara secara visual pada ukuran tampilan. JPEG-nya adalah 174 KB, WebP-nya adalah 128 KB, dan AVIF-nya adalah 96 KB—sekitar 26 persen lebih kecil dari WebP dan 45 persen lebih kecil dari JPEG, untuk gambar yang tidak dapat saya bedakan secara andal dalam A/B buta. Angka Anda akan bervariasi dengan konten, tetapi urutannya konsisten. Untuk alat fokus untuk menjalankan perbandingan ini sendiri, coba Image Compressor atau baca AVIF vs WebP comparison.

Bagaimana cara memilih algoritma yang tepat untuk setiap gambar?

Keputusan didorong oleh konten, bukan oleh format mana yang terbaru.

• Foto dan gradien kompleks: WebP atau AVIF lossy. Byte terkecil, dan mata menyembunyikan kerugiannya.
• Teks tajam, tangkapan layar UI, seni garis, logo: PNG atau WebP lossless. Kuantisasi akan mengaburkan tepi dan aliasing.
• Potongan transparan: WebP atau PNG lossless. Perhatikan artefak halo pada tepi alfa.
• Animasi pendek sederhana: WebP animasi (atau AVIF). Hindari GIF untuk apa pun yang detail.
• Master arsip: simpan RAW asli atau JPEG berkualitas tinggi. Jangan pernah memperlakukan ekspor lossy sebagai master.
• Fallback kompatibilitas maksimum: JPEG, disajikan melalui elemen <picture> sehingga browser modern masih mendapatkan AVIF atau WebP.

Alur kerja praktis, secara berurutan: simpan master yang bersih, ubah ukuran ke kotak tampilan terbesar dengan Image Resizer, pilih format berdasarkan konten, ekspor dua atau tiga kandidat kualitas, hapus metadata yang tidak Anda butuhkan, dan periksa hasilnya pada ukuran tampilan akhir. Panduan kompres gambar tanpa kehilangan kualitas membahas seluruh proses. Anda juga dapat merujuk panduan format gambar Google untuk catatan dukungan browser saat Anda menyambungkan fallback.

Kesalahan kompresi umum

• Mengompres ulang JPEG yang sudah lossy. Setiap encode menambahkan artefak. Selalu edit dari master.
• Menggunakan PNG untuk setiap foto karena terasa aman. PNG tidak memiliki langkah kuantisasi, jadi foto tetap sangat besar.
• Percaya pada satu angka kualitas di berbagai format. Skala JPEG, WebP, dan AVIF tidak dapat dibandingkan.
• Mengoptimalkan sebelum mengubah ukuran. Ubah ukuran terlebih dahulu—itu adalah penghematan byte terbesar yang tersedia.
• Menyajikan AVIF atau WebP tanpa fallback JPEG. Browser lama dan sebagian besar klien email tidak menampilkan apa-apa.
• Membiarkan subsampling chroma 4:2:0 pada teks berwarna. Itu menyebarkan merah dan biru; gunakan 4:4:4 atau PNG untuk teks.
• Mengabaikan biaya encoding. Keuntungan AVIF nyata, tetapi mengkodekannya di setiap permintaan dapat mendominasi CPU.

Ringkasan: algoritma adalah sarana, bukan tujuan

Algoritma kompresi bukanlah kemenangan gratis. AVIF memberi Anda file terkecil, tetapi biaya encode-nya bisa menghukum dalam jalur panas (hot path), dan decoding-nya lebih berat daripada JPEG pada perangkat kelas bawah. PNG sepenuhnya lossless, tetapi menyajikannya untuk foto hero akan membengkakkan Largest Contentful Paint Anda tanpa manfaat visual. Jawaban yang tepat hampir selalu keputusan format per konten yang disajikan dengan fallback, bukan satu pengaturan global.

Keterampilan yang paling berguna bukanlah menghafal matriks kuantisasi—tetapi menilai setiap gambar pada ukuran tampilan sebenarnya, menyimpan master yang bersih, dan mengkodekan ulang sekali alih-alih menggandakan kerugian. Dapatkan alur kerja itu benar dan format spesifik menjadi pilihan sekunder.

Kredit Gambar

• Abstract pixelated pattern in blue and pink — foto oleh Suzy Hazelwood di Pexels
• Colorful test-pattern bars — foto oleh Tim Mossholder di Pexels
• Close-up of colorful source code on a screen — foto oleh Pixabay di Pexels