Diskussion:Pixeltakt

Dieser Artikel ist auf diese Weise geschrieben nicht korrekt.

Der Pixeltakt errechnet sich wie folgt: 1s/(D/X), wobei X die horizontal sichtbar darzustellenden Pixel sind. 'D' (wird üblicherweise in µs angegeben und bedeutet frei interpretiert 'Daten') ist ein Wert aus dem Video-Timing und bezeichnet allgemein die allein für die Darstellung von X sichtbaren Pixeln in einer Zeile benötigte Zeit.

Ein grundlegendes Problem bei bisheriger Formel ist, dass die Zeit für den 'Horizontal Blank' nicht mit eingerechnet wird. Damit ergibt sich ein falsches Ergebnis. Ich empfehle dennoch die Formel in abgeänderter Form beizubehalten um zumindest einen circa-Wert auf schnelle Weise berechnen zu können. Man kann die Zeilenfrequenz (natürlich ebenfalls mit etwas Ungenauigkeit) in Zeilen*Bildwiederholrate aufsplitten, etwa so:

Pixeltakt = X * Y * Bildwiederholfrequenz(Hz)

Für VGA kann man noch einen Korrekturfaktor für die entgangenen Sync-Zeiten von ca. 30% einrechnen, also bspw.:

Pixeltakt=X * Y * Hz * 1,3

Damit kann jeder aus der von ihm gewünschten Auflösung und Wiederholfrequenz errechnen, ob die betrachtete Grafikkarte oder der Monitor in Frage kommen. Die vom jeweiligen Hersteller angegebene Videobandbreite sollte dann höher sein, als der errechnete Wert.

Da das Timing-Verhalten nicht proportional zur Auflösung skaliert, ist eine allgemeingültige Formel, zumindest für mich, nicht ersichtlich. Vielleicht kann da noch jemand nach präzisen Quellen suchen. Ansonsten ist erstgenannte Formel genau, wenn auch in der Praxis schlecht benutzbar.

Ich bitte um eure Meinung zum Thema.

Wenn man statt mit den aktiven (=sichtbaren) Zeilen und Pixeln zu rechnen auch die inaktiven mitrechnet ist die Formel einfach X*Y*Bildwiederholfrequenz, oder X*Zeilenfrequenz (wobei X alle horizontalen, inkl. den inaktiven Pixeln ist).

Inaktive Pixel sind Pixel, die für das Sync-Verhalten vom Monitor benötigt werden. Diese Pixel existieren nicht wirklich, müssen aber miteinberechnet werden, um den Pixeltakt zu berechnen. In Wirklichkeit wird zu den Zeitpunkten, wo diese inaktiven Piyeln an den Monitor gesendet weren ein Syncsignal gesendet, das den Elektronenstrahl zurückschickt.

Bei der Auflösung, die ich derzeit eingestellt hab (1792x1344@60Hz) stimmt der Faktor 1,3 nicht mal annähernd: Der Pixeltakt beträgt 205MHz statt 144MHz. Daraus ergibt sich ein faktor von 1,42. Die Brutto-Auflösung (also mit den inaktiven Zeilen und Pixeln) beträgt 2448x1400. Bei 640x480 kommt aber der Faktor 1,3 ca. hin, bei 1024x768 braucht man einen Faktor von 1,36 (jeweils bei einer Bildwiederholfreqenz von 60Hz). -MrBurns 21:56, 8. Apr. 2007 (CEST)

Farbtiefe

Wie mein Vorredner sehe ich das Problem, dass der Pixeltakt so nicht berechnet werden kann. Zusätzlich fehlt die Betrachtung der Farbtiefe, die einen Signifikanten Einfluss auf den Pixeltakt hat. Die aktuell genannte Formel gilt also nur für 24 Bit Farbtiefe.

Um den genauen Pixeltakt zu berechnen, müssen die Blanking Intervalle mit einbezogen werden. Folgende Excel Tabelle generiert die entsprechenden Timings: www.fl-eng.com/_lib/doc/vesa.xls

Für DVI existiert außerdem ein reduced Blanking, was hier Erwähnung finden sollte. Bei HDMI sind die Pixeltakte allerdings nicht mehr nachzuvollziehen, da hier in den Blanking Intervallen ja Audio Pakete übertragen werden können. (nicht signierter Beitrag von 134.147.64.48 (Diskussion) 17:19, 7. Jun. 2011 (CEST))

Nein, der Pixeltakt hat nichts mit der Farbtiefe zu tun, diese beeinflusst lediglich bei digitaler Übertragung die Bitrate und damit auch die Frequenz des Taktsignals mit der die Informationen übertragen werden, aber das ist nicht der Pixeltaktm, der Pixeltakt ist wie viele Pixel (aktive und inaktive) pro Sekunde dargestellt werden. Bei analoger Übertragung hingegen ist die Farbtiefe des Signals unendlich und Bitrate undefiniert und der Takt, mit dem das Signal übertragen wird, entspricht dem Pixeltakt, da es ja für jeden Subpixel ein eigenes Signal gibt (und zusätzlich ein Signal für VSYNC mit der Vertikalfrequenz und eines für HSYNC mit der Horizontalfrequenz, das mit den verscheidenen Signalen gilt natürlich nicht für Composite Video)). --MrBurns (Diskussion) 22:33, 14. Jun. 2012 (CEST)