[Serenity1]

Zitat von mrieglhofer

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.

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.

Zitat von mrieglhofer

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.

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.

Zitat von mrieglhofer

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.

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.

Zitat von mrieglhofer

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.

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.

[mrieglhofer]

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.

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.

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

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

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

[Serenity1]

Zitat von mrieglhofer

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.

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.

[swivel]

Zitat von usch

...
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, ...
Da mir aber kein sinnvoller Grund einfällt, warum ich die Kamera auf AdobeRGB stellen sollte, kann ich mit den Bugs leben.

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

[Dat Ei]

Moin, moin,

Zitat von Serenity1

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.

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

[usch]

Zitat von swivel

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

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.

Zitat von swivel

Der kleinere sRGB Farbraum ist doch ein Teilbereich vom großen AdobeRGB.

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.

[Serenity1]

Zitat von Dat Ei

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.

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.

[mrieglhofer]

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.

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.

[Serenity1]

Zitat von mrieglhofer

Du kannst unabhängig vom Zahlensystem in einem Farbraum nur die dort definierten Farben darstellen. Basta.

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.

[Dat Ei]

Zitat von Serenity1

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

Entschuldige, daß ich Dich beim Wort genommen habe.

Zitat von Serenity1

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.

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