Diskussion:Framebuffer

farbtiefe mehr als 32-bit

warum entwickeln hardwarehersteller keine grafikkarten mit mehr farbtiefe als 32-bit? ist es möglich auf aktuellen grafikkarten mehr farbtiefe zu erhalten durch veränderung der software? warum machen softwarehersteller das nicht? macht das alles sinn? wenn nein, warum? --77.189.124.147 12:10, 1. Apr. 2010 (CEST)

Weil Menschen so viele Farben ohnehin nicht unterschieden kann (zumindestens die meisten, siehe hier). Bei HDRR wird zwar mit mehr als 32bit gerendert, aber bevor das ganze dann in den Frameebuffer geschrieben wird, wirds auf 32bit runtergerechnet. Es gab aber mal Grafikkarten, die einen Modus unterstützten, bei dem die 32bit anders aufgeteilt waren (jeweils 10bit für jede Farbe + 2 bit für den Alpohakanal, anstatt jeweils 8 bit für jede Farbe und den Alphakanal), dieser Modus wurde jedoch kaum unterstützt und ist soviel ich weiß auch wieder vom Grafikkartenmarkt verschwunden. Natürlich könnte man mehr bits auch nutzen, um den Alphakanal zu vergrößern, bringt aber soviel ich weiß auch nichts, da das menshcliche Auge angeblich ohnehin nur ca. 60 Graustufen unterscheiden kann. Ich habs alllerdings in einem Selbstversuch mit dem Programm eizo-test 9 und auf möglcihst gute Erkennbarkeit veiieler Grauustufen optimierten Monitoreinstellung es geschafft, alle 256 Gaufstufen zu unterschieden (der Testbildschirm bestand aus einem Quadrat, das sich ind er Mitte des Bildschirms befindet und ca. die Hälfte der Bildschirmhöhe einnimmt, sowie einen Hintergrund und einem Regler, mit dem man die Farben für das Quadrat und den Hintergrund beliebig einstellen kann, ich hab den Bildschrima uf möglcihst guete Unterschiedbarkeit von garustufen optimeirt (hat keine 5 minuten gedauert) und dann folgendes verglichen, indem ich immer einen dieser 2 Werte fürs Rechteck und einen fürn hintergrund eingestellt hab und versucht hab, die Grenze zwischen rechteck und Hintergrund zu erkennen, was mir immer gelang. Ich hab folgende Werte probiert: 0/0/0-1/1/1, 254/254/254-255/255/255, sowie einige Zwischenwerte, wobei immer nur eine graustufe dazwischen war). Allerdinsg konnte ich bei Unterschieden von nur einer Graufstufe bis 6/6/6-7/7/7 nurmehr den Umriss des Rechtecks erkennen, aber nichtmehr, ob das Quadrat oder der Hintergrund heller ist, aber bei 0/0/0-2/2/2 war der Helligkeitsunterschied auch shcon duetlich. Also selbst wenn mand as als Bedingung nimmt, konnte ich mindestens 252 Graustufen unterscheiden, mit etwas optimierterer Bildschrimkalibration wären wahrscheinlcih alle 256 drin gewesen. Allerdings braucht amn da wirklich schon 2 sehr große Blöcke, bei echten Fotos oder Spielen kann man möglicherweise wirklich nur 60 Graustuifufen unterscheiden, selbst wenns schwarz-weiß-Fotos sind. --MrBurns 12:55, 1. Apr. 2010 (CEST)

Korrekte Übersetzung?

Ehrlich gesagt, ich bin gegen diese sinnlosen "Gewaltübersetzungen" noch dazu, wenn sie falsch sind, wie in diesem Beispiel: Der Framebuffer (deutsch: „Bildspeicher“) - frame (en) ist korrekterweise mit Rahmen oder Bilderrahmen zu übersetzen. Ich plädiere dafür, solche "Übesetzungen" nach Möglichkeit wegzulassen. - Ernèsto! 13:13, 31. Jan 2006 (CET)

Geht mir ähnlich, nur gibt es auch menschen, die dem englischen nicht mächtig sind. mir ist leider keine treffendere deutsche übersetzung zu framebuffer eingefallen, deswegen hatte ich es eher sinnvoll (hoffte ich jedenfalls) als wörtlich übersetzt. zu deinem vorschlag entsprechende übersetzungen in zukunft zu unterlassen, starte doch einfach mal ein meinungsbild. --Murkel ^(anmurkeln) 11:51, 1. Feb 2006 (CET)

Das wird kaum nötig sein. In Klammern kann ggf. auch eine wortwörtliche deutsche Übersetzung angegeben werden, die aber als solche auch erkennbar sein sollte. An sich kann man meines Erachtens den Framebuffer auch Rahmenpuffer nennen. Ich baue es mal ein. Entsprechende Google-Treffer gibt es auch. Ich baue es mal vorsichtig um. Stern 22:13, 1. Feb 2006 (CET)

Kann vllt mal jemand ergänzen, wofür es den Framebuffer überhaupt gibt? Meines Wissens nach handelt es sich dabei um einen speziellen dual-ported-Speicher, da man gleichzeitig lesen und schreiben muss, was wohl klar sein sollte. Das wurde aber nur mal kurz am Rande einer Vorlesung erwähnt...

Das steht bereits alles in der einleitung. der artikel beschreibt das konzept des framebuffers. für die hardwareseitige umsetzung - also den angesprochenen dual ported memory - siehe Video-RAM oder GDDR oder Halbleiterspeicher.

Der framebuffer ist nur ein bestimmter bereich des gesamten zur verfügung stehenden grafikspeichers. es ist also nicht möglich, einzelne auf der grafikkarte verbaute halbleiterspeicher dem framebuffer zuzuschreiben. wie es bereits im artikel steht, entspricht der framebuffer dem digital übersetzten monitorbild - nicht mehr und nicht weniger.

Gruß --Murkel ^(anmurkeln) 13:49, 3. Mai 2006 (CEST)

"Bilderrahmen"??? Sonst geht's noch? "Bildspeicher" ist der im Deutschen gebräuchlichste Begriff und eine völlig korrekte Übersetzung. Leider sind die Wortfelder nicht identisch, da Framebuffer hauptsächlich die Sicht des Programmierers beschreibt. Das stand sogar mal im Artikel drin, bevor irgendein Held das entsorgt hat. Wikipedia verseptembert immer mehr.

Ach ja, und "frame" heißt in diesem Kontext schlicht (Einzel)bild. Die einzelnen Bilder eines Videos heißen z.B. frame.

ich verstehe deine kritik leider nicht. bildspeicher wird doch korrekt per redirect auf die seite verlinkt. die übersetzung von frame dient nur der klärung der wortbestandteile des englischen framebuffer. es soll daraus also keine direkte deutsche übersetzung abgeleitet werden. (nebenbei für rahmenpuffer gibts fast 1000 google hits)

der von dir aufgeführte satz wurde entfernt, weil daraus einfach nichts abzuleiten ist. programmierer interessieren sich auch für andere teile der speicher- bzw. systemarchitektur, ohne das ein entsprechender verweis z.b. in hauptspeicher oder grafikprozessor zu finden ist. schliesslich ist das ja ihr aufgabengebiet, systemkomponenten zu programmieren.

gruß --Murkel ^(anmurkeln) 11:56, 27. Sep 2006 (CEST)

Beispieltabelle: C64 ist ein denkbar schlechtes Beispiel, da er zuzüglich zum framebuffer ja noch ein extra Farbspeicher besitzt! Gibt/gab es denn nie ein bekanntes System mit echter S/W Darstellung in dieser Auflösung (z.B. Gameboy classic)?

Diese Auflösung wird auch von DOS in monochrom unterstützt (ob diesen Modus auch irgendwelche DOS-Spiele verwenden ist wiederum eine andere Frage). Hingegen hat der Gameboy Classic eine Auflösung von 160x144 und 4 graustufen, wie man leicht unter Game Boy nachlesen kann. --MrBurns 19:24, 31. Jul. 2008 (CEST)

Textmodus (z.B. [...] im Konsolenmodus unter Linux)

Das stimmt nicht ganz. Gewöhnlich ist die Framebuffer-Unterstützung im Kernel heute aktiviert, dann läuft die Text-Konsole im Grafikmodus. Tippe cat /dev/mem > /dev/fb0 für bunten Pixelschnee! -- Sloyment 15:08, 1. Apr. 2008 (CEST)

ändere es bitte dementsprechend. ich würde es ja selber tun, bin aber nicht so der linuxprofi. gruß --Murkel ^(anmurkeln) 19:41, 1. Apr. 2008 (CEST)

KiB und Mib bei den Beispielen

Hi, kann mir bitte jemand vorrechnen, warum 32000 = 4 KiB und 18874368 = 2,25 MiB sein soll? Meiner Meinung nach sind das 32 KB und 18 MB! --134.100.206.196 12:09, 28. Jul. 2008 (CEST)

es sind 32000 und 18874368 bits; rechtsseitig des gleichheitszeichens stehen bytes. damit sollte es klar sein. gruß --Murkel ^(anmurkeln) 20:49, 28. Jul. 2008 (CEST)

Kontrastberechnungen und Gammakorrektur

Zumindest bei Farbformaten mit 8 Bit und weniger pro Farbkomponente besteht in der Regel keine lineare Abhängigkeit zwischen Wert und Helligkeit. Üblich ist eine Gammakorrektur mit einem Gamma von 2.2. Der maximal mögliche Kontrast wird dadurch wesentlich höher, die Werte aus dem Text müssten alle hoch 2.2 genommen werden. Bei Formaten wie FP16 kann aber auch mit Werten gerechnet werden die in einem linearen Verhältnis zur Helligkeit stehen. Transparenzen und andere Lichteffekte lassen sich so erheblich näher an ihren physikalischen Vorbildern berechnen, hier liegt der eigentliche Vorteil, nicht im maximal möglichen Kontrast, der ist selbst bei 8-Bit pro Farbkomponente mit Gammakorrektur schon höher als alle realen Anzeigegeräte ihn wiedergeben könnten. (nicht signierter Beitrag von 87.143.51.64 (Diskussion) 11:54, 31. Jul 2011 (CEST))

Spielt Gamma-Korrektur bei der Betrachtung des Dynamikumfangs des Wertebereiches tatsächlich eine Rolle? Ich kenne mich da nicht so aus, ich selbst sehe das eher getrennt voneinander. Die Darstellung eines Bildes ist ja letztlich gar nicht die Aufgabe eines Framebuffers, sondern IMHO die der Grafikkarte. --Uncle Pain 14:28, 1. Aug. 2011 (CEST)

Lemma

Warum verschieben wir den Artikel nicht auf das deutsche Bildspeicher? 92.231.205.243 21:38, 4. Dez. 2011 (CET)

Unsinnige Kontrastangaben

Die Kontrastangaben für FP24 und FP32 von $10^{43}:1$ bzw $10^{83}:1$ sind realitätsferner Schwachsinn. Schon aus physikalischen Gründen existiert solch ein Kontrast nicht; selbst ein Gigawatt-Laser braucht für 10^43 Photonen mehr als 50 Millionen Jahre(!). --Schweikhardt 23:45, 9. Jan. 2012 (CET)

Diese Rechnereien sind sowieso für den Fuß, da das Intervall [0..255] nicht linear skaliert wird (dann würde man nämlich unter etwa 150 nichts mehr sehen). Mit einem kruden Hack wurde das so hingebogen, daß CRTs automatisch "in etwa" augen-linear angezeigt haben, d.h. real-logarithmisch. Man nennt dies sRGB und es ist ein Alptraum beim naiven Implementieren von Bildprozessierern, siehe z.B. http://www.4p8.com/eric.brasseur/gamma.html? . Lichtquellen erzeugen i.A. keine Zustände definierter Photonenanzahl, insofern wäre ich mit diesem Argument eher vorsichtig. Die beste heute verfügbare Anzeige (abgesehen von gepulstem Laser-TV und dergleichen?) ist die analoge Diaprojektion mit einem Kontrast von etwa 1:2000, extrem guter Diafilm selbst ist limitiert durch seinen Dichtewert von etwa D4 ~= 1:10000. --17:57, 2. Dez. 2012 (CET) (ohne Benutzername signierter Beitrag von 88.75.236.58 (Diskussion))

Dass man bei linearer Skalierung bei "unter 150 nichts mehr sehen" würde ist natürlich Blödsinn (unter "nichts mehr sehen" würde ich "schwarz sehen" verstehen), weil z.B. der Unterschied zwischen dem Grfauwert 10 (der sich bei korrekter Kalibirierung schon stark genug von 0 unterscheidet, dass das manshcliche Auge den Unbterschied wahrnehmen kann) und 255 bei linerarer Skalierung geringer wäre als bei der derzeit verwendeten logarimischen Skalierung. Man könnte aber eventuell nicht emhr alle Graustufen unterscheiden, was heute einem Mensch, der gut sehen kann, möglich ist wenn der Monitor entsprechend kalibriert ist (zumindest wenn sie in Streifen angezeigt werden, also z.B. ganz Links ein Streifen mit Grauwert 0, daneben einer mit 1 usw.). Und dass der höchste erzelbare Kontrast mit Monitoren unter 2.000:1 ist, ist auch Schmarrn, selbst LCDs erzielen einen statischen Kontrast von mehr als 2000:1 (der dynamische Kontrast kann hlher sein, aber das ist nicht das, was man eigentlich unter Kontrast versteht), Plasmabildschirme bis ca. 5.000.000:1 (kontrastoptimierte Kalibrierung vorausgesetzt). --MrBurns (Diskussion) 00:36, 3. Dez. 2012 (CET)

Umlaut im Code

Meine Frage an die Benutzer 149.249.0.211 und Codc: was stört euch am Umlaut im Quellcode-Kommentar? Selbst wenn jemand den Quellcode wirklich kopiert und ihn selbst verwendet, dürfte der Umnlautr keine negatoven Effekte haben: der Compiler dürfte ihn trotzdem ignorieren, weil er ja im Kommentar steht und es gibt bei den meisten Edittoren die Möglichkeit, die richtige Kodierung zu verwenden, damit der Umlaut richtig angezeigt wird und selbst wenn der Editor statt dessen ein falsches Zeichen darstellt, ist es nicht schwer zu erraten, dass das ein Umlaut sein soll. Hingegen spricht veiles gegen das weglassen des Umlautes, vor allem, dass Rückgabewert im ggeensatz zu Rueckgabewert korrektes Deutsch ist. --MrBurns (Diskussion) 02:31, 10. Jan. 2014 (CET)

Ich habe gerade gemerkt, dass noch andere Umlaute in den Kommenatren mit ae/oe/ue geschrieben waren, hab sie jetzt wohl alle durch ä/ö/ü ersetzt. --MrBurns (Diskussion) 02:38, 10. Jan. 2014 (CET)

Was ist ein frame buffer?

Der Artikel beschreibt leider nicht, was genau ein frame buffer ist, wo man ihn findet und wie er genutzt wird, außer in den ersten beiden Sätzen:

Der Framebuffer oder Bildspeicher (englisch frame – Einzelbild, buffer – Zwischenspeicher) ist Teil des Grafikspeichers von Computern und entspricht einer digitalen Kopie des Monitorbildes.

Genau. Teil des Grafikspeichers. Digitale Kopie des Monitorbildes. (Bei digitialen Monitoren also 1:1? Bei analogen Monitoren wird das digitale Bild mittels RAMDAC in analoge Signale für den Monitor umgewandelt, steht aber nicht da...)

Das heißt, jedem Bildschirmpixel kann genau ein bestimmter Bereich des Framebuffers zugewiesen werden, der dessen digital übersetzten Farbwert enthält.

Das ist es, was "eine digitale Kopie des Monitorbildes" bedeutet, oder nicht?

Seit den 1990er-Jahren befindet sich der Framebuffer vorwiegend auf der Grafikkarte.

Ist das so? Interessant, denn laut dieser Quelle^ref ist es genau umgekehrt: früher, als RAM noch zu langsam war, musste man eigenen Grafikspeicher, der etwas schneller war, für den Framebuffer verwenden. Später, als der RAM (der Computer) schneller wurde, konnte man mittels unified memory den frame buffer auch im System-RAM ablegen...

Und das sind nur die ersten drei Sätze.

Mich würde auch interessieren, wo der Rest herkommt. Ja, natürlich bestimmt die Auflösung und Farbtiefe die Größe des nötigen Framebuffer-Speichers. Aber der genaue Unterschied zwischen Grafikspeicher und Framebuffer wäre eigentlich mal interessanter gewesen (In early computers, video memory and the frame buffer were synonymous.^ref) als technische Details, von denen man noch nicht einmal weiß, ob sie z.B. von Atari-ST-Heimcomputern, IBM Mainframes (z.B. System/360), Macintosh, IBM PCs oder Spielekonsolen stammen... Vielleicht ja auch aus der digitalen Fernsehtechnik? Keine Ahnung, es fehlen ja auch jegliche Einzelnachweise...

Und dann kommt noch die Frage, warum der Linux-Framebuffer so umfassend beschrieben ist (was gut ist, aber ohne Quellenangaben dann doch etwas schwierig nachzuvollziehen), andere Implementierungen (Windows, Unix^{Bsp. 1978!!!}, Mac OS?) aber nicht. Auch hier wäre es jedoch erstmal insteressanter, allgemein von der Abstraktion zu sprechen – was ist denn der Unterschied zwischen dem VRAM-Framebuffer und dem frame buffer eines Betriebssystems,^Bsp. und dann im Speziellen, was ist eine frame buffer console (Unix natürlich, wird man unter Windows und Mac OS wohl vergeblich suchen)?

Und dann gibt es ja auch noch andere frame buffer, die nichts mit Grafik zu tun haben, beispielsweise bei der Netzwerktechnik im MAC (vermutlich für das zwischenspeichern für dem frame transfer zwischen MAC und PHY).^ref

‣Andreas•⚖ 09:34, 1. Dez. 2021 (CET)

Nachtrag: Ach ja, auch das Remote Framebuffer Protocol hat etwas mit dem Grafik-Framebuffer zu tun... (wenn auch vielleicht entfernt...) ‣Andreas•⚖ 09:47, 1. Dez. 2021 (CET)

Nachtrag 2: Das ist interessant zu lesen, sehr allgemein und "alt" (von 1987), NASA Technical Memorandum 89139 "Survey of Currently Available High-Resolution Raster Graphics Systems": Display Memory: The display memory (also known as refresh buffer, frame buffer, or bit map) contains the information necessary to generate the signal which places an image on the monitor screen.^ref ‣Andreas•⚖ 10:18, 1. Dez. 2021 (CET)