Jak przekształcić sygnał wideo PAL na cyfrowe dane 600x800?

Witajcie,
Ostatnio zacząłem bawić sie analizą obrazu i mam takie pytanie:
W jaki sposób mogę przekształcić typowy sygnał wideo (np. taki z kamer) w cyfrowe dane np. 600 na 800 Tak aby można było analizować poszczególne piksele z obrazu. Raczej wolałbym użyć jakiegoś szybkiego przetwornika A/C niżeli komputera.
Z tego co wiem to system PAL to 625linii na klatkę x 25 klatek na sekundę. Czyli linie pojawiają się z częstotliwością 15,625 kHz. Gdyby każda linia miała składać się z ok 600 pikseli (po 8 bitów na każdy) to częstotliwość próbkowania przetwornika musiałaby wynosić ok 9,4MHz.
Znajdę taki przetwornik i mikro kontroler który to przechwyci?
Pozostaje jeszcze kwestia pamięci do buforowania tego na czas analizy obrazu.
Co Wy na to?
Dla przykładu podaje przykładową ramkę PAL:


A może istnieją gotowe układy do tego celu?

Pozdrawiam

tda8703

Oczywiście że istnieją gotowe ADC, które dekodują sygnały PAL/NTSC/SECAM. Najczęściej nazywane są jako Video Decodery. Na wyjściu przeważnie wypuszczają próbki w standardzie YCrCb 4:2:2, choć są i takie, które wypluwają RGB. Produkuje je dużo firm, m.in. Analog Devices (np. układ ADV7180), NXP, STM, TI, Averlogic i pewnie wiele innych .

Z przetwornikami do analizy sygnału wideo jest taki problem że jeśli sygnał pojedynczych linii nie jest zsynchronizowany z taktowaniem przetwornika to będzie objawiać się to tym że pojedyncze linie będą drgać o jeden piksel względem siebie. Dlatego stosuje się układy framegrabberów które samodzielnie synchronizują się z sygnałem wideo, posiadają układy wewnętrznych liczników i bufor pamięci.

Co do mikrokontrolera natomiast, to raczej będzie ciężko. Zrobienie tego w całości programowo raczej mija się z celem. Można by użyć jakiegoś mikrokontrolera z wbudowanym kontrolerem DMA, ale takim, który obsługiwał by transmisję równoległą na pinach I/O. Jeszcze się z takim nie spotkałem.
Innym rozwiązaniem jest budowa, lub użycie gotowego zewnętrznego kontrolera DMA i zewnętrznej pamięci. Przetwornik A/C łączy się z kontrolerem, a ten z kolei połączony jest z pamięcią RAM i mikrokontrolerem. Zasada jest taka, że dane z przetwornika kopiowane są cyklicznie do uprzednio wybranego stałego obszaru pamięci, do którego za pośrednictwem kontrolera DMA ma również dostęp mikrokontroler. Żeby jednak taki układ działał poprawnie, konieczne było by dodanie jakiegoś układu synchronizacji z sygnałem wizyjnym, tak, aby zapis do pamięci zaczynał się zawsze wtedy, gdy zaczyna się ramka obrazu.
Taki kontroler DMA / pamięci da się wykonać na jakimś układzie FPGA. Jako pamięć można wykorzystać DRAM, bo tańszy, nawet zwykłe SIMMy ze starych x86.

Zdaje mi się, że kiedyś widziałem projekt takiego kontrolera zrobionego właśnie specjalnie do przechwytywania sygnału wizyjnego, znaleźć go próbowałem, niestety bez rezultatu.

Jest jeszcze jedna metoda, mniej toporna niż połączenie mikrokontrolera i przetwornika bezpośrednio - połączenie ich za pośrednictwem kolejki (pamięć FIFO), ale raz, że takie pamięci sporo kosztują i nie są łatwo dostępne, a dwa - mimo wszystko całą transmisję trzeba obsługiwać programowo, a jak nie całą, to przynajmniej jej część i wszystkie, nawet aktualnie niepotrzebne dane w ten, czy inny sposób przetwarzać.

elektryk napisał:

Z przetwornikami do analizy sygnału wideo jest taki problem że jeśli sygnał pojedynczych linii nie jest zsynchronizowany z taktowaniem przetwornika to będzie objawiać się to tym że pojedyncze linie będą drgać o jeden piksel względem siebie. Dlatego stosuje się układy framegrabberów które samodzielnie synchronizują się z sygnałem wideo, posiadają układy wewnętrznych liczników i bufor pamięci.

Można użyć układów 'telewizyjnych' do wyodrębnienia impulsów synchronizacji H i V. Takie impulsy mogą służyć do sterowania A/C taktowanego szybkim sygnałem (kilka-kilkanaście taktów na teoretyczny pixel). Potem przy obróbce można uśredniać sąsiednie pixele jednocześnie skalując ekran do 800pix. Fakt faktem że takie urządzenie nie ma sensu przy istnieniu gotowych procesorów wizyjnych. Na pewno obróbka obrazu 12MB/s (25klatek po 800x600) będzie problemem. Problemem będzie również obsługa i dekodowanie kolorów.

jest jeszcze inna wazna sprawa, mianowicie jaki sygnal chcesz przechwutywac? W systemie PAL przechwycenie luminancji to "pryszcz" odpowiada za nia poziom sygnalu (z pewnym ale o czym dalej). Tak wiec przechwycenie obrazow "czarno-bialych" (niezaleznie czy w sygnale jest kolor czy go niema) da sie zrobic z tym ze wymagana predkosc bedzie blizej 25*625*833 (format 4:3) = ok. 13MHz. Natomiast jezeli chodzi o kolor to nie jst tak wesolo. Kolor w systemie PAL jest kodowany za pomoca sygnalu zmiennego nalozonego na luminancje a konkretnie jesgo faza - na poczatku kazdej linii wywylany jest tak zwanu color burst jako sygnal odniesienia i na dodatek co jeden (o ile pamietam) polobraz faza tego sygnalu jes obracana (stad nazwa systemu Phase Alternating Line). Generalnie jest to niezle zakrecone i raczej ciezkie do wykombinowania na piechote . Lepiej uzyc gotowej kosci ktora to zalatwi.