RAW sRGB vs. AdobeRGB
 

Hi,

mir ist gerade aufgefallen, daß die Bildkontrolle bei der a65 nicht korrekt ist, wenn man als Farbraum AdobeRGB eingestellt hat. Anscheinend vergißt die a65 das Bild für die Darstellung auf dem Display (das vermutlich sRGB hat) zu korrigieren.

Daher 2 Fragen:
1. Wo kann diesen Bug bei Sony melden, damit der vielleicht in einer der nächsten Firmwareversionen gefixt wird?

2. Wie wichtig ist diese Einstellung bei RAW-Dateien? Bei echten HDR-Dateien ist es ja nicht ganz so wichtig, da Werte außerhalb von sRGB einfach höhere Werte als 1.0 (bzw. 255) haben und eine entsprechende Software das korrekt umrechnen kann. Dei RAW habe ich dazu leider noch keine Info zu dem Thema gefunden.

Hat jemand eine Idee?
Viele Grüße
Serenity

Was empfindest du als nicht korrekt? Der Kameramonitor kann, wie viele andere große Monitor auch, AdobeRGB gar nicht darstellen. Insofern ist das ja klar.

Die Kamera verwendet intern und beim RAW das native Kameraprofil und erst bei der Erstellung der JPG oder was immer mußt du das Profil angeben. Und mit diesem Profil wird die Datei dann erstellt. Damit ist die Eisntellung für RAW nicht notwendig und wirkt sich nur aufs JPG aus. Ev. kann die Sony Software das als Voreinstellung übernehmen, aber die verwende ich nicht.

Grundsätzlich hat HDR und Farbraum nichts miteinander zu tun. Der Farbraum gibt nur vor, welche Farben wie abgebildet werden. Bei AdobeRGB sind bestimmte Farben möglich, die außerhalb des sRGB Farbraumes liegen speziell im Grünbereich. Dafür sind aber die Abstände zw. den Farben enger und somit die Differenzierung geringer. Dies lässt sich nur mit einem durchgängigen 16Bit Workflow beheben. Dito ist für WEB dann eine Farbraumkonvertierung notwendig, bei der je nach Auswahl die Farben abgeschnitten, verändert oder nur komprimiert werden.

Den gleichen Fehler hatte schon die A900 (und möglicherweise auch alle Alphas davor, die ich aber nicht alle kenne). Von daher denke ich, es wird sie nicht interessieren. Interessanterweise macht es meine NEX-7 aber richtig ... anderes Entwicklerteam?

Als weiteren Bug würde ich es bezeichnen, daß die Dateien kein eingebettetes Farbprofil haben und die Unterscheidung sRGB/AdobeRGB einfach über den Dateinamen erfolgt.

Irrelevant. Die Einstellung wirkt nur auf die eingebettete JPEG-Vorschau. Für das eigentliche Bild wird der Ausgabefarbraum erst beim Entwickeln im Raw-Konverter festgelegt. Insofern ist es eigentlich Quatsch, an der Kamera AdobeRGB einzustellen, das macht nur Probleme.

Ich kann mich nicht mehr an die Diskussion erinnern ;-) Wie äusserte sich das? Ich habe sie immer auf sRGB stehen.

Vielleicht vorab: Ich kenne mich mit Farbprofilen generell sehr gut aus, da ich den Umgang und eine komplette Farbpipeline in einer Software schon implementiert habe und mich dementsprechend sehr intensiv mit dem Thema auseinandergesetzt habe.

Daß Farbraum und HDR grundsätzlich erstmal nichts miteinander zu tun haben ist klar, zumal das HDR-Format gar keine Farbprofile unterstützt. Aber auch ein HDR-Bild besteht nur aus 3 Farben (RGB) und man muß wissen, was diese 3 Farben bedeuten. In einem HDR-Bild steht beispielsweise für einen Wert (1.0, 0.5, 0.2). Dadurch weiß man aber erstmal gar nichts darüber, welche Farbe das ist. Erst ein Farbprofil gibt diesen Werten eine gewisse Bedeutung.
Im Vergleich zum JPG ist es aber nicht so dramatisch. Bei JPG hat ein Farbkanal nur 8 Bit, sprich 255 Werte. Ist das JPEG mit AdobeRGB erstellt und hat beispielsweise einen Wert von (0, 255, 0), dann wäre die entsprechende Farbe im sRGB Farbraum vielleicht etwas wie (0, 280, 0). 280 ist aber mit 8 Bit nicht mehr speicherbar, die Farbe ist also mit einem sRGB-JPEG nicht mehr darstellbar.
Beim einem HDR gibt es das Problem nicht, hätte das HDR AdobeRGB Farben (0.0, 1.0, 0.0) dann wäre das mit sRGB einfach etwa (0.0, 1.1, 0.0). Das meine ich mit damit, daß es bei HDRs keine ganz so dramatische Rolle spielt, zumindest was die darstellbaren Farben angeht. Ein anderes (leider nicht gelöstes Problem) sind die Primärvalenzen, die einen Anhaltspunkt liefern, wie denn die RGB-Farben zu interpretieren sind um damit die Farben des vollen Farbspektrums des Lichts anzunähern. Aber das ist eine anderes Thema, das leider weit komplexer ist.

Aber zu dem, was ich erwarten würde:

Ein korrekt arbeitendes System würde das Farbprofil der Bilddatei (JPG oder halt RAW) auslesen und zur Darstellung in das Farbprofil des Displays konvertieren, damit die Farben korrekt dargestellt werden. Farben, die vom Display nicht dargestellt werden können, müssen dabei natürlich entsprechend behandelt werden, im einfachsten Fall werden die dann einfach geclamped aber es gibt auch andere Möglichkeiten, die den Farbeindruck so gut wie möglich versuchen zu erhalten.
Genau das wird aber bei der Bildbetrachtung in der Kamera nicht gemacht, die RGB-Werte werden anscheinend einfach ans Display geschickt und die dargestellten Farben sind im Fall von AdobeRGB dann entsprechend völlig falsch, weil das Display eher den sRGB-Farbraum abbildet.

Bei RAW bin ich noch am Zweifeln was genau das RAW-Format speichert. Wenn es natürlich wirklich einfach die Sensordaten abspeichert und intern ein entsprechendes Farbprofil des Sensors hinterlegt hat, so daß die Sensordaten dann bei der Darstellung entsprechend nach sRGB oder AdobeRGB oder was auch immer konvertiert wird, dann wäre das natürlich super.

Mmhhh, klingt ja nicht sehr ermutigend. :( Vieleicht sollte ich mal ein paar Sony-Leute auf der Photokina damit nerven ;)

Ernsthaft? Da ich nur RAW photographiere ist mir das noch gar nicht aufgefallen. Wäre ja ein echtes Armutszeugnis.

Das klingt beruhigend, dann würde ich das einfach auf sRGB setzen und gut ist.

Was du schreibst, hat wieder mit HDR nur indirekt zu tun. Auch eine 16Bit Abbildung würde im Farbraum sRGB eine Farbe, die nur im AdobeRGB darstellbar ist, außerhalb des Zahlenraum kodieren und damit abschneiden.
Du meinst, wen ich dich richtig verstehe, das ein 8Bit sRGB im 16Bit Zahlenraum kein Problem ist. Das gibts aber nicht.
RAW hat den 16Bit Zahlenraum und dann dadurch fast alle Farbräume korrekt abdecken. Der native Farbraum ist ja größer als sRGB und AdobeRGB.

Aber zurück zur Kamera:
1) Einstellung auf sRGB und du hast die Probleme nicht. Außer du brauchst diese speziellen Farben. Dann RAW und als 16Bit im AdobeRGB ausgeben.
2) Wenn das AdobeRGB Bild an den Monitor geschickt wird, kann er nur eine Farbraumumrechnung machen. Vermutlich wäre perzeptiv sinnvoll, aber nicht in jedem Fall. Aber da wird je auch nur der Eindruck halbwegs bewahrt, spezielle Farben wie violett sind trotzdem rot. Aber ich teile deine Ansicht, dass Sony sich das spart und einfach aus dem RAW irgendwas hinschicke und das dürfte wohl das eingebettete JPG mit sRGB sein. Nur bei der Qualität des Monitor irgendwo im undefinierten Umgebungslicht wäre das wohl wahrscheinlich eh übertrieben.

Naja, sie halten sich prinzipiell an den DCF-Standard. Der schreibt nur vor, daß Bilddateien im AdobeRGB-Farbraum einen Dateinamen mit "_" am Anfang haben müssen, mehr nicht. Es wäre natürlich sinnvoll, trotzdem ein Farbprofil mitzuliefern, denn einen Bildbetrachter oder Webbrowser interessiert die Konvention bei der Namensgebung erst mal nicht, und spätestens wenn man die Datei mal umbenennt, wäre die Information halt weg.

Es gibt zwar noch ein Farbraum-Flag in den Exif-Daten, das sagt aber nur, ob es sRGB oder nicht sRGB ist – letzteres könnte ohne Farbprofil dann natürlich alles Mögliche sein.

Im Prinzip ja. Die Raw-Daten enthalten allerdings kein Sensorprofil, das muß der Raw-Konverter selber kennen. Deswegen braucht man für jede neue Kamera ein Software-Update. Und in der Regel dauert das eine Weile, weil die Sensoren erst von den Herausgebern der Software im eigenen Labor vermessen und die neuen Profile erstellt werden müssen.

Das eingebettete JPEG ist dann in AdobeRGB, es wird aber so behandelt, als wäre es sRGB. Deswegen sind auf dem Display alle Farben falsch, nicht nur die "out of gamut". Das irritiert halt ein wenig, selbst wenn man zu Gute hält, daß das Kameradisplay eh nicht kalibriert ist.

Da mir aber kein sinnvoller Grund einfällt, warum ich die Kamera auf AdobeRGB stellen sollte, kann ich mit den Bugs leben.

Ein Grund fällt mir ein.
http://www.luminous-landscape.com/tu...ht-hista.shtml

Ich bezweifle, daß das auf jede x-beliebige Kamera übertragbar ist. Insbesondere wenn sie bekanntermaßen ein Problem damit hat, AdobeRGB überhaupt korrekt darzustellen.

Zur Unterstützung von RAW gibt es bei Sony ja extra den Kreativmodus "neutral" (bei den größeren Kameramodellen zumindest).

Das was ich geschrieben habe ist korrekt, es geht nicht um 8 Bit Integer im Vergleich zu 16 Bit Integer sondern um 8 Bit Integer gegen 16 oder 32 Bit Floating Point (aka HDR).
Bei 16 Bit Integer hast Du Recht, wenn bei JPEG 0 = 0% und 255 = 100% entspricht, dann ist das bei 16 Bit Integer 0 = 0% und 65536 = 100%. Bei HDR (und damit meine ich echtes HDR, sprich .EXR oder 32 FP Tiff oder meinetwegen auch das RGBE-Format der .HDR Dateien) ist das aber anders, das sind floating point Werte wo gilt 0.0 = 0%, 1.0 = 100%, 2.0 = 200% usw. Damit sind alle Farben abbildbar, egal welcher Farbraum. Der Farbraum beschreibt hier lediglich, welche Farbe denn genau mit 100% gemeint ist. Ist eine Farbe außerhalb des Farbraums, dann ist sie mit HDR immer noch abbildbar, die Werte liegen nur nicht mehr zwischen 0 und 1.


Naja, RAW deckt das ab, was der Sensor aufnehmen kann, das heißt nicht, daß das zwangsläufig größer ist als sRGB oder AdobeRGB, auch wenn das in der Praxis sicherlich so sein wird. Ich glaube man kann sich das RAW-Format wie einen simplen Photonenzähler vorstellen, der bis 65535 zählen kann. Poor-Man´s HDR stimmt also schon, sonst würden Sachen wie Expose-to-the-right gar nicht funktionieren.

Das war ja eigentlich die Frage: Spielt das bei RAW überhaupt eine Rolle? Meine Vermutung ist mittlerweile "nein", da RAW ja nur einfach ein Dump der Sensordaten sein sollte. Die werden dann von der Software am Rechner in das Farbsystem konvertiert, das man der Software sagt, kann also auch was anderes wie z.B. eciRGB sein.

Das ist eigntlich gar nicht so schwer:
AdobeRGB Eingabedatei->inverses AdobeRGB Gamma->linear AdobeRGB nach XYZ->XYZ
nach linear sRGB->sRGB Gamma->Displaydarstellung

Dadurch werden alle Farben, die von sRGB dargestellt werden können korrekt dargestellt. Farben die außerhalb des darstellbaren Bereichs liegen können natürlich nicht dargestellt werden und müssen irgendwie behandelt werden, am einfachsten durch Clampen der Werte.

Warum soll das HDR da eine Rolle spielen? Ich gehe mal nicht davon aus, dass die Kameras intern ein 32 Bit Format erstellt und dann mit Tonemapping ein 8 Bit. Da eher schon, dass die die 2 16 Bit Bilder mit Fusion verrechnet und daraus dann ein 8 Bit erstellt und das alles im jeweiligen Farbraum dazugibt. Aber davon hängt die Theorie ab.

Spielt keine Rolle, aber es ist auch kein Dump. Allein schon dadurch, dass DRO in der kleinsten Einstellung auch das RAW beeinflusst.

Von dem abgesehen, dass wir nicht wissen, woher sie was verarbeiten, gibt es 4 Rending Indents, je nach Anforderungen und dann sind aber schon bei einem ordentlichen Farbmanagement in der Kamera. Wenn sowas notwenig ist, dann gibts ja die Tethering Lösung z.B. bei A900 oder über Eye-Fi auf einen kalibrierten Monitor.

Aber unabhängig davon sind das natürlich schon Eigenheiten, die am Anfang nerven, die aber letztlich dann mit Erfahrung in den Griff kommen. Denke auch an die DRO Falle ;-)

Hä? Darum ging es doch gar nicht. HDR (im Sinn von einem echtem High-Dynamic-Range Format, nicht diesen PseudoHDR-Schrott den die Kamera intern erzeugt) hab ich nur erwähnt, weil bei einem echten HDR der Farbraum keine so große Rolle spielt, da mit einem HDR alle irgendwie mit RGB abbildbaren Farben dargestellt werden können, egal ob sRGB, AdobeRGB oder sonst was.
Die Frage war nur was bei RAW geschieht. Wird da was umgewandelt und hat die sRGB/AdobeRGB Einstellung einen Einfluß auf die Werte, die im RAW-File stehen oder nicht.

Was den Rendering Intent angeht: Klar, eine komplette Unterstützung wäre super, für 99% reicht aber die einfache Variante zur Darstellung auf dem Display vollkommen aus.

Hi,

den ganzen Tread finde ich schierig. Verstehe ich teilweise nicht.

Mir geht es nur um "den Teil" - ob das Kameradisplay wirklich prinzipiell überhaupt andere Farben zeigt, - wenn man den Farbraum statt sRGB auf AdobeRGB stellt.

Der kleinere sRGB Farbraum ist doch ein Teilbereich vom großen AdobeRGB. Wenn das Kamera Display nicht alle Farben "korrekt" anzeigen kann, wird es diese natürlich trotzdem anzeigen.

Warum soll das Display AdobeRGB Bilder falsch bzw. anders darstellen als direkt sRGB?

Weil die "Umrechnung" von AdobeRGB zu sRGB für das Display wirklich Farben zeigt, welche sichtbar anders als das direkte sRGB Signal sind?

Und das soll man sehen?

LG

uli

Moin, moin,

die Aussage finde ich gewagt. Egal wie viele Bits für eine Integer- oder Floating Point-Darstellung verwendet werden, der Wertebereich ist endlich und damit auch die Anzahl Farben, die durch die Binärwerte dargestellt werden können. Ist die Anzahl Farben auch endlich?


Dat Ei

Das Display kann da nix für. ;) Das Ganze ist viel einfacher.

Wir haben es insgesamt mit vier verscheidenen Farbräumen zu tun:

1. Der Sensorfarbraum (geräteabhängig)
2. sRGB (geräteunabhängig, IEC-Standard)
3. AdobeRGB (geräteunabhängig, Adobe-Standard)
4. Der Displayfarbraum (geräteabhängig)

Wenn du jetzt ein Bild aufnimmst, rechnet die JPEG-Engine der Kamera den Sensorfarbraum [1] in einen der beiden geräteunabhängigen Farbräume [2] und [3] um, je nach Einstellung. Dafür gibt es zwei genau definierte Umrechungsfunktionen, eine für [1] → [2] und eine für [1] → [3].

Um das Bild auf dem Display anzuzeigen, muß umgekehrt der geräteunabhängige Farbraum [2] bzw. [3] aus der JPEG-Datei in in den geräteabhängigen Farbaum [4] des Displays umgerechnet werden. Auch dafür gibt es zwei genau definierte Umrechnungsfunktionen, eine für [2] → [4] und eine für [3] → [4].

Der Fehler ist jetzt, daß bei im AdobeRGB-Farbraum gespeicherten Bildern nicht die zweite Umrechnungsfunktion verwendet wird, sondern die erste, die eigentlich für sRGB gedacht ist.

Nein. Beide enthalten jeweils genau 16777216 Farben. Nur die Abstände zwischen den Farben sind bei AdobeRGB größer. Wahrscheinlich sind 100% schwarz (0,0,0) und 100% weiß (255,255,255) die einzigen Farben, die in beiden Farbräumen übereinstimmen.

:shock: Bei so einer Korinthenkackerei weiß ich gar nicht, was ich darauf noch antworten soll.

Ja, toll, Farben die bei einem 16 Bit Bild im AdobeRGB-Farbraum dargestellt werden können, können vielleicht nicht zu 100% mit einem 16 Bit sRGB Bild dargestellt werden. Mit einem 32 Bit sRGB Bild kann man sie aber wiederum darstellen.

Abgesehen davon ist das Thema für mich erledigt, schließlich ging es hier um RAW bzw. die fehlerhafte Darstellung des Vorschaubildes, wenn man AdobeRGB eingestellt hat.

Auch wenn du jetzt grantig wirst, aber tritt einfach mal einen Meter zu Seite. Von wegen Leitung.
Du kannst unabhängig vom Zahlensystem in einem Farbraum nur die dort definierten Farben darstellen. Basta. Mit größeren Zahlen kannst du zwischen den Farben besser differenzieren. Das ist einfach die Definition von einem Raum. Du kannst auch in einem Raum nicht durch die Wand sehen, wenn du mm statt cm verwendest.

Das RAW hat einen eigenen Farbraum, der durch das Gerät definiert ist. Und der ist im konkreten Fall bei den SLT größer als der sRGB und AdobeRGB. Deshalb kannst du diese beiden auch auswählen und die Kamera/Software macht dann die passende Farbraumkonvertierung.

Daher nochmals, die Einstellung ist für RAW absolut egal.

Und genau diese Annahme ist falsch. Ok, sie sind nicht mehr "offiziell definiert", aber sie sind mit Werten darstellbar, sprich die Umrechnung von sRGB nach AdobeRGB und umgekehrt ist ohne Verlust möglich solange man nicht anfängt irgendwelche Werte zu clampen. Natürlich bedeutet das, daß man bei der Umrechnung von AdobeRGB nach sRGB Werte über 1 oder sogar Werte unter 0 bekommen kann, da der AdobeRGB-Farbraum einen größeren Definitionsbereich hat. Strikt nach der Definition genommen sind die Farben von dem Farbraum also "nicht darstellbar". Mathematisch sind aber in beiden Farbräumen alle Farben des jeweiligen anderen Farbraums abbildbar und man kann beliebig hin und her konvertieren ohne auch nur den geringsten Verlust (ist schließlich nur eine Matrizenmultiplikation. In mit 32Bit Float sind die Verluste, die durch eine eventuelle Konvertierung entstehen so gering, daß sie in der Praxis keine Rolle spielen.

Entschuldige, daß ich Dich beim Wort genommen habe.

Das sehe ich nicht so, denn der Gamut des Adobe RGB geht über die Grenzen des Gamut des sRGBs hinaus, d.h., daß es Farben innerhalb des AdobeRGB-Gamuts gibt, die unabhängig von der Bittiefe immer außerhalb des sRGB-Gamuts liegen werden. Die Bittiefe entscheidet nur über den Differenzierungsgrad innerhalb eines Gamuts.


Dat Ei

Klar wäre es so möglich, wenn die Definition dies nicht anders vorsehen würde. Dann könnte man natürlich einen sRGB Farbraum machen, der über die Grenzen hinaus läuft und die AdobeRGB Farben darstellbar macht und dafür 10Bit braucht. Und dann speicherst du das in JPG 8Bit und fertig. Könnte man, aber sinnhaft?

Deshalb nimmt man ja das Device Profil und erstellt bei der Ausgabe das File im Wunschfarbraum. Und danach ist es faktisch nur mehr verlustbehaftet zu konvertieren.

Naja, ich komme ja eigentlich aus dem Renderingbereich, da rechnet man immer mit 32Bit Floating Point und man benötigt zwingend Werte die außerhalb des definierten Farbraums liegen.

Ob es sinnvoll ist oder nicht? Naja, wäre es nicht sinnvoll, dann gäbe es gar keine HDR-Dateien im RGB-Format, dort sind die Werte praktisch ständig deutlich größer als 1.0. Alternative wäre dann nur der XYZ-Farbraum, was ja auch wunderbar wäre für ein Dateiformat, aber Rechnen macht damit nicht so wirklich Spaß. Aber ohne Farbraum wüßte man nicht mal annähernd welcher Farbe denn nun ein RGB-Wert entspricht.

Insofern: Ja es ist sogar sehr sinnvoll Farben außerhalb des definierten Bereichs zu haben.

Vielleicht nochmal zum besseren Verständnis warum auch im sRGB-Farbraum AdobeRGB Farben dargestellt werden können, wenn man die Werte nicht auf den 0-1 Bereich beschränkt:

Standarddarstellung für Farbräume ist diese, CIE xy Chromazitätsdiagram:

http://www.gamutvision.com/docs/imag...Adobe_sRGB.jpg

Das kleiner Dreieck entspricht sRGB, das größere entspricht AdobeRGB. Man sieht also sehr schön, daß besonders im grünen Bereich der AdobeRGB-Farbraum mehr Farben abdeckt.
Was man auch sieht: Beide Farbräume können mit einem Dreieck dargestellt werden.

Ein Dreieck spannt immer eine Ebene auf. Ein beliebiger Punkt in dieser Ebene kann durch die Linearkombination der 3 Eckpunkte des Dreiecks beschrieben werden. Also sagen wir die Ecken des sRGB Dreiecks heißen A, B und C. Dann kann jeder beliebige Punkt in der Dreiecksebene beschrieben werden als

P = w * A + u * B + v *C

Farben innerhalb des sRGB Dreiecks haben lediglich die Einschränkung daß u > 0.0, v > 0.0, u + v <= 1.0 und w = 1.0 - u - v ist. Hebt man diese Einschränkung auf, dann ist auch jeder Punkt innerhalb des AdobeRGB-Dreiecks mit diesen Stützpunkten beschreibbar und somit darstellbar, ebenso wie jeder andere Punkt auf diesem Chromazitätsdiagramm.
Bei HDR-Dateien gibt es eben diese Einschränkung auf den 0-1 Bereich nicht, so daß man alle Farben darstellen kann und Farbräume deshalb nicht dieselbe Wichtigkeit haben wie es bei beispielsweise bei JPG der Fall ist. Man braucht sie immer noch um die richtige Zuordnung der Werte vornehmen zu können, aber grundsätzlich sind alle Farben in einem HDR gespeichert, wie ich ja schon am Anfang sagte.

Bei RAW-Dateien war mir das nicht so klar, da die Werte ja noch immer auf den 0-1 Bereich beschränkt sind. Der Unterschied zu JPG ist hier vor allen Dingen wohl, daß die Farben mit linearem Gamma und nicht mit den in sRGB bzw. AdobeRGB definierten Gammaverläufen gespeichert sind. Außerdem haben sie natürlich ihren eigenen Farbraum (den des Sensors) und deshalb spielt die sRGB bzw. AdobeRGB Einstellung keine Rolle beim RAW.
Dieser Punkt mußte mir halt erstmal klar werden, deshalb hatte ich gefragt. Und daß die Kamera AdobeRGB JPEGs falsch anzeigt ist ja nun auch geklärt, mal sehen ob ich bei der Photokina einen Sonymenschen mal darauf ansprechen kann.