Upng.js: Gunakan dithering

Dibuat pada 27 Mar 2018  ·  5Komentar  ·  Sumber: photopea/UPNG.js

Ini penting untuk gambar berwarna.

Sumber gambar [174285 B]
firefox-512

Setelah upng, antarmuka web [69927 B]
firefox-512 upng

Hasil pngquant terlihat lebih baik. [69932 B]
firefox-512 pngquant

Komentar yang paling membantu

Ya, pngquant menghitung kesalahan kuadrat rata-rata, dan menerapkan dithering hanya di area dengan kesalahan tinggi. Dengan cara ini area yang tidak perlu dithering tidak mendapatkan kebisingan tambahan.

pngquant juga melakukan deteksi tepi (mirip dengan algoritma Prewitt) dan menonaktifkan dithering di tepi. Ini mencegah anti-aliasing terlihat seperti bulu.

Dalam pngquant, 90% waktu dihabiskan untuk menjalankan K-means ekstra. Jika Anda menggunakan --speed 10 seluruh rekompresi (pada i7 2.3Ghz) membutuhkan ~80 md dithered, 50 md tanpa dithering.

(BTW, TinyPNG tidak memiliki algoritme sendiri. Ini hanya GUI untuk pngquant).

Semua 5 komentar

Saya menerapkan dithering Floyd-Steinberg di masa lalu, tetapi itu tidak sepadan.

Saya pikir kita perlu beberapa dithering yang ramah kompresi. Apakah Anda tahu siapa saja yang bisa membantu kami?

pngquant menggunakan Floyd-Steinberg yang dimodifikasi untuk penanganan warna yang lebih baik.

Saya percaya, bahwa dithering akan selalu meningkatkan ukuran file karena sifatnya yang acak.
Satu-satunya tujuan fitur ini — untuk memanjakan mata kita.
Dithering dapat disembunyikan di bawah bendera, seperti di Ps. Pengguna akan memutuskan.

Saya pikir kita perlu beberapa dithering yang ramah kompresi. Apakah Anda tahu siapa saja yang bisa membantu kami?

Saya pikir, kita bisa bertanya pada @kornelski.

Maksud saya, saya membuat tiga versi gambar:

  • A: 50 warna: 15 kB
  • B: 50 warna + Dithering: 23 kB
  • C: 100 warna: 22 kB

B tampak sebagus C, tetapi sedikit lebih besar, jadi saya pikir membiarkan lebih banyak warna lebih baik daripada dithering (keduanya meningkatkan ukuran file).

Saya pikir kita perlu dithering, yang terdiri dari beberapa pola berulang, yaitu harus "bersahabat" dengan algoritma Deflate - membuat B hanya memiliki 20 kB (jadi masih sebaik C, tetapi lebih kecil).

OMONG-OMONG. Saya juga berpikir, bahwa pngquant melakukan Deflate yang lebih baik (yang juga membutuhkan waktu sekitar 100x lebih lama daripada UPNG.js: misalnya 30ms vs. 3000ms), sehingga dapat membuat B hanya memiliki 20 kB, saat menggunakan dithering yang sama seperti yang saya lakukan.

Oh begitu.
Saya tidak tahu algoritma dithering, yang bisa menangani kasus ini.

pngquant menghitung kesalahan mse, memiliki pengaturan kualitas min dan max dan jangan menulis file jika ukurannya terlalu besar atau kualitasnya menurun secara dramatis.

Mungkin Anda menemukan utas ini bermanfaat
https://encode.ru/threads/1757-Lossy-DEFLATE-lossy-PNG

Dan proyek ini khususnya
https://github.com/foobaz/lossypng

Ya, pngquant menghitung kesalahan kuadrat rata-rata, dan menerapkan dithering hanya di area dengan kesalahan tinggi. Dengan cara ini area yang tidak perlu dithering tidak mendapatkan kebisingan tambahan.

pngquant juga melakukan deteksi tepi (mirip dengan algoritma Prewitt) dan menonaktifkan dithering di tepi. Ini mencegah anti-aliasing terlihat seperti bulu.

Dalam pngquant, 90% waktu dihabiskan untuk menjalankan K-means ekstra. Jika Anda menggunakan --speed 10 seluruh rekompresi (pada i7 2.3Ghz) membutuhkan ~80 md dithered, 50 md tanpa dithering.

(BTW, TinyPNG tidak memiliki algoritme sendiri. Ini hanya GUI untuk pngquant).

Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

HRK44 picture HRK44  ·  9Komentar

mn4367 picture mn4367  ·  16Komentar

MartinMuzatko picture MartinMuzatko  ·  6Komentar

scrubs picture scrubs  ·  3Komentar

akshaysrin picture akshaysrin  ·  3Komentar