Warum nutzt man RGB?

[Mastermind]

Es wird Zeit eine der "was ich schon immer mal wissen wollte"-Fragen zu stellen. :D Denn obwohl ich überdurchschnittlich über Computer informiert bin, kenne ich nicht den genauen Grund, warum man konkret RGB für die Bilddarstellung verwendet. Früher hab ich mir diese Frage so gar nicht gestellt, denn ich wusste, dass es an sich Sinn macht. Warum also nicht. Allerdings weiß ich seit neuestem, dass es Probleme mit der Darstellung einiger Farben gibt. Und, dass man durchaus an besseren Systemen interessiert ist, siehe sRGB. Doch es gibt ja auch gänzlich andere Farbsysteme, von denen ich aber nur oberflächlich was mitbekommen habe.

Also dacht ich mir, geh ich als Physiker mal einfach an die Sache ran. Unsere Problemstellung ist es, Farbinformationen zu übertragen. Dabei jetzt aber unter dem Gesichtspunkt, dass es keine schwächen bei irgendwelchen Farben geben darf. Was sich mir als Physiker sofort aufdrängt ist folgendes System: Man nimmt das Fenster des sichtbaren Lichtes im elektromagnetischen Spektrum. Wo man jetzt genau die Grenzen definiert ist ja ein klein wenig ne Streitfrage, aber das können wir außen vorlassen, denn darauft kommt es nicht allzusehr drauf an. Jedenfalls nimmt man dieses Spektrum und teilt es gleichmäßig auf. Ordnet nun der kleinsten sichtbaren Wellenlänge 0 zu und der größten länge den höchsten Bit-Wert zu, z.B. 16 Bit. Nun nimmt man noch 8 Bit für die Helligkeit und versteckt irgendwo zwei Werte je für perfektes weiß und perfektes schwarz. Z.B. in dem man das Spektrum erst beim drittkleinsten Bitwert beginnt. Und fertig ist die Laube. :biggrin: So hat man bei 24 Bit Farbtiefe das Spektrum gleichmäßig abgedeckt und kann auch weiß und schwarz darstellen.

Jetzt würde ich natürlich gerne von euch Experten wissen, ob mein System etwas taugt. Wenn nein, warum nicht? Wenn ja, warum wird es nicht eingesetzt? :smile:

[looking glass]

Zuviele Informationen, die nur unnötig Platz benötigen, aber nichtmal Ansatzweise in ihrer gänze nutzbringend wären, oder anders, wieviele Farbnuancen glaubst Du, kann das menschliche Auge wirklich klar auseinander halten? Wieviele Farben überhaupt klar diffenrenziert auseinander halten?

Der RGB Farbraum hat rechnerisch 16.777.216 Möglichkeiten in der Computertechnik, wen ich dagegen halte, das der Mensch c.a. 200 Farbtöne unterscheiden kann, diese in Intensität, Helligkeit und ich glaub, Weissanteil erweitert, kann der Mensch c.a., ich glaub, es waren 20 Millionen Farben sehend unterscheiden, reduzierend kommt jedoch hinzu, was ein Bildschrim überhaupt anzeigen kann.

Wie man es aber nun auch drehen und wenden will, eine Erweiterung des Farbraums über RGB hinaus, bringt eigentlich nicht mehr viel, weil das Auge einfach nicht mehr sehen kann und es kaum Geräte gibt, die ein mehr anzeigen könnten.

Die Frage ist also, warum sollte man etwas anderes benutzen, was einen grösseren Farbraum hätte, welchen wir nicht sehen? Wäre das nicht unnütz?

Eine andere Frage wäre, ob dein Ansatz z.B. was bringen würde bei der Mischfarbenberechnung, oder ob er eine Datenreduktion zu Folge hätte, welche Platz schaffen würde, bei Erhöhung des Farbraums, oder ähnliches - für solche Betrachtungen, ist es für mich jedoch zu spät heut :).

[Monger]

Ich vermute, das ist historisch und technisch bedingt: bis heute basieren alle Monitore darauf, dass ihre Leuchtschicht aus drei verschiedenen Farben besteht: Rot, Grün und Blau. Da ist es nur natürlich, die Farbtafel nach der Hardware auszurichten.


Aber ich stimme dir natürlich zu, dass das RGB Modell massive Schwächen hat. Wie man ja auch von Druckern weiß, ist das RGB Modell extrem schlecht für Fotos geeignet. Selbst wenn man RGB sehr hochaufgelöst abmischt, wird man die Pastelltöne (wie eben Hautfarbton etc.) nicht vernünftig hinkriegen. Für sowas ist dann CMYK besser geeignet.

Du kannst natürlich dir eine beliebige Farbskala (wie z.B. eben nach Wellenlängen) definieren. Die nützt dir aber gar nix, wenn du sie nicht auf die Hardware schmeißen kannst. Du musst also zwischendrin mappen, und machst dort naturgemäß Rundungsfehler.

Die Frage müsste also eher sein: Warum gibt es keine Monitore mit mehr als drei Farbschichten? Ich vermute, das hat vorallem konstruktionsbedingte Gründe. Drei Farben lassen sich in einem Dreieck als Lichtpunkt noch relativ gut vereinen. Bei vier oder mehr Farben müsste das Lochmuster völlig anders aussehen, und verbraucht natürlich auch deutlich mehr Platz. Was wiederum heißt, dass man bei selbem Platz nur eine niedrigere Auflösung anbieten kann...
Außerdem sind afaik Blau, Grün und Rot als Farbschicht relativ einfach umzusetzen. Andere Farbtöne sind da technisch wohl komplexer.

Meines Wissens gibt es für technische Zwecke wie z.B. die Medizin ganz eigene Monitore, die auch mit ganz anderen Farbskalen arbeiten, und auch intern anders aufgebaut sind. Aber die kosten natürlich auch entsprechend...



Lange Rede, kurzer Sinn: die verfügbare Hardware definiert die Farbskala. Es wäre sicher mal spannend, wenn es da andere Hardware gäbe, aber das wird wohl in absehbarer Zukunft nicht passieren.

[Gast]

Ordnet nun der kleinsten sichtbaren Wellenlänge 0 zu und der größten länge den höchsten Bit-Wert zu, z.B. 16 Bit.

Hmm, bist Physiker, ja? Schonmal was von stetigen Merkmalen gehört, welche im diskreten Raum abgebildet werden sollen?

[Mastermind]

Gast[/POST]']Hmm, bist Physiker, ja? Schonmal was von stetigen Merkmalen gehört, welche im diskreten Raum abgebildet werden sollen?
Physikstudent im niedrigen Semester. ;) Erkläre bitte genauer oder mit Link. Ich habe eine Vorstellung davon, was du mathematisch wohl meinst, aber nicht, wo jetzt das Problem liegt.

[Mastermind]

Monger[/POST]']Ich vermute, das ist historisch und technisch bedingt: bis heute basieren alle Monitore darauf, dass ihre Leuchtschicht aus drei verschiedenen Farben besteht: Rot, Grün und Blau. Da ist es nur natürlich, die Farbtafel nach der Hardware auszurichten.


Aber ich stimme dir natürlich zu, dass das RGB Modell massive Schwächen hat. Wie man ja auch von Druckern weiß, ist das RGB Modell extrem schlecht für Fotos geeignet. Selbst wenn man RGB sehr hochaufgelöst abmischt, wird man die Pastelltöne (wie eben Hautfarbton etc.) nicht vernünftig hinkriegen. Für sowas ist dann CMYK besser geeignet.

Du kannst natürlich dir eine beliebige Farbskala (wie z.B. eben nach Wellenlängen) definieren. Die nützt dir aber gar nix, wenn du sie nicht auf die Hardware schmeißen kannst. Du musst also zwischendrin mappen, und machst dort naturgemäß Rundungsfehler.

Die Frage müsste also eher sein: Warum gibt es keine Monitore mit mehr als drei Farbschichten? Ich vermute, das hat vorallem konstruktionsbedingte Gründe. Drei Farben lassen sich in einem Dreieck als Lichtpunkt noch relativ gut vereinen. Bei vier oder mehr Farben müsste das Lochmuster völlig anders aussehen, und verbraucht natürlich auch deutlich mehr Platz. Was wiederum heißt, dass man bei selbem Platz nur eine niedrigere Auflösung anbieten kann...
Außerdem sind afaik Blau, Grün und Rot als Farbschicht relativ einfach umzusetzen. Andere Farbtöne sind da technisch wohl komplexer.

Meines Wissens gibt es für technische Zwecke wie z.B. die Medizin ganz eigene Monitore, die auch mit ganz anderen Farbskalen arbeiten, und auch intern anders aufgebaut sind. Aber die kosten natürlich auch entsprechend...



Lange Rede, kurzer Sinn: die verfügbare Hardware definiert die Farbskala. Es wäre sicher mal spannend, wenn es da andere Hardware gäbe, aber das wird wohl in absehbarer Zukunft nicht passieren.
Das klingt logisch und in diese Richtung gingen meine Überlegungen auch.
Dann dachte ich mir, wäre es doch möglich gewesen, dass man dem Monitor das Signal so sendet und im Monitor, wenn es schon aufgrund technischer Umstände RGB sein muss, mit einer sehr hohen Genauigkeit (z.B. 96 Bit) umgerechnet wird. Es ist ja sehr viel Platz in den Röhrenmonis. Da wäre so ein Chip sicher kein Problem gewesen. ;)

[Mastermind]

looking glass[/POST]']Zuviele Informationen, die nur unnötig Platz benötigen, aber nichtmal Ansatzweise in ihrer gänze nutzbringend wären, oder anders, wieviele Farbnuancen glaubst Du, kann das menschliche Auge wirklich klar auseinander halten? Wieviele Farben überhaupt klar diffenrenziert auseinander halten?

Der RGB Farbraum hat rechnerisch 16.777.216 Möglichkeiten in der Computertechnik, wen ich dagegen halte, das der Mensch c.a. 200 Farbtöne unterscheiden kann, diese in Intensität, Helligkeit und ich glaub, Weissanteil erweitert, kann der Mensch c.a., ich glaub, es waren 20 Millionen Farben sehend unterscheiden, reduzierend kommt jedoch hinzu, was ein Bildschrim überhaupt anzeigen kann.

Wie man es aber nun auch drehen und wenden will, eine Erweiterung des Farbraums über RGB hinaus, bringt eigentlich nicht mehr viel, weil das Auge einfach nicht mehr sehen kann und es kaum Geräte gibt, die ein mehr anzeigen könnten.

Die Frage ist also, warum sollte man etwas anderes benutzen, was einen grösseren Farbraum hätte, welchen wir nicht sehen? Wäre das nicht unnütz?

Eine andere Frage wäre, ob dein Ansatz z.B. was bringen würde bei der Mischfarbenberechnung, oder ob er eine Datenreduktion zu Folge hätte, welche Platz schaffen würde, bei Erhöhung des Farbraums, oder ähnliches - für solche Betrachtungen, ist es für mich jedoch zu spät heut :).
Ich tippe mal darauf, dass es gestern auch für den Rest zu spät für dich war. :biggrin: (Soll aber nicht beleidigend sein!)
Zunächst mal sehe ich mein System als genau so Ressourcennutzend an, wie RGB. Bzw. habe ich es so festgelegt, dass genau so viele Bits zum einsatz kommen.
Desweiteren macht eine vergrößerung des Farbraums sehr wohl Sinn. Und ganz besonders dann, wenn bestimmte Farben schlecht dargestellt werden können. Wir können hier ja von HDRR absehen. Mir ging es nur darum, dass so ein System in meinen Augen nicht die Schwächen des RGB-Systems hätte. Denn alle Farben wären gleich gut vertreten.

[RLZ]

Zuerst mal: Warum RGB?
Das Farbsehen des Menschen wird durch die sog. Zäpfchen ermöglicht. Der Mensch hat davon 3 Typen (andere Tiere haben auch mehr), die auf unterschiedliche Frequenzbereiche reagieren. Und oh Wunder... Diese Frequenzbereiche passen schon sehr gut auf die Farben Rot, Grün und Blau.
Hier schön skizziert:
http://www.research.ibm.com/image_apps/graphics/spaper1.gif
Sieht man mal von dem negativen Ausschlag des Zäpfchen für Rot ab, approximiert der RGB-Farbraum schon sehr gut das menschliche Sehen.
CIE z.B. verbessert diese Approximation dann noch:
http://www.research.ibm.com/image_apps/graphics/spaper2.gif
(hier CIE 1931)
Der negative Einfluss wird hier invertiert, was bei der Wahrnehmung aber ungefähr den selben Einfluss hat.

Ich hab jetzt mal versucht die Erklärung einfach zu halten... Ich hoffe das langt den meisten noch. ;)
So und nu auf zur Arbeit X-D

[Monger]

Mastermind[/POST]']Das klingt logisch und in diese Richtung gingen meine Überlegungen auch.
Dann dachte ich mir, wäre es doch möglich gewesen, dass man dem Monitor das Signal so sendet und im Monitor, wenn es schon aufgrund technischer Umstände RGB sein muss, mit einer sehr hohen Genauigkeit (z.B. 96 Bit) umgerechnet wird. Es ist ja sehr viel Platz in den Röhrenmonis. Da wäre so ein Chip sicher kein Problem gewesen. ;)

Wäre wahrscheinlich möglich, aber damit verbrätst du halt unnötig Bandbreite. Und wozu? Damit wenn irgendwann mal in ferner Zukunft die entsprechenden Monitore verfügbar sind, du auch entsprechende Daten schicken kannst? Und du musst ja auch intern mit den entsprechenden Farbwerten rechnen.

Nene, das wird vorerst nix. Wenn wir jetzt schon erstmal Gleitkommawerte für die Helligkeit zur Berechnung verwenden, und danach vielleicht noch eine Korrektur des Farbraums kommt (wir sehen ja Grün, Rot und Blau nicht gleichmäßig gut), wären wir schonmal einen dramatischen Schritt weiter. Das RGB Modell ist noch lange nicht ausgereizt.

[Gast]

Mastermind[/POST]']Also dacht ich mir, geh ich als Physiker mal einfach an die Sache ran. Unsere Problemstellung ist es, Farbinformationen zu übertragen. Dabei jetzt aber unter dem Gesichtspunkt, dass es keine schwächen bei irgendwelchen Farben geben darf. Was sich mir als Physiker sofort aufdrängt ist folgendes System: Man nimmt das Fenster des sichtbaren Lichtes im elektromagnetischen Spektrum. Wo man jetzt genau die Grenzen definiert ist ja ein klein wenig ne Streitfrage, aber das können wir außen vorlassen, denn darauft kommt es nicht allzusehr drauf an. Jedenfalls nimmt man dieses Spektrum und teilt es gleichmäßig auf. Ordnet nun der kleinsten sichtbaren Wellenlänge 0 zu und der größten länge den höchsten Bit-Wert zu, z.B. 16 Bit. Nun nimmt man noch 8 Bit für die Helligkeit und versteckt irgendwo zwei Werte je für perfektes weiß und perfektes schwarz. Z.B. in dem man das Spektrum erst beim drittkleinsten Bitwert beginnt. Und fertig ist die Laube.
tja, das Problem bei der Sache hast du praktisch schon genannt: einen Wert für weiß kannst du nirgendwo verstecken, weil es weiß in deinem System gar nicht gibt. Dein System kennt nur reine Spektralfarben, in der Natur kommen aber auch Mischungen aus unterschiedlichen Spektralfarben vor, weiß ist ein Beispiel dafür (alle Spektralfarben gemischt).
Schwarz bekommst du noch hin, indem du die Helligkeit auf Null setzt, aber wenn du sie auf maximal setzt, bekommst du mitnichten weiß, sondern einfach nur die Farbe, die in den 16 Bit für die Spektralfarben eingestellt ist, besonders hell (z.B. helles Rot).

Ein ähnliches System wie deines gibt es aber tatsächlich, nur daß es neben Farbton (Hue) und Helligkeit (Luminance) noch einen dritten Anteil hat, die Sättigung (Saturation), gewissermaßen ein Maß für den Grad der Gemischtheit der Farben. Maximale Sättigung bedeutet reine Spektralfarbe, Sättigung Null bedeutet je nach eingestellter Helligkeit schwarz, grau oder weiß.
Im Farbdialog von Windows bekommst du dieses System für gewöhnlich direkt neben dem RGB-System angezeigt ;)

Mastermind[/POST]']Jetzt würde ich natürlich gerne von euch Experten wissen, ob mein System etwas taugt. Wenn nein, warum nicht? es fehlt die Sättigung.

Mastermind[/POST]']Wenn ja, warum wird es nicht eingesetzt? :smile:es wird eingesetzt. Aber mit Sättigung.

[Gast]

Mastermind[/POST]']Dann dachte ich mir, wäre es doch möglich gewesen, dass man dem Monitor das Signal so sendet und im Monitor, wenn es schon aufgrund technischer Umstände RGB sein muss, mit einer sehr hohen Genauigkeit (z.B. 96 Bit) umgerechnet wird. Es ist ja sehr viel Platz in den Röhrenmonis. aber keinen für Bits. Röhrenmonitore arbeiten analog.

[Gast]

Monger[/POST]']Aber ich stimme dir natürlich zu, dass das RGB Modell massive Schwächen hat. Wie man ja auch von Druckern weiß, ist das RGB Modell extrem schlecht für Fotos geeignet. Selbst wenn man RGB sehr hochaufgelöst abmischt, wird man die Pastelltöne (wie eben Hautfarbton etc.) nicht vernünftig hinkriegen. Für sowas ist dann CMYK besser geeignet.das liegt daran, daß RGB eine additive Farbmischung ist (R+G+B = weiß), der Drucker aber nur subtraktive Farbmischung kann. Deswegen benutzt er CMY (C+M+Y = schwarz). Da aber die physikalischen Eigenschaften der Druckertinte nicht ideal genug dem CMY-Modell entsprechen, sprich: eine Mischung aus cyanfarbener, magentafarbener und gelber Tinte kein echtes schwarz ergibt, sondern nur ein schmutziges dunkelbraun, nimmt man zusätzlich noch schwarze Tinte (K).

[Mastermind]

RLZ[/POST]']Zuerst mal: Warum RGB?
Das Farbsehen des Menschen wird durch die sog. Zäpfchen ermöglicht. Der Mensch hat davon 3 Typen (andere Tiere haben auch mehr), die auf unterschiedliche Frequenzbereiche reagieren. Und oh Wunder... Diese Frequenzbereiche passen schon sehr gut auf die Farben Rot, Grün und Blau.
Hier schön skizziert:
http://www.research.ibm.com/image_apps/graphics/spaper1.gif
Sieht man mal von dem negativen Ausschlag des Zäpfchen für Rot ab, approximiert der RGB-Farbraum schon sehr gut das menschliche Sehen.
CIE z.B. verbessert diese Approximation dann noch:
http://www.research.ibm.com/image_apps/graphics/spaper2.gif
(hier CIE 1931)
Der negative Einfluss wird hier invertiert, was bei der Wahrnehmung aber ungefähr den selben Einfluss hat.

Ich hab jetzt mal versucht die Erklärung einfach zu halten... Ich hoffe das langt den meisten noch. ;)
So und nu auf zur Arbeit X-D
Danke für die Darlegung. Allerdings kommt es mir ja mehr darauf an, dass es intern offensichtlich suboptimal ist, das reine RGB-System zu nutzen. Röhrenmonitore haben dieses Problem an sich nicht. Da hab ich dann auch kein Problem mit dem RGB-System.

[Mastermind]

Monger[/POST]']Wäre wahrscheinlich möglich, aber damit verbrätst du halt unnötig Bandbreite. Und wozu? Damit wenn irgendwann mal in ferner Zukunft die entsprechenden Monitore verfügbar sind, du auch entsprechende Daten schicken kannst? Und du musst ja auch intern mit den entsprechenden Farbwerten rechnen.

Nene, das wird vorerst nix. Wenn wir jetzt schon erstmal Gleitkommawerte für die Helligkeit zur Berechnung verwenden, und danach vielleicht noch eine Korrektur des Farbraums kommt (wir sehen ja Grün, Rot und Blau nicht gleichmäßig gut), wären wir schonmal einen dramatischen Schritt weiter. Das RGB Modell ist noch lange nicht ausgereizt.
Du täuschst dich. Das von mir beschrieben System braucht keine zusätzliche Bandbreite, weil es genau so 24 bzw. 32 Bit Farbtiefe benutzt, wie das verglichene RGB-System. Desweiteren haben Röhrenmonitore seit eh und je die Möglichkeit, Farben besser darzustellen, als sie mit dem RGB-System intern kodiert werden. Von daher sind beide Einwände unwirksam.

[Mastermind]

Gast[/POST]']tja, das Problem bei der Sache hast du praktisch schon genannt: einen Wert für weiß kannst du nirgendwo verstecken, weil es weiß in deinem System gar nicht gibt. Dein System kennt nur reine Spektralfarben, in der Natur kommen aber auch Mischungen aus unterschiedlichen Spektralfarben vor, weiß ist ein Beispiel dafür (alle Spektralfarben gemischt).
Schwarz bekommst du noch hin, indem du die Helligkeit auf Null setzt, aber wenn du sie auf maximal setzt, bekommst du mitnichten weiß, sondern einfach nur die Farbe, die in den 16 Bit für die Spektralfarben eingestellt ist, besonders hell (z.B. helles Rot).

Ein ähnliches System wie deines gibt es aber tatsächlich, nur daß es neben Farbton (Hue) und Helligkeit (Luminance) noch einen dritten Anteil hat, die Sättigung (Saturation), gewissermaßen ein Maß für den Grad der Gemischtheit der Farben. Maximale Sättigung bedeutet reine Spektralfarbe, Sättigung Null bedeutet je nach eingestellter Helligkeit schwarz, grau oder weiß.
Im Farbdialog von Windows bekommst du dieses System für gewöhnlich direkt neben dem RGB-System angezeigt ;)

es fehlt die Sättigung.

es wird eingesetzt. Aber mit Sättigung.
Dieses Problem hatte ich im Hinterkopf und, dass es dieses alternative System hab ich auch mitbekommen. Jetzt weiß ich genau, wie es funktioniert. Danke.

Allerdings wird intern doch immer noch mit RGB gerechnet, oder etwa nicht? Von daher ist so ein System solange Augenwischerei, solange die GraKa es sowieso in RGB umrechnet und wieder die Nachteile von RGB zum Tragen kommen, weil sie das alternative System einfach nicht handlen kann. Oder liege ich da etwa falsch?

[Mastermind]

Gast[/POST]']aber keinen für Bits. Röhrenmonitore arbeiten analog.Aber genug für einen Digital-Analog-Wandler. :biggrin: Wobei es mir nicht auf die Anzahl der Bits ankommt. Mir ging es nur darum, dass der Monitor aus dem anderen Signal-Typ die Farben gleichmäßiger "herauslesen" könnte.

[Monger]

Mastermind[/POST]']Dieses Problem hatte ich im Hinterkopf und, dass es dieses alternative System hab ich auch mitbekommen. Jetzt weiß ich genau, wie es funktioniert. Danke.

Allerdings wird intern doch immer noch mit RGB gerechnet, oder etwa nicht? Von daher ist so ein System solange Augenwischerei, solange die GraKa es sowieso in RGB umrechnet und wieder die Nachteile von RGB zum Tragen kommen, weil sie das alternative System einfach nicht handlen kann. Oder liege ich da etwa falsch?
Wenn ich das richtig weiß, sind beide Systeme verlustfrei ineinander umrechenbar.
Bei Hue/Saturation/Lightness wird immer noch jeder Kanal linear mit der gleichen Zahl an Bits aufgelöst. Abgesehen vielleicht davon dass es sich für Physiker schöner liest :ugly: , bietet es keine Vorteile gegenüber RGB. Es ist schließlich das selbe.

[Coda]

Mastermind[/POST]']Also dacht ich mir, geh ich als Physiker mal einfach an die Sache ran. Unsere Problemstellung ist es, Farbinformationen zu übertragen. Dabei jetzt aber unter dem Gesichtspunkt, dass es keine schwächen bei irgendwelchen Farben geben darf. Was sich mir als Physiker sofort aufdrängt ist folgendes System: Man nimmt das Fenster des sichtbaren Lichtes im elektromagnetischen Spektrum. Wo man jetzt genau die Grenzen definiert ist ja ein klein wenig ne Streitfrage, aber das können wir außen vorlassen, denn darauft kommt es nicht allzusehr drauf an. Jedenfalls nimmt man dieses Spektrum und teilt es gleichmäßig auf. Ordnet nun der kleinsten sichtbaren Wellenlänge 0 zu und der größten länge den höchsten Bit-Wert zu, z.B. 16 Bit. Nun nimmt man noch 8 Bit für die Helligkeit und versteckt irgendwo zwei Werte je für perfektes weiß und perfektes schwarz. Z.B. in dem man das Spektrum erst beim drittkleinsten Bitwert beginnt. Und fertig ist die Laube. :biggrin: So hat man bei 24 Bit Farbtiefe das Spektrum gleichmäßig abgedeckt und kann auch weiß und schwarz darstellen.
Damit kannst du nicht sinnvoll mit rumrechnen.

[Mastermind]

Coda[/POST]']Damit kannst du nicht sinnvoll mit rumrechnen.
Warum? Kannst du ein konkretes Beispiel geben?

[Coda]

Mach damit mal Alpha-Blending, bzw. verändere nur die Farbe Rot usw...

[Mastermind]

Coda[/POST]']Mach damit mal Alpha-Blending, bzw. verändere nur die Farbe Rot usw...
Nun, ich gebe zu, zu Alpha-Blending kann ich nicht viel sagen, weil mir die genauen Abläufe nicht bekannt sind.
Aber zum zweiten Beispiel: Verändere mit deinem System mal nur die Farbe Ockergelb. Oder Lila. Oder Türkis. ;)

[Gast]

Coda[/POST]']Mach damit mal Alpha-Blending, bzw. verändere nur die Farbe Rot usw...Alpha-Blending sollte kein Problem sein. Du machst einfach ein HSLA-Format. Beim Blending machst du dann

(H,S,L) = (As*Hs + (1-As)*Hd, As*Ss + (1-As)*Sd, As*Ls + (1-As)*Ld)

wobei s und d für source und destination stehen. Um den Rot-Anteil zu ändern, mußt dann eine Transformation zwischen RGB und HSL machen und berechnen, wie sich die Änderung von R auf H, S und L auswirkt. Im Windows-Farbdialog bekommst du das demonstriert.

[Mastermind]

Gast[/POST]']Alpha-Blending sollte kein Problem sein. Du machst einfach ein HSLA-Format. Beim Blending machst du dann

(H,S,L) = (As*Hs + (1-As)*Hd, As*Ss + (1-As)*Sd, As*Ls + (1-As)*Ld)

wobei s und d für source und destination stehen. Um den Rot-Anteil zu ändern, mußt dann eine Transformation zwischen RGB und HSL machen und berechnen, wie sich die Änderung von R auf H, S und L auswirkt. Im Windows-Farbdialog bekommst du das demonstriert.
Sehr schön. :biggrin:

[Neomi]

Gast[/POST]']Alpha-Blending sollte kein Problem sein. Du machst einfach ein HSLA-Format. Beim Blending machst du dann

(H,S,L) = (As*Hs + (1-As)*Hd, As*Ss + (1-As)*Sd, As*Ls + (1-As)*Ld)

Schön, das wäre dann RGB-Blending mit ausgetauschten Buchstaben. Ganz so einfach ist es mit HSL aber nicht. Versuche mal von Rot mit leichtem Blauanteil zu Rot mit minimalem Grünanteil zu blenden, ohne das komplette Farbrad einmal zu überqueren.

Mastermind[/POST]']Sehr schön. :biggrin:

Wenn man mit einer Formel zufrieden ist, die nicht so funktioniert, wie sie soll, dann ja.

[Coda]

Mastermind[/POST]']Aber zum zweiten Beispiel: Verändere mit deinem System mal nur die Farbe Ockergelb. Oder Lila. Oder Türkis. ;)
Das macht keinen Sinn. Die Farbe egal wie sie gespeichert ist immer noch eine Farbe. Wie soll ich "eine Farbe einer Farbe ändern"?

Die Idee deiner Farbspeicherung ist übrigens nicht neu. Photoshop hat sowas in der Farbauswahl, aber zum rumrechnen ist es einfach nicht brauchbar. Texturfilterung dürfte auch ein Problem werden.

[Mastermind]

Coda[/POST]']Das macht keinen Sinn. Die Farbe egal wie sie gespeichert ist immer noch eine Farbe. Wie soll ich "eine Farbe einer Farbe ändern"?

Die Idee deiner Farbspeicherung ist übrigens nicht neu. Photoshop hat sowas in der Farbauswahl, aber zum rumrechnen ist es einfach nicht brauchbar. Texturfilterung dürfte auch ein Problem werden.
Wenn ich das sage, was du sagst, macht es plötzlich keinen Sinn? Ich zitiere dich mal nochmal:

"verändere nur die Farbe Rot usw..."

Ich habe genau das gleiche gesagt, nur die Farbe ersetzt. Ich bin davon ausgegangen, dass du darauf anspielen wolltest, dass man mit Rot einfach "hantieren" kann bei RGB. Und ich wollte dich darauf aufmerksam machen, dass das nicht mit jeder Farbe geht. Wo liegt denn jetzt das Missverständnis? ;)

[Xmas]

Mastermind[/POST]']Desweiteren haben Röhrenmonitore seit eh und je die Möglichkeit, Farben besser darzustellen, als sie mit dem RGB-System intern kodiert werden.
Röhrenmonitore stellen in der Regel RGB-Farben dar, welches System sollte da also besser sein?

RGB kann man im Prinzip als grob eingeteiltes Spektralsystem betrachten. Um Lichtinteraktionen korrekter zu berechnen müsste man eigentlich die Zahl der dargestellten Wellenlängen deutlich erhöhen. Dann könnte man auch solche Dinge wie Absorption eines schmalen Frequenzbandes realistisch darstellen.

[Trap]

Das Auge sieht keine Spektren, sondern nur 3-dimensionale Farbvektoren. Als Ausgabe des Rechners reicht also ein Werttripel pro Punkt. Wie das Anzeigegerät die dann am besten in Licht wandelt ist wieder eine andere Frage.

Mit Spektren zu rechnen könnte Vorteile bringen, ähnlich wie HDR-rendering, aber nur in sehr exotischen Fällen.

[Mastermind]

Trap[/POST]']Das Auge sieht keine Spektren, sondern nur 3-dimensionale Farbvektoren. Als Ausgabe des Rechners reicht also ein Werttripel pro Punkt. Wie das Anzeigegerät die dann am besten in Licht wandelt ist wieder eine andere Frage.

Mit Spektren zu rechnen könnte Vorteile bringen, ähnlich wie HDR-rendering, aber nur in sehr exotischen Fällen.
Könntest du einen Link angeben, wo das mit den dreidimensionalen Farbvektoren in den Augen beschrieben wird?

[RoKo]

Hier kommt der Link: http://de.wikipedia.org/wiki/Zapfen_%28Auge%29#Verteilung_und_Zapfentypen

[Trap]

Genauer passend ist IMO der Artikel:
http://de.wikipedia.org/wiki/Farbwahrnehmung

[DavChrFen]

Noch was: für die Farbe braun kommt im Regenbogen nicht vor. Daraus folgt, dass man für die Farbe braun nicht EINE Wellenlänge zuordnen kann. Braun ist ein Mischmach aus verschiedenen Wellenlängen.
Und CYK+schwarz kann farben darstellen, die RGB nicht kann. Der sogenannte "Farbkeil" hat was damit zu tun.

http://www.hundertachtzehn.de/fr.png

[Gast]

Trap[/POST]']Das Auge sieht keine Spektren, sondern nur 3-dimensionale Farbvektoren. die Linearkombinationen von Basisvektoren e_R, e_G und e_B sind, von denen jeder ein Spektrum ist (siehe Grafik von RLZ).

[Gast]

Xmas[/POST]']RGB kann man im Prinzip als grob eingeteiltes Spektralsystem betrachten. Um Lichtinteraktionen korrekter zu berechnen müsste man eigentlich die Zahl der dargestellten Wellenlängen deutlich erhöhen. ähm... du meinst damit hoffentlich nicht, daß RGB nur drei Wellenlängen verwenden würde? Das R, G und B sind des RGB-Systems nämlich mitnichten monofrequente Farben. Sonst hättest du in RLZ's Grafik statt der drei breiten, gaußkurvenähnlichen Gebilde nur drei schmale Peaks.

[z3ck3]

Wenn man nur ein Ausgabemedium hat ist es sinvoll auch nur für das Ausgabemedium zu codieren. Monitore benutzen den RGB Farbraum. Ob nun sRGB oder Adobe RGB oder sonst was. sRGB und andere Farbräume des RGB-Typs sind im prinzip ja nur RGB Farbräume die für bestimmte Medien optimiert wurden. So sind bestimmte farbbereiche intensiever oder schwächer. So passt Adobe RGB z.B. perfekt als Ausgangsfarbraum für den Druck (Rot kann in CMYK z.B. nicht so satt dargestellt werden wie es in sRGB dargestellt werden kann).

Vielleicht ist das auch etwas falsch dargestellt, aber im Prinzip müsste dieses stimmen.

Wenn das Ausgabemedium aber variiert, z.B. ein Bild sowohl für das Internet wie auch für verschiedene Druckmedien bestimmt ist, empfiehlt es sich sogar den LAB Farbraum zu nutzen solange das Bild bearbeitet wird und erst im letzten schritt in den gewünschten Farbraum umzuwandeln (jedenfalls hab ich das mal so gelernt *g*)

Letztendlich deckt der RGB Farbraum mit seinen 8bit pro Kanal schon den größten Teil des Farbspektrum ab. Und da sich das Bild am Monitor aus 3 Farben zusammen setzt sollte man auch die Farben übertragen und mit diesen rechnen. Denn bei jeder Umrechnung gehen Informationen verloren.

[Trap]

Gast[/POST]']ähm... du meinst damit hoffentlich nicht, daß RGB nur drei Wellenlängen verwenden würde? Das R, G und B sind des RGB-Systems nämlich mitnichten monofrequente Farben. Sonst hättest du in RLZ's Grafik statt der drei breiten, gaußkurvenähnlichen Gebilde nur drei schmale Peaks.
Jedes Anregungsspektrum hat ein gleich wahrgenommenes Spektrum das nur aus 3 monochromatischen Linien besteht. Daher darf der Computer auch mit monochromatischem R,G und B rechnen und macht es auch.

[Gast]

Trap[/POST]']Jedes Anregungsspektrum hat ein gleich wahrgenommenes Spektrum das nur aus 3 monochromatischen Linien besteht. ich versuche mal zu verstehen, was du hier sagen willst.
Willst du sagen, daß die drei in heutigen Röhrenmonitoren verwendeten Leuchtstoffe nur je eine monochromatische Anregungslinie haben?
Daß nämlich jedes x-beliebige Anregungsspektrum stets drei monochromatische Linien hätte, stimmt definitiv nicht...

[hofmetzger]

Es gibt ja außer RGB und HLS noch YUV.
RGB hat für Computergrafik den Vorteil des einfachen Mischens von Farben, ist praktisch zu Speichern (Speicher vierteln in Rot, Grün, Blau und Mipmap, welcher widerum Rot, Grün, Blau und eine weitere Mipmap ...)

HLS find ich ganz praktisch, um Einfluss auf Eigenschaften eines Bildes zu nehmen, die mit RGB-Reglern nur schwer zu erreichen sind: Farbkorrekturen, Saturation anpassen. Man sieht schon: praktisch in Bild/Videobearbeitung.

YUV wird vor allem im Videobereich angewendet. Microsoft hat da eine schöne Seite (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/yuvformats.asp) dazu, auf der auch auf die Arten der Speicherung eingegangen wird. Das ist insofern interessant, da durch die Trennung von Helligkeit und 2 Croma-Kanälen, es möglich ist verschiedene Auflösungen für Helligkeit und Farbe zu fahren. Da der Mensch Unterschiede und Details der Helligkeit stärker wahrnimmt, als die der Farbe, wird meist die Farbauflösung eingeschränkt und damit Bandbreite/Speicherbedarf gespart, ohne den visuellen Eindruck stark zu verschlechtern.
Microsoft empfielt generell das YUV-Format für Video unter Windows.

Es ist also durchaus so, dass man für den richtigen Job, auch das richtige Format verwendet.

[Coda]

hofmetzger[/POST]']ist praktisch zu Speichern (Speicher vierteln in Rot, Grün, Blau und Mipmap, welcher widerum Rot, Grün, Blau und eine weitere Mipmap ...)
Nene, es werden schon 4 Komponenten gespeichert, außer man benützt DXT.

[hofmetzger]

Coda[/POST]']Nene, es werden schon 4 Komponenten gespeichert, außer man benützt DXT.
Hmm, zumindest hab ich das so in Graphischer Datenverarbeitung gelernt. Aber ich nehm das mal so hin :)

[aths]

hofmetzger[/POST]']Es gibt ja außer RGB und HLS noch YUV.
RGB hat für Computergrafik den Vorteil des einfachen Mischens von Farben, ist praktisch zu Speichern (Speicher vierteln in Rot, Grün, Blau und Mipmap, welcher widerum Rot, Grün, Blau und eine weitere Mipmap ...)Mit MIP-Maps hat das nichts zu tun. Sofern man (in Texturen) den vierten Kanal nicht nutzt (zum Beispiel für Alpha), hat man einfach 8 Füllbits ohne Bedeutung.

YUV ist – wie RGB – ein XYZ-Sytem (die alle mittels Matrizenmultiplikation in ein anderes XYZ-System abbildbar sind), HSL ist ein ganz anderer Farbraum.

sRGB, von dem wir hoffentlich sprechen, setzt als Weißpunkt 6500 K voraus, und stuft die Farben (annähernd) mit eine Gamma-Charakteristik von 2,2 ab.

YUV teilt die Farbe in wahrgenommene Helligkeit, und Rot- und Blau-Differenz auf. Da die Helligkeit in viel höherer Frequenz wahrgenommen wird als Farbe, kann man Y und UV in unterschiedlichen Auflösungen speichern und hat trotzdem noch einen guten Schärfe-Eindruck.

Für einen Menschen viel einfacher zu bedienen ist HSL, weil man so Farbton, Sättigung und Helligkeit direkt einstellen kann. Allerdings sind die Werte nicht auf unsere Wahrnehmung abgestimmt – der gleiche Winkelunterschied im Farbton kann mal mehr, mal weniger auffallen.

CIE-Modelle, CIE Luv und CIE Lab versuchen, den gesamten Farbraum darszustellen, sowie bessere Farbabstands-Berechungen zu ermöglichen.

[Mastermind]

aths[/POST]']Mit MIP-Maps hat das nichts zu tun. Sofern man (in Texturen) den vierten Kanal nicht nutzt (zum Beispiel für Alpha), hat man einfach 8 Füllbits ohne Bedeutung.

YUV ist – wie RGB – ein XYZ-Sytem (die alle mittels Matrizenmultiplikation in ein anderes XYZ-System abbildbar sind), HSL ist ein ganz anderer Farbraum.

sRGB, von dem wir hoffentlich sprechen, setzt als Weißpunkt 6500 K voraus, und stuft die Farben (annähernd) mit eine Gamma-Charakteristik von 2,2 ab.

YUV teilt die Farbe in wahrgenommene Helligkeit, und Rot- und Blau-Differenz auf. Da die Helligkeit in viel höherer Frequenz wahrgenommen wird als Farbe, kann man Y und UV in unterschiedlichen Auflösungen speichern und hat trotzdem noch einen guten Schärfe-Eindruck.

Für einen Menschen viel einfacher zu bedienen ist HSL, weil man so Farbton, Sättigung und Helligkeit direkt einstellen kann. Allerdings sind die Werte nicht auf unsere Wahrnehmung abgestimmt – der gleiche Winkelunterschied im Farbton kann mal mehr, mal weniger auffallen.

CIE-Modelle, CIE Luv und CIE Lab versuchen, den gesamten Farbraum darszustellen, sowie bessere Farbabstands-Berechungen zu ermöglichen.
Heißt das, dass CIE das bestmögliche ist? Oder würdest du sagen, dass man sich als Perfektionist mit 96 Bit RGB begnügen sollte?

[aths]

Mastermind[/POST]']Heißt das, dass CIE das bestmögliche ist? Oder würdest du sagen, dass man sich als Perfektionist mit 96 Bit RGB begnügen sollte?Was ist besser: Apfelsaft oder Kühlflüssigkeit? (Frei nach D. B. Kirk.) Es hängt vom Verwendungszweck ab.

Beispiel: Für Farbsubsampling braucht man einen Yab-artigen Farbraum, da gibt es unter anderem YIC (NTSC), YUV (PAL), YCbCr/YPbPr (JPEG) und andere. (Ein gängiges JPEG-Bild welches z. B. in 1600x1200 vorliegt, speichert nur die Helligkeit in 1600x1200, die Farbe lediglich in 800x600.) Problem beim YCbCr-Farbraum: Nur etwa 1/4 davon liegt im RGB-Würfel. Der Rest ist mit RGB nicht darstellbar (und wird, da JPEG ausgehend von RGB kodiert wird, auch nicht genutzt). Mal stark vereinfacht heißt das, 24 Bit YCbCr entsprechen nur etwa 22 Bit RGB. Das ist auch der Grund, warum man beim JPEG-speichern nicht sicher sein kann, dass ein RGB-Wert exakt gespeichert wird, da sind selbst bei allerbester Qualitätsstufe Abweichungen im Bitbereich möglich.

Als Perfektionist will ich für Gamma-Korrektur und Skalierungsoperationen, dass nicht die 24-Bit-RGB-Daten weiterverarbeitet werden, sondern sozusagen die entpackten JPEG-Daten "mit Nachkommastellen" – und dass endlich mal "gammakorrekte" Skalierung stattfindet (sprich, dass man berücksichtigt dass sRGB die RGB-Werte nichtlinear quantisiert.) Die interne Farbverarbeitung sollte also höher sein als 8 Bit pro Kanal, und man sollte von der Dekomprimierung bis zur Anzeige nicht auf 8 Bit runden. Wenn man dann noch einen besseren Skalierungsalgo als den bilinearen oder bikubischen Filter nimmt, und noch besser gleich in JPEG2000 speichert, hätte man ohne größere Dateien zu bekommen mehr Bildqualität, als man heute gewohnt ist.

Ich kann mir, bis auf ganz ganz wenige Spezialfälle, keine Situationen vorstellen bei der man mit FP16 pro Kanal nicht bestens bedient wäre, wenn es um die Speicherung von Bildern geht. Das wäre dann 48 Bit Farbe. Da man mit FP16 auch negative Werte speichern kann, lassen sich sogar alle wahrnehmbaren Farben speichern (wenn auch nach wie vor nicht anzeigen.) Schon 12 oder gar nur 10 Bit (Fixpoint, aber nach der sRGB-Kennlinie) wäre auch schon ein Fortschritt.

Es gibt keinen "besten" Farbraum. Da aktive Monitore ohnehin Lichtfarben mit den RGB-Grundanteilen mischen, kann man auch gleich in RGB rechnen. Würde man endlich sRGB-Texturen auch für sRGB korrekt filtern, und sich bessere MIP-Algos als den Boxfilter überlegen, sähen Texturen in der 3D-Grafik besser aus, ohne dafür gleich einen anderen Farbraum zu verwenden.

[Mastermind]

aths[/POST]']Was ist besser: Apfelsaft oder Kühlflüssigkeit? (Frei nach D. B. Kirk.) Es hängt vom Verwendungszweck ab.

Beispiel: Für Farbsubsampling braucht man einen Yab-artigen Farbraum, da gibt es unter anderem YIC (NTSC), YUV (PAL), YCbCr/YPbPr (JPEG) und andere. (Ein gängiges JPEG-Bild welches z. B. in 1600x1200 vorliegt, speichert nur die Helligkeit in 1600x1200, die Farbe lediglich in 800x600.) Problem beim YCbCr-Farbraum: Nur etwa 1/4 davon liegt im RGB-Würfel. Der Rest ist mit RGB nicht darstellbar (und wird, da JPEG ausgehend von RGB kodiert wird, auch nicht genutzt). Mal stark vereinfacht heißt das, 24 Bit YCbCr entsprechen nur etwa 22 Bit RGB. Das ist auch der Grund, warum man beim JPEG-speichern nicht sicher sein kann, dass ein RGB-Wert exakt gespeichert wird, da sind selbst bei allerbester Qualitätsstufe Abweichungen im Bitbereich möglich.

Als Perfektionist will ich für Gamma-Korrektur und Skalierungsoperationen, dass nicht die 24-Bit-RGB-Daten weiterverarbeitet werden, sondern sozusagen die entpackten JPEG-Daten "mit Nachkommastellen" – und dass endlich mal "gammakorrekte" Skalierung stattfindet (sprich, dass man berücksichtigt dass sRGB die RGB-Werte nichtlinear quantisiert.) Die interne Farbverarbeitung sollte also höher sein als 8 Bit pro Kanal, und man sollte von der Dekomprimierung bis zur Anzeige nicht auf 8 Bit runden. Wenn man dann noch einen besseren Skalierungsalgo als den bilinearen oder bikubischen Filter nimmt, und noch besser gleich in JPEG2000 speichert, hätte man ohne größere Dateien zu bekommen mehr Bildqualität, als man heute gewohnt ist.

Ich kann mir, bis auf ganz ganz wenige Spezialfälle, keine Situationen vorstellen bei der man mit FP16 pro Kanal nicht bestens bedient wäre, wenn es um die Speicherung von Bildern geht. Das wäre dann 48 Bit Farbe. Da man mit FP16 auch negative Werte speichern kann, lassen sich sogar alle wahrnehmbaren Farben speichern (wenn auch nach wie vor nicht anzeigen.) Schon 12 oder gar nur 10 Bit (Fixpoint, aber nach der sRGB-Kennlinie) wäre auch schon ein Fortschritt.

Es gibt keinen "besten" Farbraum. Da aktive Monitore ohnehin Lichtfarben mit den RGB-Grundanteilen mischen, kann man auch gleich in RGB rechnen. Würde man endlich sRGB-Texturen auch für sRGB korrekt filtern, und sich bessere MIP-Algos als den Boxfilter überlegen, sähen Texturen in der 3D-Grafik besser aus, ohne dafür gleich einen anderen Farbraum zu verwenden.
Das ist alles ganz interessant und in der Praxis hast du wohl recht. Ich werde mal meinen eigentlichen Gedanken etwas umformulieren und deine Ausführungen über Bildkompression aufgreifen:

Eine der wesentlichen Forderungen an die Farbcodierung, völlig egal (!) wofür die Farben codiert werden, ist in meinen Augen, dass der gesammte theoretisch vorhandene Farbraum dargestellt werden kann und zwar vollständig. Das bedeutet für mich, dass man zwischen zwei aneinanderliegenden Farben kaum bis gar keine Nuancen erkennen kann (bei jeder Helligkeit), bei perfekter Darstellung natürlich.
Desweiteren sollte natürlich gewährleistet sein, dass auch die Helligkeit variiert werden kann, wobei man zwischen zwei Stufen fast keinen bis gar keinen Unterschied merkt (bei jeder Farbe).
Dies alles kann man unabhängig vom Monitor sehen, schließlich geht es erstmal darum, wie intern gerechnet wird und das hat möglichst optimal zu erfolgen. Dann kann die Darstellung auch mal vernünftig mit der Qualität des Monitors skalieren.

Konkret erwarte ich, dass ich Bilder und Videos verlustfrei komprimieren kann und dabei die obigen Anforderungen erfüllt werden.

In der Praxis wäre ich persönlich sehr froh, wenn PNGs und MNGs mit entsprechender Unterstützung seitens der Browser endlich Verbreitung finden würden! ;)

Wobei mir da grad eine geniale Idee kommt! Mich würde grad brennend interessieren, welchen Kompressionsgrad man mit MNG und gleicher Bilderrate im Vergleich mit H.264 erreichen könnte, wenn man z.B. einen Film in 720p oder 1080p komprimieren würde. :biggrin:

[del_4901]

1080p gibt es (noch) nicht es gibt blos 1080i

[hofmetzger]

Mastermind[/POST]']
Wobei mir da grad eine geniale Idee kommt! Mich würde grad brennend interessieren, welchen Kompressionsgrad man mit MNG und gleicher Bilderrate im Vergleich mit H.264 erreichen könnte, wenn man z.B. einen Film in 720p oder 1080p komprimieren würde. :biggrin:
B'schissn ums salopp zu sagen. Afaik ist MNG nur die Aneinandereihung von PNGs. Informationsfluss über die Zeit findet nicht statt. Es gibt auch fortgeschrittene Wavelet-basierte Codecs (snow afaik).. aber letztenendes gewinnt bei Doom9 in den Codec-Contests immer "konvetionelle" Technik.

[Gast]

aths[/POST]']Mit MIP-Maps hat das nichts zu tun. Sofern man (in Texturen) den vierten Kanal nicht nutzt (zum Beispiel für Alpha), hat man einfach 8 Füllbits ohne Bedeutung.wobei, wenn man statt einzelner Pixel/Texel eine N*N-Texture als Ganzes betrachtet, die Sache mit den Mipmaps schon Sinn machen würde:
Bei 32 Bit pro Pixel braucht die Texture 32*N^2 Bit Speicherplatz. Werden davon nur 24*N^2 für die Farbinformation genutzt, könnte man hingehen und die verbleibenden 8*N^2 Bit für die Mipmaps nehmen. Jede Mipmap-Stufe hat ja die halbe Kantenlänge der vorherigen und damit ein Viertel der Größe ((N/2)^2), und paßt daher hervorragend in die 8*N^2 = 32*(N/2)^2 Bit.

[Neomi]

Die einzelnen Texel (bzw. Pixel im Framebuffer) müssen gut adressierbar sein (deshalb das Füllbyte) und in einem Block stehen. Deshalb werden sie nicht über die Füllbytes verteilt (das wäre beim Zugriff elendig ineffizient), sondern belegen weiteren Speicher.

[Mastermind]

AlphaTier[/POST]']1080p gibt es (noch) nicht es gibt blos 1080i
Selbstverständlich gibt es 1080p. Völlig unabhängig davon, dass es im Fall von HDTV bisher nicht zum Einsatz kommt, weil es Bandbreitenprobleme gibt. Schau dir einfach mal die ein oder andere HDWMV in diesem Format an, wenn dein Monitor mitmacht. ;)

HDWMV-Beispielvideos KOSTENLOS! (http://www.microsoft.com/windows/windowsmedia/musicandvideo/hdvideo/contentshowcase.aspx)

[Gast]

Mastermind[/POST]']Selbstverständlich gibt es 1080p. Völlig unabhängig davon, dass es im Fall von HDTV bisher nicht zum Einsatz kommt, weil es Bandbreitenprobleme gibt. Schau dir einfach mal die ein oder andere HDWMV in diesem Format an, wenn dein Monitor mitmacht. ;)



was für bandbreitenprobleme? je nach codierung braucht 1080i und 1080p genau gleich viel bandbreite.

[Mastermind]

Gast[/POST]']was für bandbreitenprobleme? je nach codierung braucht 1080i und 1080p genau gleich viel bandbreite.
Ich habe es bereits an mehreren Stellen gelesen. Hier ein Zitat aus Wiki:

"Jede Auflösung, auch 1920 × 1080, kann prinzipiell sowohl mit als auch ohne Zeilensprung übertragen werden. Allerdings übersteigt die Datenmenge von 1080p50 (und -60) das von den eingesetzten Übertragungsverfahren (DVB und ATSC) vorgesehene Maximum."

[Gast]

bei filmen hat man aber in der regel sowieso nur 25fps, also sollte man eher 1080i50 und 1080p25 vergleichen - und da liegt die benötigte bandbreite wohl recht nah beieinander...

[Gast]

Mastermind[/POST]']

"Jede Auflösung, auch 1920 × 1080, kann prinzipiell sowohl mit als auch ohne Zeilensprung übertragen werden. Allerdings übersteigt die Datenmenge von 1080p50 (und -60) das von den eingesetzten Übertragungsverfahren (DVB und ATSC) vorgesehene Maximum."

das ist natürlich richtig, aber normalerweise gehen wir von 1080p@25/30fps bzw. 1080i@25/30fps (bzw. 50/60 halbbilder/s), und da ist die datenrate prinzipiell gleich.

theoretisch sollte 1080p sogar eine leicht höhere kompression bei gleicher qualität zulassen.

[Xmas]

Gast[/POST]']ähm... du meinst damit hoffentlich nicht, daß RGB nur drei Wellenlängen verwenden würde? Das R, G und B sind des RGB-Systems nämlich mitnichten monofrequente Farben. Sonst hättest du in RLZ's Grafik statt der drei breiten, gaußkurvenähnlichen Gebilde nur drei schmale Peaks.
Es gibt ja nicht das RGB-System, aber wenn ich mir die Grafik in DavChrFen's Beitrag anschaue so nutzen zumindest Wide Gamut RGB und CIE RGB doch annähernd reine Spektralfarben als Grundfarben.
Die Grafik von RLZ bedeutet ja nicht dass die Anregung mit drei Farbelementen die genau diese Spektren aufzeigen erfolgen muss.

[haifisch1896]

Mastermind[/POST]']Das klingt logisch und in diese Richtung gingen meine Überlegungen auch.
Dann dachte ich mir, wäre es doch möglich gewesen, dass man dem Monitor das Signal so sendet und im Monitor, wenn es schon aufgrund technischer Umstände RGB sein muss, mit einer sehr hohen Genauigkeit (z.B. 96 Bit) umgerechnet wird. Es ist ja sehr viel Platz in den Röhrenmonis. Da wäre so ein Chip sicher kein Problem gewesen. ;)

Wenn Du ne Grafikkarte kennst, die bei bspw. Doom 3 in 1600x1200 bei 96bit noch Frameraten über 40 fps produziert, wäre das bestimmt machbar.

[Mastermind]

hendrikhey[/POST]']Wenn Du ne Grafikkarte kennst, die bei bspw. Doom 3 in 1600x1200 bei 96bit noch Frameraten über 40 fps produziert, wäre das bestimmt machbar.
:| Das ist doch überhaupt kein Argument!

[Gast]

hendrikhey[/POST]']Wenn Du ne Grafikkarte kennst, die bei bspw. Doom 3 in 1600x1200 bei 96bit noch Frameraten über 40 fps produziert, wäre das bestimmt machbar.

zumindest die x1xxx-serie von ati rechnet intern in doom3 mit 128bpp, die vorgängermodelle mit 96bpp.

[Coda]

Es geht natürlich um die Farbtiefe des Rendertargets. Internere Präzision hat keine Auswirkung auf die Leistung wenn man genügend Transistoren zur Verfügung hat.

[haifisch1896]

Ich geb mich geschlagen. :-)