Catatan dari tim tentang keahlian, format, dan keputusan kecil di balik hasil yang baik.
Kenapa WebP tidak didukung secara universal di aplikasi desktop
WebP dirilis Google pada 2010, tetapi penerimaan oleh perangkat lunak desktop tertinggal jauh di belakang dukungan browser. Browser menerima WebP sejak awal karena mereka mengendalikan mesin perendernya sendiri dan Google secara aktif mengasah dukungan WebP Chrome sebagai keunggulan bersaing. Aplikasi desktop butuh waktu lebih lama menerima format gambar baru karena masing-masing memelihara tumpukan pembacaan gambarnya sendiri, dan mendukung format baru menuntut pengujian terhadap rentetan panjang kasus tepi. Adobe Photoshop, yang dipakai mayoritas fotografer dan perancang profesional, baru mengirim dukungan WebP bawaan di versi 23.2 pada akhir 2022. Aplikasi Microsoft Office masih menangani WebP secara tidak seragam di berbagai platform hingga 2026. Perangkat lunak RIP cetak dan kebanyakan perkakas pengarsipan lawas tidak pernah menerimanya sama sekali. Akibat praktisnya, file yang tampil sempurna di browser bisa ditolak mentah-mentah oleh perangkat lunak yang dibutuhkan pengguna, dan mengubah ke PNG adalah jalan keluar yang andal.
Bagaimana WebP meraih keunggulan kompresi atas PNG
PNG memakai kompresi DEFLATE, sebuah algoritme lossless serbaguna dari 1996. Ia menerapkan serangkaian filter scanline yang dapat dibalik sebelum kompresi lalu menuliskan hasilnya sebagai aliran zlib. Cara ini efektif tetapi dirancang sebelum riset pembelajaran mesin dan codec video melahirkan teknik yang lebih baik. WebP mode lossy memakai transformasi berbasis blok yang diturunkan dari kompresi video VP8, menerapkan prediksi intra-bingkai dan transformasi kosinus diskret pada unit makroblok 16x16. WebP mode lossless memakai prediksi spasial, transformasi warna, dan tahap pengkodean LZ77 yang secara struktur lebih efisien daripada DEFLATE untuk isi gambar biasa. Tolok ukur terbitan Google menunjukkan WebP lossless sekitar 26 persen lebih kecil dari PNG pada kumpulan gambar uji standar, dan WebP lossy beralpha sekitar tiga kali lebih kecil dari PNG pada kualitas visual sebanding. Arah PNG ke WebP menuai penghematan ini, arah WebP ke PNG membalikkannya, karena itu keluarannya lebih besar.
Contoh pertumbuhan ukuran file yang terukur
Diukur pada Chrome 148, desktop Linux, memakai jalur penulisan PNG bawaan yang diterapkan pada masukan WebP yang sudah dibaca. Grafik bergaya vektor kecil berukuran 400x300 piksel, disimpan sebagai WebP pada kualitas 80, dibaca dan ditulis ulang sebagai PNG dalam kira-kira 15 sampai 25 ms dengan pertumbuhan ukuran khas 20 sampai 30 persen. WebP fotografis 1024x768, ukuran kecil, dibaca dan ditulis ulang ke PNG dalam waktu kurang dari 100 ms dengan pertumbuhan khas 3 sampai 5 kali. WebP fotografis besar 3840x2160, ukuran lebih besar, ditulis ke PNG dalam sekitar 1,2 detik dengan pertumbuhan 5 sampai 10 kali bergantung pada kerumitan adegan. Batas atas praktisnya kira-kira foto WebP besar menjadi PNG beberapa kali lebih besar. Angka-angka ini mencerminkan beda efisiensi kompresi kedua format dan menskala linear dengan jumlah piksel.
Transparansi alpha dalam perjalanan bolak-balik
Kanal alpha 8-bit di WebP dan PNG memakai rentang nilai yang sama, di mana 0 berarti sepenuhnya transparan dan 255 berarti sepenuhnya pekat. Ketika browser membaca WebP beralpha, ia menghasilkan penyangga piksel bernilai RGBA di mana komponen A mencerminkan data alpha asli. Saat penyangga itu ditulis ulang sebagai PNG, penulis PNG menaruh nilai A langsung ke kanal alpha PNG. Tidak ada tahap penggabungan, tidak ada warna latar yang ditambahkan, dan tidak ada efek samping pra-perkalian yang mengubah nilai piksel. Hasilnya pemindahan alpha yang lossless, di mana nilai keburaman tiap piksel di PNG sama dengan yang disimpan WebP. Untuk gambar dengan penghalusan tepi yang halus, setiap nilai alpha perantara, misalnya piksel pada keburaman 40 persen di tepi teks, melewati perjalanan dengan utuh. Kesetiaan inilah yang menjadikan PNG pilihan tepat ketimbang JPG saat aplikasi tujuan harus menampilkan gambar di atas beberapa latar.
Perilaku EXIF dan metadata
Alur penulisan ulang melepas metadata EXIF, IPTC, dan XMP dari keluaran PNG. File WebP bisa membawa data EXIF tertanam di bongkah metadatanya, dan data itu hilang saat browser membaca dan menulis ulang gambar. Profil warna ICC menempuh jalur berbeda, di mana Chrome dan Safari mempertahankan tanda profil ICC sRGB pada keluaran PNG setelah membaca WebP, dan Firefox melepas semua metadata termasuk profil ICC. Akibat praktisnya keluaran aman-sRGB di semua browser, tetapi profil gamut lebar mana pun yang tertanam di WebP sumber tidak bertahan di Firefox. Untuk alur kerja foto profesional yang bergantung pada perjalanan bertanda ICC, pakailah alat konversi yang peduli metadata. Untuk penanganan gambar web biasa, pelepasan metadata umumnya bisa diterima dan memberi keuntungan kecil berupa pengurangan sedikit ukuran file keluaran.
Memverifikasi privasi dalam praktik
Klaim bahwa tidak ada data file yang keluar dari browser bisa diperiksa tanpa alat khusus apa pun. Buka browser Anda, kunjungi halaman webp-to-png, lalu buka alat pengembang browser lewat F12 atau menu klik kanan. Pindah ke tab Network, bersihkan permintaan yang ada, dan jalankan konversi dengan menjatuhkan file WebP. Saring daftar permintaan berdasarkan Fetch, XHR, atau All. Daftar menampilkan nol permintaan keluar yang berisi data gambar selama penulisan. Satu-satunya permintaan jaringan yang ada adalah aset pemuatan halaman awal dan ping analitik standar, yang hanya merekam tampilan halaman dan data kinerja Core Web Vitals, tanpa isi gambar. Setiap pengubah WebP ke PNG jarak jauh besar setidaknya menghasilkan satu POST unggah dan satu GET unduh per konversi, keduanya tercatat di server. Arsitektur di-perangkat berarti entri log itu tidak pernah ada, dan inilah perbedaan berarti bagi pengguna yang mengubah file bermuatan sensitif.
