Sıkıştırma, Kodlayıcılar ve Kutulaşma sorunu…

Bu yazıda daha önce başlamış olduğum DSLR kullanıcılarının görüntü kalitesi açısından en çok sorun yaşadığı ve anlaması gereken temel kavramlar/sorunlar dizisine devam edeceğim. Sayısal video ile uğraşanların önlerine çıkan en tipik belalar, düşük veri oranı, yüksek gürültü oranı ve son olarak da sıkıştırma sorunlarıdır. İlk konuda veri oranı, ikinci konuda da gürültü kavramlarını ele almıştık. Bu yazıda ise konumuz sayısal video alanında kullanılan sıkıştırma işlemi (compression), bu iş için kullanılan kodlayıcılar (codecs) ve bu noktada ortaya çıkan kutulaşma bozuklukları (macroblocking). Amacım, hem kayıt alırken, hem sonrasında çekilmiş görüntü üzerinde işlem yaparken, hem de en sonda çıktı alırken karşımıza çıkabilecek durumları gözden geçirmek ve genel bir fikir oluşturabilmek.

İlk iki yazıda Cin örnekleri vermiştik. Bu yazıda da biraz zorlama da olsa aynı benzetmeyi devam ettirmeye çalışacağım. İlk iki cini tekrarlamaya gerek yok. İkisinden de aynı sonuç çıkmıştı: Işık azaldıkça başımız belada. Biz bunlarla uğraşırken birde önünüze fırlayan üçüncü cin, size bazı ek koşullar dayatıyor.

Sen, 14. kutudan başlayıp geriye doğru her kutuda misketlerinle yazı yazıp ilerlerken, ben bitirdiğin kutuya şöyle bir bakıp içeriğini aklımda tutacağım. Sen 13. kutuyu bitirince ben onun başına geçip sadece ve sadece 14. kutudaki misketlerden farklı yerlerdeki misketleri bırakıp, aynı yerde duran tüm misketleri alıp cebime atacağım. Böylece, sadece “farklardan oluşan” bir 13. kutu ortaya çıkacak ve tek başına bir anlamı olmayacak. 13. kutuda çok az misket kalmış olacak ama daha sonra önce 14. kutuya, sonra da 13. kutuya bakanlar kafalarında 13. kutunun tam halini oluşturabilecekler. Elbette, 13. kutuyu anlayabilmek için 14. kutuyu bilmek zorunlu olacak çünkü 13. kutu sadece ve sadece “fark misketlerinden” oluşmuş olacak. “Neden?” diye sorabilirsin. Birincisi, misketlerin olabildiği kadarını geri almamız lazım, ikincisi her kutuya binlerce yüzlerce misket kullanarak yazı yazılmaz. Bir kutuya tam yazarsın, arkasından gelenlerde ise sadece (varsa) farklı kısımları yazarsın. Böylece misketten ve yerden tasarruf yapacağız…

Şimdi işler biraz değişti. Artık biz yazı yazarken, cinlerin biri rastgele renkli gürültü misketleri ekleyecek, bir diğeri de her kutunun bir önceki kutudan farkını tutup misketlerin gerisini cebine atacak. Evet, aşağı yukarı sıkıştırma dediğimiz olay budur. Bir veri kümesi bir kez “tam” olarak elde edilir, bunu takip eden kısımlar ise sadece ve sadece bu tam kümeden olan farkları gösterirler. İster zip, ister rar ister h.264, ister mpeg4 olsun, tüm sıkıştırma algoritmaları aşağı yukarı benzer bir mantık üzerinde ilerler: Aynılar atılır, farklılar yazılır. Tekrar okunma gerektiğinde de önce tam küme okunur, sonra üzerine farklar eklenir. Sıkıştırma olmaksızın ne internet, ne veri iletişimi ne de sayısal teknoloji bugünkü konumunda olabilirdi. Cep telefonuyla konuşurken sesimizi taşıyan sinyale dahi sıkıştırma uygulanır.

Bu cin konusuna geri döneceğim ama öncelikle kısaca bir kamera algılayıcısında neler olur, bizim videolarımız nasıl yakalanır ve kodlanır gibi konuların teknik altyapısına biraz değinmek istiyorum.  Canınızı sıkarsa aşağıdaki 3. Cin başlıklı noktaya atlayıp okumaya devam edebilirsiniz.

Sahip olduğunuz kamerayı bir tarafından hammadde giren, diğer tarafından bitmiş ürün çıkan bir fabrikaya benzetebilirsiniz. Bakalım fabrikanın içindeki her üretim aşamasında neler oluyor.

Kameranın algılayıcısı üzerine düşen ışığı elektrik sinyaline çevirir ve bu analog sinyali sayısal sinyale dönüştürmek için özel bir devreye gönderir. Bu devreden çıkan veri miktarı inanılmaz derecede büyüktür. Hemen Canon APS-C algılayıcısını örnek alalım.

apsc

Matematikle bir şey anlatmayı hiç ama hiç sevmediğim halde basit aritmetik işlemler dışına çıkmadan bir fikir vermeye çalışacağım. Boyutu 22,20 mm x 14,80 mm olan bu algılayıcı RAW modunda 5184 x 3456 boyutunda fotoğraflar çekiyor. Yani üzerinde 17.915.904 tane piksel varmış ki yuvarlak 18 megapiksel diyoruz. Daha önce açıkladığımız gibi bu algılayıcı 14 bitlik değerler atıyor. Yani fotoğraf çekerken, her tek piksele 16.384 ayrı değer verilebiliyor. Toplam ne kadar veri ediyor yani diye bu rakamları bir kez daha çarpınca ortaya 293.534.171.136 bit veri çıkıyor. Yani algılayıcı yakaladığı tek karede 300 milyar bite  yakın veri elde ediyor. Bu da 286.654.464 Kb ediyor ki bu da 279.936 Mb ediyor. Yani aslında tek karedeki veri miktarı 280 megabyte‘a yakın. Oysa kart üzerindeki dosyaya bakıyorum: 21.266 Kb yani 21 Mb’nin biraz üzerinde. Şimdi biz ham yani RAW formatı sıkıştırmasız diye biliyorduk, oysa rakamlar yalan söylemez. Algılayıcı 280 Mb göndermiş ama karta 21 Mb yazılmış. Bunun nedeni, algılayıcı üzerindeki her pikselin tek tek bağımsız kaydedilmemesi. Bazı pikseller sadece mavi, bazıları sadece kırmızı ve bazıları da sadece yeşil rengi algılarlar ve resim bu üçünün bir şekilde biraraya getirilmesiyle ortaya çıkar. Neyse fotoğrafı geçelim ama şu aklımızda kalsın: Algılayıcı yüzeyi bir seferinde 280Mb veri yakalar.

Peki video çekmek istediğimizde ne olur? Saniyede 25 kare (PAL) video çekimi yapıyorsak, bu algılayıcı 25 x 280 Mb = 7000Mb yani saniyede yaklaşık 7 Gigabyte veri yakalar demektir. Bu hızda sürekli veri yakalama ve yazma yapabilen sistemler ancak çok özel sistemlerdir ve genelde askeri ya da uzay teknolojisi gibi alanlarda kullanılırlar. 10 saniyelik çekimin 70 Gigabyte tuttuğunu düşünsenize. 1 dakikalık çekim ise 4,2 TB tutacaktır. Bilgisayarınızdaki toplam harddisk kapasitesi nedir diye bir düşünün.

Şimdi elbette burada bir hata var. Biz 18 megapiksellik bir algılayıcıyı saniyede 25 kare yakaladık. Oysa tam yüksek çözünürlük (HD) görüntü 1920 x 1080 boyutundadır. Yani HD aslında 2.073.600 piksel, yani 2 megapikseldir. İşte bu noktada bizim algılayıcı bize birinci ihanetini yapar: 18 megapiksellik yüzeyi 2 megapiksele indirmek (downresolution / downrez) için her iki satırından birini atar. Yani en üstteki 1. satırını okur, 2. ve 3. satırları okumaz. 4. satırı okur, 5 ve 6’yı okumaz vb. Böylece 5184 yerine önce 1728 satıra iner ardından da bunu 1920’ye çıkarır (upresolution / uprez). Dikeyde de durum benzerdir; 3456 kolondan 1080 elde edilir. Bu satır atma (line-skipping) olayı Canon kameraların başındaki en büyük beladır. Çünkü atılan satırlara denk gelen yerlerdeki veri kaybedilmiş olur ve bunlar alias dediğimiz bela olarak çıkar. Olsun diyelim, sonuçta yine de tatmin edici bir görüntü var elimizde. Burada yapılan henüz sıkıştırma değil; resmen veriyi atma.

Şimdi, karede 2 megapiksel x 25 kare ile veri yakalayacağız. Bu noktada kamera ikinci ve  belki de daha büyük ihanetini yapar: 14 bit yerine bunu 8 bitlik bir altyapıyı gözeterek kodlar. Yani her bir piksele 16,384 ayrı değer yerine sadece 256 ayrı değer atar. Peki, toplam veri ne olur? Saniyede 25 kare x 2 Mb veri x 256 = 12.800 MB eder. Yani yuvarlak saniyede 12,5 GB veri akışı olur. Bu miktar, şu budanmış, kırpılmış haliyle bile son derece yüksek bir veridir. Demek ki, tam HD video çeksek, 1 dakikalık çekim 60 x 12,5 = 750 GB edecektir. Dakikası 750 GB çekim olmaz, olursa yer yetmez.

3. Cin

İşte bu noktada üçüncü cinimize yani sıkıştırmaya iş düşer. Başta söylediğimiz gibi, sıkıştırma sürecinde bu cin peşpeşe gelen kareleri değişik şekilde işleyerek görev yapar. En tipik yöntem GOP (group of pictures) yaklaşımıdır. Cin, şöyle çalışır: 1. kareyi tam kaydeder (i-frame), 2. karede sadece 1. kareden olan farklar kaydedilir (p-frame), 3.karede 2.’den olan farklar kaydedilir vb taa ki yeni bir tam kareye, yani yeni bir i-frame’e dek. Bu tam kareler ve arkalarından onları takip eden “fark kareleri” bir grup oluşturur ve buna GOP denir. Örneğin Canon kameralarda standart ayarlarda GOP 15’tir ve bu iki tam kare arasında 14 fark karesi var anlamına gelir. Yani çoğumuz video çekerken saniyede 25 kare yakaladığımızı sanıyor olabiliriz ama aslında o 25 karenin sıralaması şöyle olmaktadır:

Resimdeki kırmızılar tam kareleri (i-frame), maviler fark karelerini (p-frame) göstermektedir.

gop15b

GOP rakamı büyüdükçe (long-GOP), tam karelerin arası açılır, sıkıştırma artar, dosya boyutu düşer, kalite de düşer. Burada kutucuklanma (macroblocks) dediğimiz durum ortaya çıkabiliyor. Peşpeşe olan iki kare arasındaki fark büyükse, veri oranı yetersizliği nedeniyle bazen bu fark tam yansıtılamıyor. Bu sorun, özellikle yüksek hareketli görüntü içeriği olan sahnelerde ortaya çıkar. Peşpeşe gelen iki kare arasında o kadar çok fark vardır ki ve elde de onları yazmaya yetecek o kadar az veri vardır ki, ayrıntılar kaydedilemez. Ani değişiklikleri yazmaya veri yetmez ve görüntüde sıkıştırma algoritmasının işini bitiremediğini gösteren kutucuklar çıkar. Akan su, dalgalı deniz, sallanan yapraklı ağaçlar vb gibi sürekli değişiklik içeren görüntüleri çekmek bu nedenle zordur.

macrobloacks

Öte yandan, GOP azalırsa (short-GOP), tam kareler birbirine yaklaşır, sıkıştırma azalır, dosya boyutu büyür, kalite artar, makrobloklar yok olur.

Aşağıdaki resim GOP3lük yani short-GOP bir sıkıştırmayı gösteriyor. Kırmızılar tam kare (i-frame), yeşiller fark kareleridir.

gop3b

Aşağıdaki karelerden üstte olanı GOP15 ile çekilmiş olduğu için suda bulanık bir görünüm ortaya çıkmış ve yer yer kutucuklanma görülmekte. Alttaki ise GOP3 ile ve yüksek veri oranı ile çekilmiş bir videodan alınmıştır ve su daha akışkan olarak kaydedilmiştir.

gh2macros

En baştan söyleyelim; isterseniz bu cini işin en başından devre dışı bırakabilirsiniz. Yani, “O zaman, ben sıkıştırma istemiyorum. Videomdaki her kare, tam ve eksiksiz olsun” diyebilirsiniz ama bedeli korkunç büyüklükteki video dosyaları olacaktır. Yine de ısrarlıysanız, söyleyelim istediğinizin adı Tam-İçerikli Kodlamadır ve bunu yapan işleme de Tam-İçerikli Kodlayıcı (Intra Codec) diyoruz. Bazen ALL-I codec bazen de GOP1 codec dendiği de olur. Yani intra kodlamada saniyede yakalanan 25 karenin her biri bağımsızdır. İçerikleri tamdır ve herhangi bir karenin içeriğini belirlemek için bir diğer kareye gereksinim yoktur. Özetle: kareler arasında sıkıştırma yapılmaz. Cin, iş yapmaz.

Günümüzde bazı kameralar intra kodlama özelliği ile geliyorlar. Örneğin Panasonic’in AVC-Intra 50 ve AVC-Intra 100 dediği iki ayrı kodlayıcısı var. Aslında, Intra kodlama da sıkıştırmasız değildir. Her kare bağımsızdır ama her karenin kendi içinde jpeg türünden bazı sıkıştırmalar yapılabilir. Panasonic kodlayıcıların adlarındaki 50 ve 100 rakamları da bunu gösteriyor. Aşağıda Panasonic kamera ile alınmış bir videonun kare kare dökümünü görüyorsunuz. Kırmızı renkle gösterilenler I-frame dediğimiz bağımsız tek kareler. Gördüğünüz gibi tüm video boyunca karelerin hepsi i-framelerden oluşuyor.

allicodec

Burada biraz ara verip, Panasonic GH2 kameranın hacklenmiş intra görüntülerinden oluşan bir videoyu izleyelim. Tam HD olarak izleyiniz.

Standardı GOP15 gibi uzun bir değer olan Canon üzerinde ise bu noktayı iyileştirme amaçlı iki ayrı çalışma var:

RAW kodlama: Aslında, düşük çözünürlükte raw modunda seri fotoğraf çekip sonra bunları birleştirerek video oluşturma yöntemi. Böylece, Canon’un standart h.264 kodlayıcısı kullanılmıyor. GOP 15’ten kurtulmuş oluyoruz çünkü her karemiz birer raw foto artık. Raw yüzünden dinamik derinlik yüksek ve görüntü kalitesi çok iyi ama 550D ve 600D gibi kameralarda bu modu kullanırsanız yetersiz yazma hızı nedeniyle çözünürlük neredeyse 0,5 ila 0,7 megapiksele düştüğü için ben tatmin olamadım bir türlü. Yani, çözünürlükten ciddi kayıp var. Bir de fotoğrafları dönüştürme ve video yapma işlemi anlamayana biraz karmaşık ve zorlu gelebilir. Ayrıca 600D gibi kameralarda kısa süreli çekimler yapılabiliyor. Bu video klip vb türünden çekimler için işe yarayabilir ama diğer tür çekimler için 500D ve 600D için sınır bu. 5D Mk iii, 650D ve 700D ile 6D gibi kameralar daha büyük gelecek vaadediyorlar bu noktada ama iş hala emekleme aşamasında. Aşağıdaki video 5D ii Mark iii ile RAW çekilmiş.

Bu ise 550D ile.

Bu da 7D ile raw çekim.

Unutulmamalı ki burada verdiğim örnekler bizzat Vimeo ve YouTube sıkıştırmasından geçtikleri için aslında intra değiller ve gerçek kaliteyi görebilmek için kaynak dosyaları indirmeniz gerek. İzlediğiniz görüntülerde web sıkıştırmasından kaynaklı kutulaşmalar görülebilir.

Diğer yöntem ise, Magic Lantern’in kardeşi Tragic Lantern ve daha çok 600D ve 550D üzerine odaklanmış bir uygulama. Burada bir dizi Raw foto çekip sonra video yapmak yerine doğrudan Canon’un standart kodlayıcısı h.264 üzerinde değişiklik yaparak yüksek veri oranlarına ulaşmaya çalışıyor. Kodlayıcı ayarlarını GOP1 olarak belirleyince intra video elde etmiş oluyoruz. Bu yaklaşım elbette h.264 kodlayıcısının varoluş nedenine aykırı, çünkü h.264 aslında daha önceki mpeg kodlayıcılara kıyasla kalite kaybı olmadan çok sıkıştırma yapabilen bir kodlayıcı. Bu türden bir çekim inanılmaz güzel sonuçlar veriyor, çünkü kareler birbirinden bağımsız ve video akışı muhteşem. Bilgisayarda montaj/efekt çalışması yaparken de sistemler çok hızlı çalışıyor. Eksileri ise; sıkıştırmanın çok az olması (tek kare içi ile sınırlı) nedeniyle dosya boyutları çok büyük ve bu büyüklükteki dosyaları sürekli olarak karta yazmaya eski makineler yine bazen yetişemiyor. Yeni kuşak makinelerde bu konuda ümit yine daha fazla. Ek olarak, h.264 kodlayıcısı biraz ayrıntısı düşük ve yumuşak (soft) resimler ürettiği için keskinlik raw kadar yüksek değil.

Bu 600D ile Tragic Lantern

Yine 600D ve TL. Bu videolarda gördüğünüz kutucuklanmalar yine esasen Youtube’un işidir.

Yani her ikisi de teknik olarak GOP1 olan bu iki yaklaşım arasından, raw tercih ederseniz dinamik derinlikten ve keskinlikten kazanıyorsunuz. TL seçerseniz çözünürlük daha yüksek oluyor ve işlemleri raw’a göre daha kolay. Hemen söyleyelim; her ikisinde de kayıt anında ses alınmıyor yani sessiz kayıt yapmak durumundasınız. Ses açılınca işlemciye yük bindiği için kayıt kopuyor. Öyleyse, harici ses kayıt ile işlem yapmak zorunlu. Ayrıca her ikisinde de son derece hızlı kartlara sahip olmanız gerek. Standart Class 10 kartlar yeterli olmuyor ve en az 45Mb/s, hatta 90Mb/s’lik kartlar gerekli.

Bu intra veya GOP1 seçeneği çok zorlu gelirse bunlardan bir adım daha öteye gidip GOP3 ya da GOP6‘lı alternatifler denenebilir. Çünkü, GOP3 seçince ses kaydı alma olanağı da doğuyor. Bu noktada en iyi seçenek yine Tragic Lantern ve Slice control. Burada kamera belirlediğiniz değerlere göre veri oranını belli durumlarda devamlı değiştiriyor ve tampon belleklerin dolması nedeniyle kaydın düşmesi durumu söz konusu olmuyor.

Özet:

GOP1: Cine, “Her kutuyu olduğu gibi bırak ve hiçbir şey eksiltme” demek.

GOP3: Cine, “1. kutuyu incele, 2. ve 3. kutulara sadece farkları koy; Fazla misketler al senin olsun” demek.

GOP6: Cine, “1. kutuyu incele, 2, 3, 4 ve 5. kutulara sadece farkları koy; Böylece daha fazla misket arttı sana bak” demek.

GOP15: Eh, artık anlaşılmıştır. Diğerleri yanında kameraların standart kodlayıcılarının ne kadar kısıtlı olduğu görülebilir.

Kişisel görüşüm, Canon üzerinde GOP3’ün en iyi dengeyi sağladığı ve intra olmaksızın da son derece kaliteli görüntüler elde edilebileceği. Elimde 600D var ve raw ve dual iso teknikleri ile en fazla 209 kare kayıt yapabiliyorum ki bu da 8sn’nin biraz üstü demek. Hem bu süre sınırlaması, hem de bilgisayar başında çok çetrefilli işler çıkardıkları için raw, dual iso ve GOP1’e biraz uzağım ve bunu sadece Panasonic üzerinde kullanmayı düşünüyorum. Kaldı ki GOP1 olayı kartları da zorluyor ve hatta adım adım ölüme götürüyor. Çok kaliteli kartlarınız yoksa zor.

Panasonic kullanıcıları ise uygun kartları varsa, Driftwood’un GOP1 Moon T7 (24p’de 130-147Mbps, 25p’de 80Mbps) seçebilirler. Bu hack ile çekilmiş bir video:

GOP3 olarak ise Driftwood’un Spizz ya da kişisel tercihim olan LPowell’ın Flowmotion 2.02 (24p’de 100 Mbps, Turbo modunda 145 Mbps) kullanılabilir. Flowmotion normal Class 10 kartlarda dahi çok iyi sonuç veriyor ve bugüne dek pek kilitlendiğini görmedim.

GH2 ve Flowmotion

http://vimeo.com/55007889

Sıkıştırma konusu tek bir yazıda ele alınamayacak kadar geniş. Bu noktaya kadar sıkıştırma kavramının temel yapısını özetleyip, sıkıştırmasız ve az sıkıştırmalı çekim seçeneklerini sunduk. Günümüzde yeni kameralar sıkıştırmasız, kayıpsız sıkıştırmalı ve kayıplı sıkıştırmalı seçenekleri ile geliyorlar artık. Yine de, amacımız daha çok amatörlerin çalışmalarına yardımcı olmak ve kalitelerini yükseltmelerini sağlamak olduğu için, erişilemeyecek alternatiflere pek değinmeyeceğiz.

Bu yazıda yine “Nasıl?” sorusuna cevap vermedik farkettiyseniz. Bu bahsedilen uygulamaları tek tek ve kontrollü koşullarda test edip kullanımlarını anlatma planları mevcut. Bunun için de biraz zaman gerekli. Ayrıca, ancak bize vereceğiniz tepki ve destek çerçevesinde bu türden çalışmalara devam edebiliriz. Hangi kamera için ne türlü sorunlar yaşanmakta, şu anda dek anılan konuların hangilerinin uygulamasını öğrenmek istersiniz gibi konuları sizlerden öğrenebilirsek bu noktadan sonraki konularımız da kabaca belli olmuş olur.

Bir sonraki yazıda görüşmek üzere.

Reklamlar

Sıkıştırma, Kodlayıcılar ve Kutulaşma sorunu…” için 10 yorum

    1. GOP mantığı video dosyası için geçerlidir. Eğer sinema filminden kastınız sinema salonunda projeksiyon edilen 35mm film ise zaten GOP ile açıklayamayız. Her kare tek bağımsız analog karedir.

      Öte yandan video şeklinde projeksiyon edilecekse bu çok önemli değil. Görüntünün içeriğinde hareket bol ise o zaman olabildiğince düşük GOP (3 ya da 1) tercih edilebilir. Öte yandan sakin içerik için ise GOP15 bile kurtarabilir. Farkeden dosya boyutu olacaktır.

      GOP açıklaması daha çok çekim aşaması ile ilgili yani gösterim değil. Üzerinde ince çalışma yapılacak (yeşil perde ya da camera tracking vb) çekimler için olabildiğince GOP1’e yakın olmak daha yerinde olur. GOP1 ile çalıştıkan sonra da içeriğe göre çıktı alınan dosyanın GOP’u belirlenebilir.

      Teşekkürler ve saygılar…

  1. Hocam merhabalar.

    Şu sıralar bitrate, sıkıştırma meseleleri ile ilgili okumalar yapıyorum. Anlamadığımı itiraf etmek durumundayım. Daha bilinçli hareket edebilmek ve neyi neden yaptığımı bilmek için işin sayısal ve teknolojik kısmını anlamak istiyorum.

    Öncelikle şu paragrafınıza değinmek istiyorum:
    ”Matematikle bir şey anlatmayı hiç ama hiç sevmediğim halde basit aritmetik işlemler dışına çıkmadan bir fikir vermeye çalışacağım. Boyutu 22,20 mm x 14,80 mm olan bu algılayıcı RAW modunda 5184 x 3456 boyutunda fotoğraflar çekiyor. Yani üzerinde 17.915.904 tane piksel varmış ki yuvarlak 18 megapiksel diyoruz. Daha önce açıkladığımız gibi bu algılayıcı 14 bitlik değerler atıyor. Yani fotoğraf çekerken, her tek piksele 16.384 ayrı değer verilebiliyor. Toplam ne kadar veri ediyor yani diye bu rakamları bir kez daha çarpınca ortaya 293.534.171.136 bit veri çıkıyor. Yani algılayıcı yakaladığı tek karede 300 milyar bite yakın veri elde ediyor. Bu da 286.654.464 Kb ediyor ki bu da 279.936 Mb ediyor. Yani aslında tek karedeki veri miktarı 280 megabyte‘a yakın. Oysa kart üzerindeki dosyaya bakıyorum: 21.266 Kb yani 21 Mb’nin biraz üzerinde. Şimdi biz ham yani RAW formatı sıkıştırmasız diye biliyorduk, oysa rakamlar yalan söylemez. Algılayıcı 280 Mb göndermiş ama karta 21 Mb yazılmış. Bunun nedeni, algılayıcı üzerindeki her pikselin tek tek bağımsız kaydedilmemesi. Bazı pikseller sadece mavi, bazıları sadece kırmızı ve bazıları da sadece yeşil rengi algılarlar ve resim bu üçünün bir şekilde biraraya getirilmesiyle ortaya çıkar. Neyse fotoğrafı geçelim ama şu aklımızda kalsın: Algılayıcı yüzeyi bir seferinde 280Mb veri yakalar.”

    Algılayıcı 14 bitlik değerler atıyor dedik, yani şu şöyle mi oluyor: 1 veya 0’dan birini seçiyor. Sonra yine bunu yapıyor ve bu şekilde devam ediyor. 2x2x2x2x2…=2 üzerine 14 kadar farklı sonuç çıkabiliyor ortaya. Ve atanan değer bunlardan sadece bir tanesi. O da diyelim ki 10101000101011 olsun. Peki bu sıfır ve birlerden oluşan dizginin görsel olarak karşılığı rengin ta kendisi midir? On dört tane boyayı karıştırdık ve ortaya bir renk derinliği mi çıkardık? Yoksa ben olayı çok yanlış mı anlamışım? Bit dediğimiz sayısal verinin görsel olarak sonucu nedir? Bit bir sayısal bilgi. Bu bilgi de video ürettiğimiz için renk derinliği mi olur? bir gamut? Ayrıca son olarak iki ile çarpıp 300 milyar bite yakın bir değer buldunuz, niye iki ile çarptık?

    Bunun dışında aşağıda fotoğraflarını paylaştığım sayısal video kodlamaları hakkında biraz bilgi verir misiniz? 4:2:2, 4:1:1, 4:2:0 gibi kodlamalarda nasıl bir mantık izleniyor?



    Son olarak bayer filtreli algılayıcı ve üç yongalı model. Bunlar hakkında da biraz bilgi rica edeceğim.

    Blain Brown – Sinematografi kitabını okuyorum ancak başlıklar çok yüzeysel geçiliyor gibime geliyor ya da olaya çok yabancıyım. Bu yüzden size danışmak istedim.

    1. Bunlara tek tek cevap yazmak çok uzun sürer. İşin teknik kısmıyla ilgiliyseniz elbette önemli şeyler ama film ya da video çekecekseniz bunları ayrıntılı bilmenize gerek yok aslında.

      Bit meselesini çok karıştırmayın derim. Aynı analog değeri sayısal ifade etmek için elinizde ne kadar geniş bir bit aralığı varsa o kadar iyidir diye bilmek yeter. 8 bitlik sistemde atanabilecek sayısal değer sayısı 256 iken 10 bitte 4096’ya, 14 bitte 16384’e çıkar. Yani birinde elinizde 6 renkli pastel boya seti varken diğerinde 24 renkli tam set var gibi. Bu nedenle aynı renk aralığını çok daha ince ve ayrıntılı üretebilmek söz konusu. Verilen değerler RGB türünden bir değerlendirme sistemi ile bir renk ya da renk tonuna denk gelirler. Birinde 6 ana renk diğerinde 256 ana renk var demek yeterli. Bit sadece rakamdır. Bu rakam kullanılan renk yelpazesi (gamut diyelim) içinde bir aralığı temsil eder. Bilgisayar ya da yazılım bu verilen değerin hangi gamuta göre hangi rengi üreteceğini bilir. Yani sensör kodlar ve dosyaya koyar, yazılım ise bunu okuyup tekrar üretip ekranda bize gösterir. Sensörün yakaladığı tüm veriyi alamayız ve zaten gerek de yok. Ne kadarını azaltalım tartışması bu. İnsan gözü renkteki küçük değişimlere karşı çok hassas değil. bu nedenle renkten taviz veriyoruz. Parlaklıktaki (brightness) değişimlere ise daha hassas ve o nedenle onu olduğu kadar aynı tutmaya çalışıyoruz. O rakamlardaki ilk 4 parlaklık değeridir ve değişmez. Yani her noktaya gelen parlaklık değeri neyse kullanılan bitrate üzerinden aynen kodlanır. 4:4:4 dediğimiz de hiçbir şey azaltılmamış halidir, yani parlaklık ve renk atılmamıştır ama bu kullanılmayan bir format çünkü çok veri var. 4:2:2 dediğimiz renkteki her iki pikselden birinin değerinin atılması yani dosyaya girmemesi demek. 1 nolu pikselin değeri tam alınır, 2 silinir, 3 tam alınır vb. Sonra yazılım o aradaki olmayan 2. pikseli (1+3)/2 şeklinde ortalama ile kendi üretir ve bize gösterir. 4 kareden oluşan bir piksel kümesini de benzeri bir ortalama ile tek piksel ile temsil edebilirsin. Bu durumda sadece 1 piksel tam renk kaydedilir, diğer 3 piksel ise ortalama ile üretilir vb vb. Veri düşer ama renk hassasiyeti de düşer. O rakamlar bu kullanılan azaltma ve ortalama alma sistemini anlatıyor. 8 bitlik sistemlerde 4:2:0 esas. Yani parlaklık tam, renkler ise 4’te bir oranında kullanılıyor. Bu nedenle de renk oynaması vb yaptığımızda bozukluklar oluşuyor çünkü bazı piksellerin değeri gerçek değer değil çevresindeki gerçeklerden üretilmiş sanal değer.

      Bayer filtreli modelde her piksel sadece bir renge atanır. Yani sensörün önüne bir renkli filtre konur ve bir nokta sadece kırmızı görürken yanındaki yeşil, diğeri mavi görür. Bu görüntü kaybına yol açar çünkü ideali her pikselin kendine gelen baskın rengi görmesidir. Yani düz mavi gökyüzünü çekiyorsanız aslında her noktanın mavinin bir tonunu göndermesi gerekirken sadece 3 noktadan biri mavi tonu gönderir, komşuları ise o mavi rengin kırmızı ya da yeşil filtreden geçmiş halini gönderir. Yeşil doğa çekimi yaparken de benzeri olur. Bu Bayer sistemi. Bunun sınırlarını aşmak için 3 ana rengin her birine ayrı bir sensör kullanan 3 çipli sistem var. Bunda her sensör sadece bir renge göre görüyor. Biri tamamen kırmızı, diğeri tamamen yeşil, diğeri tamamen mavi filtre ile görüyor. Sonra bir algoritma ile bu 3 ayrı resim bir araya getiriliyor. Bu daha başarılı bir sistem.

      Diğerleri hakkında daha sonra yazayım.

  2. Nihai amacım film çekmek. Fakat detaylı olmasa da bazı şeyleri bilmek isterim.

    Şimdi ben biraz daha bakındım ve şöyle bir sonuca vardım:

    4:4:4 her bir dört pikselde parlaklık ve renkler tamdır.
    4:2:2 her bir dört pikselde parlaklık tam ancak renkler ( kırmızı ve mavi) bir piksel atlamalı ( mesela 1. ve 3.ye) konumlandırılmış.
    4:1:1 her bir dört pikselde parlaklık tam ancak renkler bu dört pikselden sadece bir tanesine yerleştirilmiş.
    4:2:0 her dört pikselde parlaklık tam ama renklerden sadece biri (misal kırmızı) bu dört pikselden ikisine yerleştirilmiş. Kullanılmayan diğer renk (mavi) bir alt satırdaki piksellerde kullanılarak telafi edilmiş.

    Sanırım buradaki dört önemli bir rakam değil. Bu sekiz de olabilirdi on altı da. Durumu basitleştirmek için dört üzerinden gidilmiş. Sekiz olsaydı hiçbir şey değişmeyecek sadece 8:4:4 gibi ifadeler kullanacaktık. Yanılmıyorum, değil mi?

    Burada mantık hangi pksellere hangi düzende renk ya da parlaklık bilgisi atandığı. Peki RGB diyoruz, o zaman yeşil nerede? Yeşilin her pikselde zaten olduğu ve bunun belirtilmediği hususunda bazı yazılar okudum, bunu doğrulayabilir misiniz?

    Bit konusunu daha iyi anlamış bulunmaktayım. Biz RGB üzerinden cevapladık soruları daha çok. Siyah-Beyaz’a değinmedik. 8 bit için konuşacak olursak 256 farklı değer elde etmiş oluyoruz. Bunlardan bildiğimiz gibi 0 siyah, 255 beyaz. Ara değerler gri tonları. RGB’ de 3 farklı renk olduğu için 2 üzeri (8×3) olması gerekmiyor mu? Bu kısmını biraz karıştırdım.

    Cevaplarınız için teşekkürler.

    1. Ayrıca çekilen videolarda ben bu bilgilere nasıl ulaşabilirim? Videonun kaç bit ile çekildiğini, hangi renk kodlamasının kullanıldığını vs.?

    2. Rakamlar hakkında söylediklerin tamamen doğru. Parlaklığa ek olarak RGB’deki her bir renk için 8 bit yani 256 ton kullanılıyor.

      Yeşilin belirtilmemesi sadece TV yayınında kullanılan YUV formatında geçerli. Yayın için bant genişliği tasarrufu çok önemli. Bu nedenle R ve B aktarılır, G ise bu iki renk ve parlaklığın bir araya gelmesinin bir formülünden türetilir. Kastedilen o olsa gerek. Yoksa RGB formatında G mevcuttur. Kolay gelsin.

  3. Hocam işler yine karıştı. Bu konuda tekrar tekrar rahatsızlık vermek istemem, bu sebeple sormam gerekiyor. 🙂

    Elimizde bir piksel var diyelim. Bu pikselin parlaklığını belirlemek için 8 bitlik bir değer atadık. Renkli çektiğimizi varsayıyorum ve RGB olarakta her bir renk için 8 bit değer atadık. Bu durumda toplamda bir piksele 4 farklı 8 bitlik değer mi verilmiş olunuyor? Parlaklık için, kırmızı, yeşil ve mavi için? Bunu da cevaplandırırsanız rahat etmiş olacağım. Zaman ayırdığınız için tekrar teşekkürler.

    1. Bir anlamda kafan karışmakta haklı çünküfarklı teknolojiler var ve markalar arasında da farklılık olabilir ama genelde olan luma yani parlaklık ile rengin aynı anda hesaplanmasıdır. Fakat dosyaya ayrı rakamlar olarak girerler. SOnuçta 3 adet 8 bitlik sinyalin ortlamasından luma değeri çıkar. Yani okunan 3 x 8 ama hesapta kullanılan 4 x 8 dersek hallolur herhalde. Her bir piksel hem luma hem de renk sinyali gönderir yani. Bunlardan her biri için evet 8 bit atanır.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap / Değiştir )

Connecting to %s