Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jak odczytać kolor piksela z sygnału video z eurozłącza

19 Cze 2009 12:54 2474 6
  • Poziom 18  
    Tak jak w temacie. Mam potrzebę odczytania przez Atmegę koloru piksea z obrazu pobranego przez eurozłączę. Znalazłem artykuł o generowaniu obrazu video przez mikrokontroler, ale jest to obraz czarno-biały, więc odwracając proces mógłbym odczytać natężenie szarości poszczególnych pikseli a mi potrzeba informacji o składowych RGB. Mak toś artykuł o sposobie przesyłu obrazu kolorowego przez eurozłącze albo dysponuje wiedzą na ten temat?
  • Poziom 33  
    Primo, to po eurozłączu są przesyłane sygnały analogowe, więc nie ma mowy o pikselach. Analogowy sygnał TV dzieli się tylko na linie, zmiana koloru w linii jest płynna.

    Po drugie, eurozłącze to taki kombajn, sygnał TV może tam występować w postaci RGB, Composite Video, czy bodaj nawet z rozdzieleniem luminancji i chrominancji (S-Video). Ale nie w każdym urządzeniu muszą wystąpić wszystkie te formy. Zobacz tu, jak nie wiesz jak wygląda sygnał wideo.

    Nawet zakładając, że masz RGB, to chcąc podzielić linie np. na 320 odcinków ("pikseli"), to masz 52us/320= 162,5ns na odcinek. Znaczy, potrzebny jest bardzo szybki przetwornik A/C. I i tak Atmega jest raczej bez szans - bez specjalizowaych układów nie da rady.

    P.S. Może napisz, co chcesz osiągnąć, to będzie łatwiej stwierdzić, czy da się wymyślić jakąś sztuczkę, czy też potrzebny komputer z kartą telewizyjną.
  • Poziom 18  
    Z tego co piszesz sprawa nie wygląda tak beznadziejnie.
    Po pierwsze co chcę osiągnąć:
    W pracy trochę luźniej więc umyśliłem zrobić sobie coś na kształt ambilight philipsa.

    Znalazłem coś takiego:
    http://www.recenze.okamzite.eu/8-ambilight-podsvetleni-vasi-tv/nemate-ambilight-poridte-si-bandilight/ (można użyć translatora google bo to po czesku), ale wydaje mi się, że można to zrobić prościej.

    Co do sygnału to w tunerze to mam napisane w specyfikacji "eurozłącze RGB" więc chyba ma... ale jeszcze to sprawdzę choćby tym układzikiem:
    http://www.recenze.okamzite.eu/gallery/Ambik1.0nahled.jpg

    Co do szybkości to potrzeba mi powiedzmy około 30 odczytów na linię. Przy czym dane R G B mogą pochodzić z 3 kolejnych(a nawet nie kolejnych) linii.
    Potem może być przerwa na kolejne 30 linii co da czas na resztę programu.
    Przy najmniejszym dzielniku przetwornika i maksymalnym taktowaniu mikrokontrolera powinno dać radę. Nie wiedziałem czy sygnał RGB nie ma przebiegu z 0V między poszczególnymi pikselami, ale z tego co piszesz jest to sygnał ciągły, co ułatwia sprawę bo nie trzeba "celować" z odczytem.
    Nie bardzo mogę się połapać z dokumentacji którą podrzuciłeś czy uda mi się wyciągnąć synchronizację ramki i linii z sygnału RGB, czy będę musiał do tego użyć kanału chociażby luminancji?
    I jeszcze jedno pytanie:) o poziom napięcia na tym RGB czyli 1V dla maksymalnej czerwieni, a 0,3V dla czerni?
  • Poziom 33  
    Ambilight to znacznie prostsze :)

    To czeskie rozwiązanie rzeczywiście wygląda mi na przekomplikowane. Do ambilight-a potrzebujesz zmierzyć średnią wartość kolorów RGB za cały półobraz - tak mi się wydaje.

    Ja bym zrobił to tak, że do pomiaru wykorzystałbym wewnętrzny przetwornik, mierząc w trzech kanałach RGB w czasie wygaszania pionowego.
    Z kolei uśrednianie zrobiłbym analogowo, np. na filtrze RC, oddzielnie w każdym kanale, kluczując szeregowo przychodzący sygnał, najlepiej z procesora, synchronicznie z sygnałami synchronizacji, aby łapało tylko część widoczną obrazu.
    Czyli pomiar raz (a właściwie trzy razy) na 20ms.


    Jeżeli chodzi o dokładne poziomy w volt-ach na eurozłączu, to nie wiem.
  • Poziom 18  
    Myślałem o 8 strefach jak na obrazku:
    Jak odczytać kolor piksela z sygnału video z eurozłącza
    więc analogowe separowanie połówek nie da tu rady.
    Montuję jakiś prototyp i zobaczę jak to wygląda.
    Spróbuję puścić a/d na jakimś szybkim mikrokontrolerze na freerun i zobaczę ile on tam zrobi pomiarów na linii. Tak na prawdę wystarczy 1 pomiar na linię, albo rzadziej (dane można zbierać przecież nawet przez powiedzmy 10 ramek). Cała kwestia to obliczenie z której części linii odczyt pochodzi. Linii jest ponad 500 więc zbierając z każdej linii punkt (przesuwając o kilkadziesiąt cyki pomiar za każdym razem) mamy 500 pomiarów co do uśrednienia zupełnie wystarczy.
    Na razie muszę zbudować prototyp co wykrywa pionową i poziomą synchronizację z luminncji. Potem pobawię się z pomiarami.

    Dodano po 34 [minuty]:

    Tak sobie myślę, że 8 filtrów RC z kluczowaniem z mikrokontrolera na podstawie odczytu ramki też było by ciekawym rozwiązaniem. To co na nich jest nie musiało by być w ogóle czytane przez a/d. Można by to puścić bezpośrednio na tranzystory sterujące diodami jak na schemacie http://www.recenze.okamzite.eu/gallery/Ambik1.0nahled.jpg
  • Poziom 33  
    Chodziło mi o to, że jeżeli zbudujesz uśredniający układ sample-and-hold, to otwierając go tylko np. w czasie obszarów, które zaznaczyłeś, na koniec półobrazu uzyskasz średnią wartość z tych obszarów.
    Ponieważ przetwornik atmegi jest dość wolny, to i tak powinieneś zastosować układ S&H - inaczej na wyjściu będziesz miał dość przypadkowe wyniki.
    Jeżeli będziesz uśredniał tylko 500 punktów (pomiarów) na cały obraz, to IMHO będzie to raczej mało odzwierciedlało średni kolor tegoż.

    --
    Po doczytaniu tego, co dopisałeś... ;)
    Chcesz łącznie dać 8 diód RGB? To byś musiał mieć 24 takie ułady...
  • Poziom 18  
    Co do przypadkowości przy tej ilości odczytów to nie jestem przekonany. Statystyka to mocna rzecz:)
    Trzeba pamiętać że to jest 50 klatek i z każdej będzie kilkaset punktów. Przez sekundę to niesamowita liczba danych o kolorze.
    Generalnie jak się siedzi w cyfrówce to się w człowieku robi taka tendencja, żeby żadnej danej nie stracić i uśrednić cały ekran (w tym przypadku).
    Mnie jednak korci żeby sprawdzić czy ta szybkość przetwornika nie jest wystarczająca. W końcu to tysiące pomiarów na obszar na sekundę.
    Co do tych układów RC to też fajny pomysł, bo generalnie można w ogóle zrezygnować z przetwornika a uśrednianie odbywa się analogowym sposobem (bez strat danych o pikselach). Odpada też sterowanie PWM 24 diod. Tyle, że jak ma się te dane cyfrowo to można jeszcze by pokombinować i np tym brzeżnym dać większą moc niż tym bliżej środka ekranu.
    Tak czy inaczej siadam do prototypu i coś tam powoli w wolnym czasie próbuję więc się dowiemy bo chyba spróbuję oby sposobów.

    p.s.
    24 tranzystory i kondensatory smd to nie tak dużo. Bardziej mnie martwi te 24 (właściwie 25) kable do ramki z diodami...(tych niestety nie da się uniknąć w żadnej wersji.) Co do ilości diód to myślę o 2-3 na każdy segment (telewizor 46 cali).