· 5 min read

Bagaimana cara kerja GIFs animasi - Dari Bingkai Kanvas ke Kompresi LZW

Format GIF berusia 39 tahun dan masih di mana-mana. Inilah yang terjadi antara mengklik 'Ekspor' dan mengambil berkas - pengambilan bingkai, kuantisasi warna, kompresi LZW, dan mengapa PP1X Anda adalah 4MB.

Mengapa GIFs Masih Ada

The Graphics Interchange Format diciptakan oleh Compuserve pada tahun 1987 [CompuServe, 1987]. Ini mendukung animasi, transparansi, dan kompresi lossless. Terbatas pada 256 warna per frame. Tidak ada audio. Ini menghasilkan file besar. Dengan setiap ukuran teknis, seharusnya diganti puluhan tahun yang lalu.

Namun: Discord, Slack, iMessage, Twitter, Reddit, dan email semua dukungan GIFs native. GIPHY melayani lebih dari 10 miliar GIFs per hari [GIPHY, 2020]. Format ini tetap ada karena bekerja di mana-mana, tidak memerlukan codec, dan bermain secara otomatis. Tidak ada format lain yang memiliki kombinasi dukungan universal dan memutar zero- gesekan.

Memahami bagaimana kerja GIFs sangat berguna di luar trivia - itu menjelaskan mengapa Anda diekspor GIF adalah 4MB, mengapa gradien terlihat banded, dan apa yang dapat Anda lakukan.

Step 1: Frame Capture

GIF animasi adalah urutan gambar (frame) yang ditampilkan dalam rangka dengan penundaan antara masing-masing. Untuk membuat satu dari animasi kanvas, Anda perlu menangkap kondisi kanvas pada interval reguler.

Dalam peramban, ini berarti membaca data pixel dari elemen HTML <canvas> pada setiap waktu frame - biasanya melalui canvas.toDataURL() atau ctx.getImageData(). Animasi ini dikembangkan ke waktu target, kanvas dirender, dan piksel ditangkap. Batas kunci: Anda harus menunggu siklus cat peramban (requestAnimationFrame) sebelum membaca piksel, atau Anda menangkap buffer yang basi.

GIF khas di 15 FPS selama 3 detik memerlukan 45 frame captures. Pada 1080 × 1080 resolusi, setiap frame adalah sekitar 4,7 juta piksel.

Langkah 2: Kuantisasi Warna

GIF mendukung maksimal 256 warna per frame, disimpan dalam tabel warna (palet). Sebuah bingkai kanvas khas memiliki ribuan warna yang berbeda. Mengurangi 256 tanpa terlihat degradasi adalah bagian tersulit dari pengkodean PP1X.

Pendekatan standar adalah * * median cut algoritma * * [Heckbert, 1982]: mengurutkan semua piksel dengan saluran termerah mereka, membagi daftar di median, ulangi untuk ruang warna hijau dan biru, secara rekursif membagi ruang ke 256 daerah. Rata-rata wilayah menjadi entri palet. Ini adalah apa yang Gif.js - perpustakaan PinePaper gunakan - penerapan dalam Pekerja Web untuk paralel [Rubaxa, gif.js].

Kuantisasi warna adalah mengapa GIFs menangani grafis warna datar dengan baik tapi berjuang dengan foto dan gradien. Gradien di 1080 piksel mungkin menggunakan 500 + warna yang berbeda. Kompres ke 256 menghasilkan banding yang terlihat - langkah diskrit di mana gradien harus halus.

      • What you can do about it: * * Gunakan sedikit warna dalam desain Anda. Bentuk datar, isi padat, dan kuantisasi teks dengan baik. Gradasi halus dan tekstur fotografi tidak. Jika GIF Anda memiliki banding, menyederhanakan palet, bukan resolusi.

Langkah 3: Kompresi LZW

Setiap bentuk pixel (referensi ke palet 256-color) dikompresi dengan * * Lempel-Ziv-Welch * (LZW) kompresi [Welch, 1984]. LZW membangun kamus urutan byte berulang karena memindai data. Ketika bertemu urutan yang telah dilihat sebelumnya, itu mengeluarkan indeks kamus bukan byte mentah.

Ini berarti kompresi GIF paling efektif ketika ada luas warna berulang - latar belakang padat, bentuk datar, teks pada permukaan seragam. Tekstur kompleks dengan variasi tingkat pixel menghasilkan rasio kompresi yang buruk karena kamus LZW menemukan beberapa urutan berulang.

    • Implikasi praktis: * * A 1080 × 1080 GIF of white text on a black background might compress to 200KB. Resolusi yang sama PP1X dari sebuah foto kompleks mungkin 8MB. Ukuran berkas lebih tergantung pada kompleksitas visual daripada pada resolusi atau jumlah frame.

Langkah 4: Frame Disposal dan Optimisasi

GIF frame dapat menspesifikasikan sebuah * * metoda pembuangan * *: apakah akan membersihkan kanvas sebelum menggambar frame berikutnya, meninggalkan frame sebelumnya terlihat, atau mengembalikan ke Latar belakang. Smart PP1X encoders menggunakan * * frame diferencing * * - pengkodean hanya piksel yang berubah antara frame, bukan seluruh frame.

Bila animasi Anda memiliki latar belakang statis dengan elemen kecil yang bergerak, GIF teroptimasi mengkodekan latar belakang sekali dan hanya memutakhirkan wilayah di mana elemen bergerak. Ini secara dramatis mengurangi ukuran berkas. Enkoder PinePaper menggunakan gif.js yang menerapkan optimasi ini secara otomatis.

Nomor

Untuk animasi PinePaper yang khas (1080 × 1080, 15 FPS, 3 detik, latar belakang gelap dengan teks animasi):

Komponen Ukuran
Frame mentah (45 × 4.7M piksel × 3 bytes) ~634 MB
Setelah kuantisasi (256 warna, 1 byte / piksel) ~211 MB
Setelah kompresi LZW ~2-4 MB
Dengan perbedaan frame ~1-2 MB

Rasio kompresi dari raw ke final adalah sekitar 300: 1 sampai 600: 1. Sebagian besar berasal dari kuantisasi warna (3: 1) dan LZW (50: 1 sampai 100: 1).

Kapan akan menggunakan GIF vs Other Formats

Format Terbaik untuk Batas
GIF Dukungan universal, otomatis-play, aplikasi pesan 256 warna, berkas besar, tidak ada audio
WebM (VP9) Kualitas terbaik, file terkecil, web Dukungan terbatas dalam Safari, iMessage
MP4 (H.264) Media sosial, pemutar video Memerlukan codec, tidak ada transparansi
APNG Animasi warna penuh dengan transparansi Dukungan terbatas dalam browser tua

GIF adalah pilihan yang tepat ketika Anda memerlukan kompatibilitas universal dan otomatis. Untuk kualitas atau ukuran berkas, WebM atau MP4 lebih baik.

Cobalah

Buka [PinePaper Studio] (/editor), buat sebuah desain, dan ekspor sebagai GIF. Perhatikan bagaimana ukuran berkas berubah sebagai Anda:

  • Tingkatkan jumlah frame (lebih banyak frame = berkas lebih besar, proporsional)
  • Tambah gradiasi (kuantisasi miskin = berkas yang lebih besar)
  • Gunakan warna padat (kuantisasi yang baik = berkas yang lebih kecil)
  • Tingkatkan ukuran kanvas (lebih piksel per frame = berkas yang lebih besar)

Setiap perubahan adalah pengukuran pipa kompresi. Anda tidak hanya membuat GIF - Anda mengamati bagaimana teori informasi berlaku untuk desain Anda.

Referensi

  • Compuserve (1987). Grafis Interchange Format Spesifikasi, Versi 87a.
  • GIPHY (2020). Laporan Tahunan GIPHY: 10 Milyar Daily Serves.
  • Heckbert, P. (1982). Kuantisasi Gambar Warna untuk Tampilan Penyangga Frame. * Grafik Komputer (SIGGRAPH) *, 16 (3), 297- 307.
  • Rubaxa. gif.js - JavaScript GIF encoder menggunakan Pekerja Web. github.com / jnordberg / gif.js.
  • Welch, T.A. (1984). Teknik untuk kompresi Data Tingkat Tinggi.

Ekspor GIF di GIF gratis - tidak ada watermark, tidak ada tanda tangan. Buka [pinepaper.studio / editor] (/editor) dan ekspor animasi pertama Anda.

Ready to create?

Start making animated GIFs, videos, and graphics — free, no signup.

Open PinePaper Editor