gif

• (ks. graphics interchange format).. compuserve'un buldugu ve zamaninda cok populer olmu$ resim dosyasi formati.. kullandigi lzw compression sayesinde (bkz: lzw) zamaninin en ufak resim dosyalariydilar. gunumuzde de hala web'de animated ve transparent atraksiyonlar ichin kullanilmaktadir.
• animasyonlu olan türü de mevcuttur. (bkz: animated gifi optimize etmeyi becerememek)
• http://www.gif.com/
• patent sahibi unisys'in hak iddia etmesi sonucu programlarda kullanımı muallakta olan, en kısa sürede yerini png'ye bırakmasını dilediğimiz arkaik bir resim formatı...
• the compuserve graphics interchange format ,indexleme yontemini kullanarak resmin boyutunu kuculten formattir.
• hollandaca zehir.
• yapisi geregi sanki 256.000 renk gibi olan format. sanki...
  bu arada, kompresyonu olmayan bir ortamdir.
• aslında animasyonlu ve animasyonsuz olarak iki yaygın formata verilen ortak isim. animasyon desteklemeyen gif87, destekleyen ise gif89 formatıdır.
• yazı gibi düzgün tanımlanmamış kenarları olan şekiller ve düz renkli alanlar içeren resimler için en iyisi gif formatını kullanmaktır.
• bir resim gif olabilmek için yaklaşık şu şekilde sıkışır:
  
  elimizde bir resim olsun. sallayalım hemen bişeyler:
  
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  (255,0,0)(255,0,255)(255,0,255)(255,0,255)(0,0,255)
  
  şimdi bu resim 5 x 6 x (2^8) = 7680 bit kadar yer kaplar.
  
  ama biz basit bi indeksleme sistemi geliştirelim hemen:
  
  255,0,0,1
  255,0,255,2
  0,0,255,3
  
  yani her renge bir numara verdik. bu indeks dosyası 9 x (2^8) + 3 x (2^2) = 2304 + 12 = 2316 bit yer kaplar.
  
  buna göre resmi de şöyle yazarız:
  
  12223
  12223
  12223
  12223
  12223
  
  ancak bu dosyayı haufmann koda sokucaz. hesaplayıp bulmuyorum şimdi ama şöyle olur:
  2 = 1
  1 = 01
  3 = 00
  
  yani 2 bir bit; 1 ve 3 de ikişer bit yer kaplar. o zaman resmin asıl dosyası 38 bit yer kaplar. bu indeks dosyası da 1, 2 ve 3'e byte dersek 30 bit civarı bir yer kaplar.
  
  toplamda
  2316 + 38 + 30 = 2384 bit. ilk dosyamız 7680 bitti. demek ki veri kaybetmeden 3 kattan biraz daha fazla sıkıştırdık dosyayı. ki çok az veri olduğundan indeks tablolarımız asıl tablomuzdan büyük oldu. gördüğünüz gibi asıl resim bilgisini tuttuğumuz dosyayı 7680 bitten 38 bit'e indirdik. aslında index tablolarımız çok küçük olmalıydı ki resim büyüdükçe index tablolarımızda az bir büyüme olacakken resim tablomuzda çk bir büyüme olacak. asıl resim büyüdükçe, sıkıştırma oranı da bol bol artacak. hele bir de biraz kalite kaybetmeyi göze alırsak 10-20 kata kadar kaliteli sıkıştırmalar sağlayabiliriz, üstelik kodunu da kendimiz yazabiliriz.
  
  bilgiye doymamak için edit: normalde haufmann algoritması önceden veri sıklığının hesaplanmasına ve bu sıklığa göre yüzdeleri belirleyerek verileri kodlamaya dayanır. gif dosyaları oluşturulurken ise önceden bu hesabı önceden yaparak değil, bir yandan hesap yapıp bir yandan veri kodlarını oluşturan şeker gibi bir algoritma kullanılır.
  
  peki bu azıcık veri kaybı dediğimiz olay nasıl olacak? burada oturup kendi kendimize diyoruz ki: "ulan senin gözün ne kulağın ne ki milyon tane rengi algılıycan da milyon tane frekansı duyucan?" ve ne yapıyoruz? evet, dosyadan insan kulağının ve gözünün algılayamayacağı ölçüde veri atıyoruz ve bu bize inanılmaz sıkıştırmalar sağlayabiliyor. siz (167,189,149), (166,189,149), (167,190,149), (167,189,148) arasındaki farkı anlayabilir misiniz?