“Kompres gambar ini” sebenarnya adalah empat operasi berbeda yang menyamar jadi satu tombol. Mengetahui operasi mana yang memakan kualitasmu membuat setelan-setelannya jauh lebih masuk akal.
Langkah satu: dekode
File terkompresi dikembalikan menjadi sebuah kisi piksel. Browser melakukannya dengan kode native, lengkap dengan akselerasi perangkat keras di platform yang menyediakannya, dan mereka menangani JPEG, PNG, WebP, dan AVIF — ditambah HEIC di platform Apple, karena sistem operasinya memang sudah membawa dekoder itu.
Dekode bersifat lossless terhadap filenya: kamu mendapat persis piksel yang digambarkan file itu. Kehilangannya sudah terjadi lebih dulu, saat apa pun yang menghasilkan file itu mengodekannya.
Langkah dua: orientasi
Kamera ponsel menyimpan orientasi mentah sensornya ditambah sebuah tag EXIF terpisah yang menyatakan cara memutarnya. Perangkat lunak yang mengabaikan tag itu menghasilkan foto miring. Menerapkannya berarti memutar kisi pikselnya yang sesungguhnya sebelum apa pun menyentuhnya — dan setelah itu tag tersebut tidak diperlukan lagi, yang merupakan salah satu sebab pengodean ulang membuang metadata.
Langkah tiga: penyampelan ulang
Kalau ukuran target tidak bisa dicapai pada resolusi penuh, gambarnya diperkecil. Di sinilah banyak kualitas yang dirasakan diam-diam dimenangkan atau dihilangkan. Filter kotak yang murah sekadar merata-ratakan piksel bertetangga dan melembekkan segalanya; filter Lanczos menimbang lingkungan yang lebih luas dan menjaga tepinya tetap tajam.
Penyampelan ulang memang benar-benar merusak — piksel yang dibuang tidak akan kembali — tapi ia sering menjadi cara yang paling sedikit merusak untuk mencapai target kecil, karena ia membuang detail yang kalau tidak dibuang akan menghabiskan seluruh anggaran encoder hanya untuk gagal menggambarkannya.
Langkah empat: pengodean
Bagian yang lossy. JPEG mengubah gambar menjadi representasi kecerahan-plus-warna, membuang sebagian resolusi warna (mata nyaris tidak menyadarinya), membelah gambarnya menjadi blok 8×8, mengubah setiap blok menjadi komponen frekuensi, lalu mengkuantisasi — membulatkan hingga hilang detail berfrekuensi tinggi. Parameter kualitas adalah kekasaran pembulatan itu. Semua yang terjadi sesudahnya adalah pengodean entropi yang lossless, dan itulah sebabnya tabel Huffman yang dioptimalkan atau pemindaian progresif bisa menghemat byte secara cuma-cuma.
Di mana WebAssembly masuk
Encoder bawaan browser adalah kotak hitam: kamu bisa meminta sebuah angka kualitas dan tidak lebih dari itu. Tidak ada tabel entropi yang dioptimalkan, tidak ada pilihan baseline atau progresif, tidak ada kendali atas filter penyampelan ulang, dan tidak ada cara mengetahui berapa byte yang dihasilkan sebuah setelan tanpa mencobanya.
Codec yang dikompilasi ke WebAssembly mengembalikan semua itu, dengan ongkos berupa byte yang kamu habiskan untuk mengunduhnya. ToolZool menjalankan seluruh alurnya dengan cara itu — dekode, orientasi, penyampelan ulang, dan pengodean semuanya Rust yang dikompilasi ke WebAssembly, di dalam sebuah worker latar belakang — alih-alih menyerahkan dekodenya kepada browser. Ada tiga alasan, dan semuanya praktis:
- Pencariannya butuh banyak kali pengodean. Mencapai ukuran yang persis berarti mengodekan gambar yang sama lima atau enam kali. Memiliki encodernya sendiri yang membuat hal itu murah dan bisa diulang.
- Sebuah dekoder harus bisa berkata tidak. File yang mengaku berukuran 60.000 × 60.000 piksel harus ditolak sebelum ia mengalokasikan memori, dan file yang terpotong harus gagal alih-alih mengembalikan setengah gambar. Dekoder browser mengambil keputusannya sendiri di titik itu; punya kami menyatakan batasnya dan menegakkannya.
- Masukan yang sama harus memberi keluaran yang sama. Dekoder browser berbeda-beda dalam penanganan warna dan dalam cara memperlakukan file yang cacat. Alur yang memiliki kedua ujungnya menghasilkan byte yang sama di setiap perangkat, dan itulah yang membuat sebuah hasil bisa kamu periksa.
Ongkosnya kami sebut terus terang: mesin itu adalah sebuah unduhan. Ia baru diambil begitu kamu memilih sebuah file, jadi membaca halaman seperti ini tidak pernah membayarnya.
Kenapa pencariannya lebih penting daripada codec-nya
Untuk sebuah ukuran file target, selisih antara encoder yang bagus dan encoder yang hebat hanya beberapa persen. Selisih antara menebak-nebak slider kualitas dan mencari angka yang tepat jauh lebih besar, karena tebakan yang mendarat di 60% dari jatahmu berarti membuang sepertiga kualitas yang sebetulnya menjadi hakmu. Itulah seluruh gagasan di balik mengompres ke ukuran yang persis, dan menembus batas 50 KB memperlihatkan apa yang kamu dapat dari pencarian itu di ujung rentang yang paling sulit.

