LeanImg

PNG vs JPG: mana yang seharusnya Anda simpan?

Tanpa kehilangan versus kehilangan, saluran alpha yang tidak dimiliki JPG dan subsampling kromatik yang memburamkan teks, dengan ukuran file yang diukur dari kedua format.

PNG dan JPG berbeda dalam satu pertanyaan: apakah file mengingat setiap piksel dengan tepat? PNG melakukannya. JPG membuang detail yang sulit ditangkap oleh penglihatan manusia, dan hasilnya jauh lebih kecil. Pemisahan tunggal ini memutuskan hampir setiap kasus yang akan Anda temui, dan itu satu arah untuk foto pantai dan arah lainnya untuk tangkapan layar dari spreadsheet.

Setiap angka di bawah ini berasal dari alat LeanImg yang berjalan di tab browser, pada dua file uji: texture.jpg pada 3840x2160 dan 538,6 KB, ditambah alpha.png pada 900x606 dan 942,4 KB dengan latar belakang transparan. Kami membangun alat ini tanpa jalur API dan tanpa tindakan server, jadi file tidak pernah meninggalkan mesin Anda. Sebagian besar situs dalam kategori ini mengunggah gambar Anda ke server dan kemudian berjanji untuk menghapusnya satu jam kemudian. Tidak ada yang perlu dihapus di sini, itulah sebabnya halaman privasi kami singkat.

Mana yang harus saya pilih, PNG atau JPG?

Foto masuk ke JPG. Tangkapan layar, logo, grafik, seni garis, dan apa pun yang membutuhkan transparansi masuk ke PNG. Panduan format MDN menarik garis yang sama. Dalam mode pintar, kompresor kami mengambil texture.jpg dari 538,6 KB menjadi 286,1 KB dengan MozJPEG pada kualitas 80, pemotongan 47%. Geser penggeser ke 60 dan foto yang sama menjadi 212,4 KB. Pada 30, ukurannya 131 KB, turun 76%.

Pemisahan itu berasal dari bagaimana masing-masing format melakukan kompresi. Desain JPG mengasumsikan piksel yang berdekatan menyatu satu sama lain, yang cocok untuk gradien dan butiran film. Tangkapan layar melanggar asumsi itu di setiap tepi teks. PNG memprediksi setiap piksel dari tetangganya dan kemudian mengempiskan perbedaannya, sehingga melakukan pekerjaan terbaiknya pada jalur datar dari warna identik yang menjadi bagian dari antarmuka pengguna.

Apa yang sebenarnya dilakukan kompresi tanpa kehilangan terhadap ukuran file?

Tanpa kehilangan berarti piksel yang terdekompresi kembali identik bit demi bit, yang diharuskan oleh spesifikasi PNG. Itu tidak berarti file tidak bisa menyusut. Mode PNG dari kompresor kami menjalankan oxipng pada level 3, dan itu mengambil alpha.png dari 942,4 KB menjadi 383,9 KB. Itu 59% lebih kecil dengan setiap nilai piksel yang dipertahankan.

Opsi PNG "ukuran file lebih kecil" adalah hewan yang berbeda. Itu menjalankan imagequant, yang mengurangi gambar menjadi palet warna sebelum PNG ditulis, dan alpha.png keluar pada 98,3 KB. Itu 90% lebih kecil. Ini adalah hasil yang kehilangan, terlepas dari apa yang diimplikasikan oleh ekstensi .png, jadi simpan salinan aslinya jika gambar itu adalah salinan master.

Kartu hasil kompresor LeanImg menunjukkan alpha.png dikurangi dari 942,4 KB menjadi 98,3 KB menggunakan mode palet
alpha.png pada 900x606, dikuantisasi ke palet: 942,4 KB turun menjadi 98,3 KB, pemotongan 90%.

Mengapa JPG memburamkan teks berwarna dan garis tipis?

Karena JPG menyimpan warna pada resolusi yang lebih rendah daripada kecerahan. Format ini memisahkan luma dari dua saluran kromatik, seperti yang ditentukan dalam ITU-T T.81, dan encoder biasanya menurunkan sampel kromatik sehingga satu sampel warna mencakup blok piksel 2x2. Pada foto 3840x2160 seperti texture.jpg Anda tidak akan melihatnya. Pada garis merah satu piksel di atas putih, warna garis itu dirata-rata dengan tiga tetangga putih sebelum pengaturan kualitas diterapkan, dan tidak ada posisi penggeser yang mengembalikannya.

Tangkapan layar adalah tempatnya menggigit. Beralih ke WebP tidak menghindarinya, karena mode kehilangan WebP terkunci pada kromatik 4:2:0 dan menerapkan rata-rata yang sama. PNG mempertahankan nilai RGB yang tepat dari setiap piksel, itulah sebabnya tangkapan UI, kode QR, dan overlay teks berada di sana. Jika PNG masih terlalu berat, kuantisasi dan pertahankan formatnya.

Apa yang terjadi pada transparansi ketika saya menyimpan sebagai JPG?

Itu akan terisi. JPEG tidak membawa saluran alpha dalam mode apa pun, jadi sesuatu harus memutuskan apa yang berada di belakang piksel transparan Anda. Konverter PNG ke JPG kami mengompositnya ke putih sebelum encoding, dan kompresor melakukan hal yang sama setiap kali format target tidak memiliki alpha. Tanpa langkah itu, mereka akan keluar hitam, karena piksel yang sepenuhnya transparan biasanya membawa RGB 0,0,0 di bawahnya.

Anda tidak dapat membalik perjalanan itu. Kembali melalui JPG ke PNG memberi Anda PNG dengan persegi panjang putih di mana transparansi sebelumnya berada, ditambah artefak JPG apa pun yang dibakar dalam proses pertama. Mengompresi juga menghapus setiap bagian metadata: EXIF, GPS, profil ICC, dan thumbnail yang disematkan semuanya hilang, meskipun orientasi tetap. Simpan master PNG; Anda akan membutuhkannya. Jika Anda memotong subjek dari foto, penghapus latar belakang kami selalu menulis PNG dengan alpha karena alasan ini, yang juga mengapa potongan kembali lebih berat daripada JPG yang Anda masukkan, dan generator ikon secara default mengatur warna latar belakangnya ke #ffffff, sehingga logo transparan mendarat di kotak putih sampai Anda mengubah bidang itu.

Mengapa PNG saya jauh lebih besar daripada JPG?

Kebisingan fotografis memberi prediktor PNG tidak ada yang bisa dikerjakan. Setiap baris ditebak dari baris di atasnya dan perbedaan yang tersisa dikempiskan, yang sangat baik pada tombol datar dan hampir tidak berguna pada butiran. Lihat dua file uji. alpha.png adalah 900x606 dan tiba pada 942,4 KB, sementara texture.jpg adalah 3840x2160, lebih dari lima belas kali jumlah piksel, dan tiba pada 538,6 KB. Kuantisasi palet adalah tuas yang menutup celah itu, dan itu membawa alpha.png ke 98,3 KB.

Haruskah saya menyimpan WebP atau AVIF dan melewatkan pertanyaan?

Terkadang, meskipun itu layak diukur. Kami menjalankan texture.jpg melalui kompresor pada posisi penggeser yang sama yaitu 80 untuk ketiga format, kemudian lagi pada 63.

Sumber yang sama kedua kali: texture.jpg, 3840x2160, 538,6 KB.
Format keluaranPenggeser 80Penggeser 63Waktu encoding
JPEG (MozJPEG)286,1 KBtidak diukurinstan
WebP290,3 KB200,6 KBinstan
AVIF312,7 KB186,9 KB10 hingga 11 detik

AVIF yang menghasilkan file terbesar pada penggeser 80 terlihat mundur, dan penyebabnya terletak pada kode kami sendiri. Untuk sumber JPEG, kompresor mengalikan penggeser Anda dengan kualitas yang dibaca dari tabel kuantisasi sumber, jadi sumber yang diperkirakan pada 60 dengan penggeser di 80 sebenarnya mengkodekan pada 48. WebP dan AVIF mengambil 80 apa adanya. Pada 63, yang merupakan default mode pintar untuk AVIF, urutannya terbalik: AVIF adalah 186,9 KB dan WebP adalah 200,6 KB terhadap sumber 538,6 KB itu. AVIF juga memerlukan 10 hingga 11 detik per encoding di mana JPEG dan WebP selesai secara instan, dan layak untuk memeriksa dukungan browser sebelum Anda berkomitmen. Kami membahas perbandingan itu secara panjang lebar dalam artikel tentang apakah WebP benar-benar mengalahkan JPG.

Apa yang harus saya lakukan dengan file di depan saya?

Buka kompresor. Jalankan file Anda dua kali. Jika itu adalah foto, ambil mode pintar terlebih dahulu, lalu dorong penggeser ke 60 dan bandingkan kedua keluaran pada zoom penuh. Jika ada teks atau transparansi, tetaplah pada PNG dan coba kedua mode PNG: tanpa kehilangan membawa alpha.png ke 383,9 KB dan mode palet membawanya ke 98,3 KB. Ukur ulang terlebih dahulu ketika gambar ditujukan untuk kolom 800px, karena pengubah ukuran menulis PNG tanpa kehilangan dan mengkode ulang semuanya dengan kualitas 90 secara default. Dan jika tujuannya adalah dokumen, JPG mendarat di halaman PDF yang dikode ulang sekali lagi pada kualitas 92, yang merupakan satu generasi ekstra untuk direncanakan.