>Natomiast co do TV 2ⁿ·50Hz:
> >najprostszy panel PAL dostaje update TFT w takt ramki, czyli każdy
> >pixel musi utrzymać jasność 1/25s. To jest łatwe, ale taki pixel jest
> >dość powolny. Jak go zrobić szybszym, trzeba zwiększyć częstotliwość
> >odświeżania, czyli np. zrobić pełne 50Hz (każde pole odświeża
> >wszystkie pixele).
> Ale pixel przez 1/25s pozostaje ten sam wiec o jakim odwiezaniu piszesz?
Pixel TFT nie trzyma wartości wiecznie. Jak projektujesz układ siedzący w pixelu (te trzy tranzystory z ich pojemnościami), to czas pomiędzy kolejnymi odświeżeniami wartości jest pierwszym parametrem: z niego wynika, jaka musi być pojemność "pamiętająca" w pixelu, aby do następnego jej przeładowania zachowała napięcie bliskie początkowemu. Im dłużej taki pixel musi czekać na nową wartość, tym więcej ładunku musi mieścić.
Nie wnikając bliżej w detale, jeśli pixel utrzymuje obraz przez czas t, to ma "poświatę" rzędu powiedzmy 3*t. Jeśli t = czas ramki, to mamy problem smużenia. Jeśli wsadzić t = 1/4 czasu ramki to mamy problem rozwiazany, ale musimy 4 razy po drodze do pixela "zapisać" na nowo wartość, czyli 200Hz dla TV.
>Z kolei wyjechanie na 200+Hz (4 update'y między kolejnymi polami)
> >pozwala zrealizować (sensownie) cyfrowo "overdrive", czyli jak z
> >pixela czarnego ma się zrobić 50% szary szybko, to w pierwszym
> >odświeżeniu dostanie on 75% szarego, aby zainicjować szybciej zmianę,
> >a potem docelową wartość
> Ale takie prymitywne stopniowanie da w efekcie smuzenie - nie wiem czy
> widoczne przy 200hz, ale przy 50 na pewno tak.
Dlaczego smużenie? To właśnie minimalizuje smużenie, bo wykorzystuje krótkie "przestrzelenie" ponad wartość docelową, żeby szybciej "odwrócić" pixel.
Kiedys tłumaczyłem to koledze (motorowodniakowi) tak: Łódź ma sporą bezwładność. Jak chcesz ją zatrzymać na możliwie krótkim odcinku dajesz na chwilę całą wstecz. Jak dobrze sterujesz, to w ten sposób krypa nie zawróci, tylko się szybciej zatrzyma.
Marek