GIF'ten Videoya Dönüşümde Teknik Olarak Ne Değişir?

Bir GIF'i MP4'e çevirdiğinizde dosya on kat küçülüyor ama görüntü neredeyse aynı kalıyor. Bu nasıl mümkün ve dönüşüm sırasında gerçekte ne değişiyor? Bu yazıda iki formatın yapısal farklarını ve dönüşümün her adımında olan biteni açıklıyoruz.

İki farklı animasyon modeli

GIF'te animasyon, birbirini takip eden bağımsız karelerdir. Her karenin:

• Kendi renk paleti olabilir (en fazla 256 giriş)
• Kendi gecikme süresi vardır (1/100 saniye biriminde)
• Kendi konumu ve boyutu olabilir (tam kare değil, kısmi bir dikdörtgen)
• Kendi elden çıkarma yöntemi vardır (bir sonraki kareden önce ne olacağı)

Videoda animasyon, sabit bir zaman ızgarasında dizilmiş karelerdir. Kare hızı genellikle sabittir (25, 30, 60 fps) ve her kare aynı süre gösterilir.

Bu temel model farkı, dönüşümün ilk zorluğunu doğurur.

Zamanlama: değişken gecikmeden sabit kare hızına

Bir GIF'in kare gecikmeleri şöyle olabilir:

Kare 1: 10 (0.10 sn)
Kare 2: 10 (0.10 sn)
Kare 3: 25 (0.25 sn)  ← duraklama
Kare 4: 10 (0.10 sn)
Kare 5:  5 (0.05 sn)  ← hızlı geçiş

Video ise sabit bir kare hızı bekler. Dönüştürücünün seçenekleri:

1. Yeterince yüksek bir kare hızı seçip kareleri tekrarlamak. Yukarıdaki örnekte 20 fps seçilirse (kare başına 0.05 sn), 0.25 saniyelik kare beş kez tekrarlanır. Zamanlama tam korunur ama kare sayısı artar — video kodekleri tekrar eden kareleri çok verimli sıkıştırdığı için bu boyut sorunu yaratmaz.

2. Ortalama bir kare hızı seçip yaklaşıklamak. Daha basit ama zamanlama farkları oluşur.

Çoğu dönüştürücü birinci yolu kullanır. Yine de, GIF'inizin gecikmeleri çok düzensizse hafif bir ritim farkı hissedilebilir.

Bir ayrıntı: bazı çok eski GIF'ler 0 gecikme değeri taşır (mümkün olduğunca hızlı). Tarayıcılar bunu genellikle minimum bir değere yükseltir ve farklı tarayıcılar farklı minimumlar kullanır. Böyle bir GIF'i videoya çevirdiğinizde hız, tarayıcıda gördüğünüzden farklı olabilir.

Kısmi karelerin birleştirilmesi

GIF'te bir kare, önceki karenin üzerine sadece değişen bölgeyi çizen küçük bir dikdörtgen olabilir. Sabit arka planlı bir animasyonda bu ciddi yer kazandırır.

Videoda böyle bir kavram yoktur; her kare tam boyuttadır.

Dönüştürücü, GIF karelerini sırayla birleştirerek (compositing) her kare için tam görüntüyü üretmek zorundadır. Bunun için elden çıkarma yöntemini doğru yorumlaması gerekir:

| Yöntem | Anlamı | |---|---| | Belirtilmemiş | Kare olduğu gibi kalsın | | Koru (Do not dispose) | Kare kalsın, sonraki üzerine çizilsin | | Arka plana dön | Kare bölgesi arka plan rengiyle temizlensin | | Öncekine dön | Kare bölgesi bir önceki hâline dönsün |

Yanlış yorumlama, dönüşümde "hayalet" izler veya birikmiş artıklar olarak görünür. Bu, düzgün yazılmış dönüştürücülerde nadir bir sorundur ama çok eski veya standart dışı GIF'lerde karşınıza çıkabilir.

Renk: palettten tam renge (ama geri dönüşü yok)

GIF'te her piksel, bir palet indeksidir. Dönüşümde bu indeksler gerçek RGB değerlerine çözülür.

Video formatı tam renk (16.7 milyon) destekler, dolayısıyla teknik bir sınır yoktur.

Ama kaynak zaten 256 renge indirilmiş durumdadır. Kaybolan renk bilgisi geri gelmez. Video, o 256 rengi tam renk kapasitesiyle saklar ve sonuç görsel olarak GIF'le aynı görünür.

İlginç bir yan etki: GIF'e dithering uygulanmışsa (renk sınırını gizlemek için kullanılan noktalı desen), bu desen videoya da taşınır. Video kodeği için bu gürültü zorlayıcıdır — kodek gerçek detay sanıp bit harcar. Yeterli bitrate verilmezse dithering deseni bulanıklaşır veya blok bozulmasına yol açar.

Saydamlık: kaybolan özellik

GIF, ikili (binary) saydamlık destekler: bir piksel ya tamamen saydam ya tamamen opaktır. Ara değer yoktur, bu yüzden saydam GIF'lerin kenarları tırtıklı görünür.

Yaygın video kodekleri (H.264, VP9 standart profilleri) alfa kanalı taşımaz. Her piksel opak varsayılır.

Dönüşümde saydam pikseller bir renkle doldurulmak zorundadır — genellikle siyah veya beyaz. Sonuç, GIF'te arkası görünen bölgelerin videoda düz renk olmasıdır.

Saydamlık gerekiyorsa video doğru hedef değildir. Alternatifler:

• Animasyonlu WEBP: 8 bit alfa, iyi sıkıştırma.
• APNG: 8 bit alfa, daha büyük dosya ama geniş destek.

İkisi de GIF'in ikili saydamlığından daha iyidir — 256 saydamlık seviyesiyle yumuşak kenarlar sağlarlar.

Kroma altörnekleme

Bu, dönüşümün en teknik ama en görünür etkilerinden biri.

İnsan gözü parlaklık (luma) değişimlerine, renk (kroma) değişimlerinden çok daha duyarlıdır. Video kodekleri bundan yararlanır: parlaklık bilgisini tam çözünürlükte, renk bilgisini yarı çözünürlükte saklar.

Bu şemaya 4:2:0 denir ve yaygın video kodlamasının varsayılanıdır. Renk bilgisi hem yatayda hem dikeyde yarıya indirilir — yani renk verisinin dörtte biri saklanır.

Fotoğrafik içerikte bu neredeyse görünmez. Ama GIF'lerde sık karşılaşılan içeriklerde fark edilebilir:

• Keskin renkli kenarlar: kırmızı metin beyaz zeminde, kenarlarda hafif bulanıklık.
• İnce çizgiler: renkli arayüz öğeleri yumuşar.
• Küçük metin: okunabilirlik düşebilir.

Bazı kodekler 4:4:4 profilini destekler (renk bilgisi tam çözünürlükte saklanır). Ekran kaydı ve metin içeren animasyonlarda bu belirgin fark yaratır, ama dosya büyür ve uyumluluk daralır.

Çift sayı kısıtı

4:2:0 altörnekleme, renk bilgisini 2×2 piksel bloklarında sakladığı için genişlik ve yüksekliğin çift sayı olmasını gerektirir.

GIF'lerde böyle bir kısıt yoktur; 401×267 gibi ölçüler yaygındır.

Dönüştürücü bunu iki yolla çözer:

• Kırpma: bir piksel sütun/satır atılır (401 → 400).
• Doldurma: bir piksel eklenir (401 → 402), genellikle siyah.

İkisi de görsel olarak fark edilmez ama boyut değişikliği metadata'da görünür.

Sıkıştırma verimliliği: asıl kazanç

Şimdi dosya boyutundaki dramatik farkın sebebine gelelim.

GIF'in araçları:

• LZW kayıpsız sıkıştırma (tekrar eden desen bulur)
• Kısmi kare (değişen dikdörtgen bölge)
• Şeffaf piksel (değişmeyen pikselleri atlama)

Video kodeğinin araçları:

• Hareket tahmini (bir bloğun nereye kaydığını bulur)
• Blok içi tahmin (komşu piksellerden tahmin)
• İki yönlü tahmin (önceki ve sonraki karelere bakma)
• Frekans dönüşümü ve nicemleme (görsel olarak önemsiz detayı atma)
• Değişken blok boyutları
• Entropi kodlaması

Fark kategoriktir. GIF "bu bölge değişti, işte yeni pikseller" der; video kodeği "önceki karedeki şu blok 12 piksel sağa kaydı ve biraz karardı" der.

Buna bir de kayıplı çalışma eklenir: video kodeği, görsel olarak fark edilmeyecek detayları atabilir. GIF'in LZW'si kayıpsızdır ve böyle bir esnekliği yoktur.

Sonuç: aynı içerik için tipik olarak 5-10 kat boyut farkı.

Ne kaybediliyor, ne kazanılıyor

| Konu | GIF | Video sonrası | |---|---|---| | Dosya boyutu | Büyük | 5-10 kat küçük | | Renk çeşitliliği | 256 (sınır) | Tam renk (ama kaynak 256) | | Saydamlık | İkili | Yok | | E-posta desteği | Var | Yok | | Otomatik oynatma | Doğal | Öznitelik gerekir | | Keskin renkli kenar | Tam | Hafif yumuşama (4:2:0) | | Zamanlama esnekliği | Kare başına | Sabit kare hızı |

Özetle

GIF ve video, animasyonu farklı modellerle ele alır: GIF'te her karenin kendi gecikmesi, paleti ve kısmi bölgesi vardır; videoda sabit bir zaman ızgarasında tam kareler bulunur. Dönüşüm, kareleri birleştirip zamanlamayı sabit kare hızına normalleştirir. Renk açısından kayıp yoktur ama kazanç da yoktur — 256 renk sınırı zaten uygulanmıştır. Saydamlık ise kaybolur çünkü yaygın video kodekleri alfa kanalı taşımaz. Kroma altörnekleme keskin renkli kenarlarda hafif bir yumuşama yaratır ve çift sayı kısıtı bir piksellik kırpma gerektirebilir. Buna karşılık kazanç büyüktür: video kodeklerinin hareket tahmini ve kayıplı çalışma yeteneği, aynı içeriği tipik olarak beşte bir ile onda bir arası boyutta saklar.