Grafika komputerowa przyzwyczaiła nas w pewnym sensie do tego, że każdy element obrazu – piksel – przedstawiony jest jako trójka składowych R-G-B, czyli czerwony-zielony-niebieski. Jest to o tyle oczywiste, że z tych trzech kolorów w drodze addytywnego mieszania można stworzyć całą przestrzeń kolorów. Jednak w cyfrowym wideo w ogóle nie znalazło się miejsce dla RGB. Ba, już w standardzie JPEG, przeznaczonym dla zdjęć, zamiast RGB pojawiają się inne literki – YUV. Przestrzenie barw to temat na osobny, obszerny wpis, tutaj skoncentruję się na YUV a w szczególności na pewnej powszechnej i nieodzownej praktyce stosowanej w kodowaniu wideo, określanej jako podpróbkowanie chrominancji (chroma subsampling).
Archiwa tagu: h.264
DCT – fundament kompresji wideo
DCT to skrót od Discrete Cosine Transform – czyli dyskretna transformacja kosinusowa. Jest podstawą wielu koderów obrazu i wideo, przede wszystkim ciągle najszerzej stosowanego kodera do zdjęć JPEG, a ponadto koderów wideo MPEG-1, MPEG-2, VC-1, H.263. Popularny H.264 używa wariantu DCT pod nazwą Integer Transform, czasem zwaną ICT (Integer Cosine Transform). Transformacja ta w skrócie, (podobnie jak inne transformacje, na przykład oparte o falki) pozwala na pewnego rodzaju rozkład obrazu na składowe o „różnym stopniu szczegółowości”. Masło maślane, więc w dalszej części postaram się wyjaśnić o co chodzi z DCT i przy okazji jak działają współczesne kodery obrazu działające wg schematu transformacja ↣ kwantyzacja ↣ kodowanie entropijne. Czytaj dalej DCT – fundament kompresji wideo
Kompensacja ruchu
Większość współczesnych kodeków wideo korzysta z pewnej oczywistej zależności między poszczególnymi klatkami sekwencji wideo. Otóż jeśli kompresowana jest scena w miarę naturalna, to znaczy to co na ekranie ma pewną ciągłość, to klatka obrazu i jej sąsiedzi w ogólności niewiele się od siebie różnią. Zatem nie sposób z tej sytuacji nie skorzystać, aby zwiększyć stopień kompresji bez utraty jakości. Jednak samo dostrzeżenie różnic i wyliczenie prostej różnicy klatek w formie rastra i zakodowanie tej różnicy niczym pojedynczego obrazka tak jak to robi koder JPEG nie jest wystarczająco efektywne. Prosta różnica między sąsiednimi klatkami wprawdzie w części będzie niemal zerowa, jednak dostrzegalne będą wyraźne kontury poruszających się obiektów, które kompresują się nienajlepiej. Gorzej, jeśli to kamera jest w ruchu, wtedy wszystko na ekranie się porusza i prosta rastrowa różnica dwóch sąsiednich klatek jest znaczna. Właśnie po to kodeki wideo stosują mechanizm kompensacji ruchu, który postaram się zilustrować, podpierając się biblioteką OpenCV.