On Feb 1, 11:05 am, "Ghost" <g...@e...pl> wrote:

> >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