Cara Mengubah Bingkai Video yang Diekstrak menjadi GIF yang Bagus

Mengapa GIF salah pada tahap ekstraksi

Sebagian besar GIF buruk ditentukan sebelum perangkat lunak GIF apa pun dibuka. Seseorang mengekstrak setiap frame dari klip berdurasi lima detik, mendapatkan 150 gambar, menyusunnya, dan mendapatkan file berukuran 14 MB yang ditolak oleh aplikasi obrolan untuk disematkan. Nalurinya kemudian adalah mengompres lebih keras, yang membuatnya berlumpur tanpa membuatnya lebih kecil.

Masalah sebenarnya ada di hulu. GIF bukanlah codec video — GIF tidak memiliki kompensasi gerakan, tidak ada prediksi antar-frame yang sesuai dengan namanya, dan batasan maksimum 256 warna per frame. Setiap bingkai dekat dengan gambar yang berdiri sendiri. Fakta tunggal tersebut mendorong setiap keputusan di bawah ini.

Jadi urutan yang perlu dipikirkan adalah: tentukan jumlah frame terlebih dahulu, palet kedua, dan baru kemudian memikirkan tentang kompresi.

Langkah 1: Pilih interval pengambilan sampel

Pertanyaannya bukan "berapa banyak frame yang dimiliki sumber" namun "berapa banyak yang sebenarnya dibutuhkan oleh gerakan". Beberapa titik awal yang kasar:

• 10–12 fps — pengaturan yang sangat sulit. Cukup halus untuk gestur, demo UI, dan sebagian besar klip reaksi. Pada sumber 30 fps, yaitu setiap frame ke-3; pada 60 fps, setiap tanggal 5.
• 15 fps — untuk gerakan berkelanjutan saat 12 mulai menyala, seperti gerakan kamera atau objek yang memantul.
• 5–8 fps — untuk konten seperti slide: bagan yang terbentuk, sebelum/sesudah, zoom lambat. Seringkali terlihat disengaja, bukannya murahan.
• 24+ fps — jarang sepadan. Ukuran file kira-kira berlipat ganda dibandingkan 12 fps dan sebagian besar pemirsa tidak dapat membedakannya dalam gambar berulang yang kecil.

Dalam ekstraksi bingkai, gunakan mode "Frame Rate (FPS)" dan masukkan pembagi: 3 untuk setiap frame ketiga, 5 untuk setiap frame kelima. Jumlah bingkai diperbarui saat Anda mengetik, yang merupakan angka yang sebenarnya memprediksi ukuran file Anda.

Langkah 2: Buat durasinya singkat

GIF tidak memiliki kasus penggunaan jangka panjang. Dua hingga empat detik mencakup hampir semua hal yang berfungsi sebagai perulangan, dan titik perulangan lebih penting daripada panjangnya: klip yang berakhir di dekat titik awal akan terbaca sebagai kontinu, sedangkan klip yang memotong di tengah gerakan akan menarik perhatian ke jahitan setiap pengulangan.

Gunakan penggeser rentang waktu untuk memangkas sebelum mengekstraksi, bukan menghapus bingkai setelahnya. Stempel waktu terlihat saat Anda menyeret, sehingga Anda dapat mendaratkan titik keluar pada pose yang sama dengan titik masuk.

Langkah 3: Pahami batas 256 warna

Ini adalah kendala yang mengejutkan orang, dan perlu dipahami daripada diperjuangkan.

Setiap bingkai GIF diindeks ke dalam palet dengan maksimal 256 warna. Video sumber Anda memiliki jutaan. Sesuatu harus menghilangkan perbedaannya, dan cara melakukannya akan menentukan tampilan hasilnya.

Dua strategi, dan strategi yang benar bergantung sepenuhnya pada konten:

• Dithering menyebarkan piksel warna palet yang berdekatan untuk memalsukan piksel yang hilang. Gradien — langit, pencahayaan lembut, bayangan pada wajah — bertahan jauh lebih baik dengannya. Biayanya adalah pola bintik yang terlihat dan file yang jauh lebih besar, karena kebisingan tersebut mengalahkan kompresi.
• Tak perlu ragu memberikan area warna yang datar dan bersih serta file yang jauh lebih kecil. Ideal untuk perekaman layar, demo UI, seni garis, apa pun dengan wilayah seragam yang luas. Pada gradien fotografi, ini menghasilkan garis garis keras.

Aturan praktis: konten layar, tanpa gangguan. Rekaman kamera, ragu-ragu. Jika Anda tidak yakin, ekspor keduanya dan lihat ukuran sebenarnya — perbedaannya terlihat jelas dan memerlukan waktu beberapa menit.

Ini juga alasan mengapa mengekstrak ke PNG adalah keputusan yang tepat meskipun GIF akhir memiliki 256 warna. Setiap artefak JPEG di sumbernya menjadi warna yang harus dimasukkan oleh palet. Memasukkan bingkai yang bersih dan tidak hilang ke dalam langkah palet akan memberikan kuantiser titik awal yang lebih baik.

Langkah 4: Cocokkan penundaan frame dengan interval yang Anda ekstrak

GIF tidak menyimpan kecepatan bingkai. Mereka menyimpan penundaan per frame, dalam seperseratus detik — dan di sinilah banyak GIF yang akhirnya diputar dengan kecepatan yang salah.

Aritmatikanya sederhana: penundaan = 100 fps target Anda.

• 12 fps → penundaan 8 (0,08 detik)
• 10 fps → penundaan 10 (0,10 detik)
• 15 fps → penundaan 7 (dibulatkan ke 6,67)
• 5 fps → penundaan 20 (0,20 detik)

Dua hal yang perlu diketahui. Pertama, pembulatannya nyata: 15 fps tidak dapat dinyatakan secara tepat, sehingga loopnya sedikit menyimpang. Untuk segala hal yang memerlukan pengaturan waktu, pilihlah 10, 12,5, 20, atau 25 fps, yang membaginya dengan rapi. Kedua, sebagian besar browser secara diam-diam membatasi penundaan di bawah 2 (0,02 detik) hingga 10 — jadi GIF yang dibuat dengan kecepatan 50 fps akan diputar pada kecepatan 10 fps untuk sebagian besar pemirsa, dengan ukuran lima kali lipat dari ukuran file dan tidak ada kehalusan apa pun.

Langkah 5: Potong ukurannya, sesuai urutan yang sesuai

Jika file masih terlalu besar, terapkan ini secara berurutan. Masing-masing gambar memiliki kualitas per byte yang disimpan lebih rendah dibandingkan gambar setelahnya.

1. Kurangi dimensinya. Mengurangi separuh lebar hingga seperempat jumlah piksel. GIF dengan lebar 480 piksel cocok untuk sebagian besar konteks penyematan; 800+ jarang diperlukan.
2. Lepaskan bingkai. Beralih dari 15 ke 10 fps akan menghilangkan sepertiga data, sehingga sebagian besar pemirsa tidak akan menyadarinya.
3. Persingkat klipnya. Tanpa ampun. Hampir setiap GIF memiliki detik di awal atau akhir tanpa melakukan apa pun.
4. Kurangi palet di bawah 256. 128 atau bahkan 64 warna adalah sering kali tidak terlihat pada konten layar dan jauh lebih kecil.
5. Matikan dithering jika Anda mengaktifkannya dan konten dapat menerimanya.

Perhatikan bahwa "kompres lebih keras" tidak ada dalam daftar. Kompresi GIF adalah LZW lossless — tidak ada putaran kualitas. Yang bisa Anda lakukan hanyalah mengambil keputusan tentang data apa yang akan disertakan.

Saat Anda tidak boleh membuat GIF sama sekali

Harus dijelaskan dengan jelas, karena menghemat banyak tenaga:

• Apa pun yang berdurasi sekitar lima detik. MP4 atau WebM akan berukuran lebih kecil dengan kualitas lebih baik. Sebagian besar platform yang menerima "GIF" kini tetap mengonversinya menjadi video secara internal.
• Konten fotografi dengan banyak gradien. 256 warna saja tidak cukup, dan tidak ada tipu daya palet memperbaikinya.
• Apa pun yang memerlukan audio. GIF tidak memiliki apa pun, dan perulangan akan terasa salah jika sumbernya memiliki irama.
• Apa pun yang lebarnya di atas 800 piksel. Pada saat itu, penalti ukuran cukup parah sehingga video adalah jawaban yang tepat.

GIF mendapatkan tempatnya tepat dalam satu situasi: loop pendek, senyap, dan diputar otomatis yang harus berfungsi di mana saja tanpa pemutar. Oleh karena itu, GIF masih belum terkalahkan — asalkan frame yang masuk dipilih secara sengaja.

Contoh yang berhasil

Misalnya Anda menginginkan GIF dari sebuah GIF interaksi UI tiga detik dari rekaman layar 60 fps, di bawah 1 MB.

1. Trim hingga 3,2 detik yang berisi interaksi, dengan frame terakhir mendekati frame pertama.
2. Ekstrak dalam mode FPS dengan N = 5 — setiap frame kelima pada 60 fps menghasilkan 12 fps, sekitar 38 frame. Keluaran PNG.
3. Rakit pada penundaan 8, ragu-ragu (ini adalah konten layar dengan warna datar).
4. Skala hingga lebar 600 piksel jika sumbernya lebih besar.
5. Periksa hasilnya. Sekitar 38 bingkai konten UI datar biasanya berukuran kurang dari 1 MB. Jika tidak, turunkan palet menjadi 128 warna sebelum menyentuh warna lainnya.

Semuanya memerlukan waktu beberapa menit, dan setiap langkah adalah keputusan yang Anda buat, bukan keputusan bawaan yang Anda warisi.