16bit TIFF vs. RAW

[jo59]

Irgendwie kommt mir Eure Diskussion komplett am Thema vorbei vor.

Wenn ich ein RAW (Foveon-Sensor ausgenommen) mit einem TIFF inhaltlich vergleichen möchte, dann vergleiche ich die sprichwörtlichen Äpfel und Birnen.

Im RAW ist für jedes Pixel nur ein Farbwert für Rot, Grün, oder Blau enthalten. Dabei ist es erstmal vollkommen egal, ob mit 10, 12, oder auch 14 Bit aufgelöst wird.

Nach dem RAW kommt dann der Interpreter und “erfindet“ zu jedem echten (gemessenen) Farbwert eines Pixels anhand von Algorithmen aus den umgebenden Pixeln die beiden jeweils fehlenden Farbwerte dazu, um daraus eine resultierende „Ergebnisfarbe“ zu erzeugen, die dann in einem (3 mal) 16-Bit-TIFF (pro Pixel) abgespeichert werden kann.
Somit ist im TIFF schonmal Zweidrittel erfundene „Farbangabe“ enthalten und die Dateigröße wächst auf über das dreifache.

Es wird doch nun niemand behaupten wollen, dass die dazuinterpretierten „Farbanteile“ keinerlei Auswirkung auf eine Weiterbearbeitung haben, deren eigentlicher Zweck eine andere Farbdarstellung (also andere Interpretation des RAWs) ist…

 

[RobiWan]

Irgendwie kommt mir Eure Diskussion komplett am Thema vorbei vor.

yep, siehe #13

Im RAW ist für jedes Pixel nur ein Farbwert für Rot, Grün, oder Blau enthalten. Dabei ist es erstmal vollkommen egal, ob mit 10, 12, oder auch 14 Bit aufgelöst wird.

Zumindest in der Theorie ist das allerdings nicht richtig. Ob man jetzt immer also bei jedem Bild die Unterschiede sehen kann sei dahin gestellt. Besser im Sinne von Farbvielfallt kann ein 10 Bit RAW nicht sein als ein 14 Bit RAW.

 

[ewm]

...Im RAW ist für jedes Pixel nur ein Farbwert für Rot, Grün, oder Blau enthalten. Dabei ist es erstmal vollkommen egal, ob mit 10, 12, oder auch 14 Bit aufgelöst wird...

Du behauptest ernsthaft, dass es egal ist, ob pro Pixel 1024, 4096 oder 16484 Helligkeitswerte für die Weiterverarbeitung vorliegen

Sorry, aber mit dieser Aussage qualifizierst Du Dich mir gegenüber nicht gerade für weitere Diskussionen zum Thema RAW-Entwicklung

Mag sein, dass das andere anders sehen. Meiner Meinung nach ist diese Aussage absolut falsch!

....Es wird doch nun niemand behaupten wollen, dass die dazuinterpretierten „Farbanteile“ keinerlei Auswirkung auf eine Weiterbearbeitung haben, deren eigentlicher Zweck eine andere Farbdarstellung (also andere Interpretation des RAWs) ist…

Das ist aber so und wohl kaum nicht zu verhindern.

Es sei denn, man schaut sich das RAW z.B. mit dem RAWDigger an.

Nur dürfte das nicht im Sinn des Bildbearbeiters sein

Also muss das RAW entwickelt werden, um es zu bearbeiten.

Ist das jetzt eine sooooo neue Erkenntnis

Wenn ja, dann bin ich hier raus

 

[Blants]

@ewm: Du bist bei deinen Betrachtungen weiter oben immer davon ausgegangen, dass die Farbwerte im Raw und im Tiff im gleichen Raum gegeben sind, also beide linear. Wenn es so wäre, stimme ich dir zu, 12- bzw. 14-Bit-Farbwerte können dann verlustfrei in 16 Bit gespeichert werden.

Aber was, wenn das Tiff nicht mehr linear ist? Unser Auge ist auch nicht linear, es wäre (für ein Endformat) Platzverschwendung die Farbwerte linear zu speichern. Für unsere Wahrnehmung ist es geschickter, die Werte so zu speichern, dass wir eine Verdopplung des Werts auch als doppelt so hell wahrnehmen würden. Und das ist etwas anderes als eine Verdopplung der physikalischen Lichtintensität.

Wenn das Tiff also eine logarithmische Skala hätte, dann wären die Helligkeitsintensitäten nicht mehr gleichmäßig verteilt (wie beim Raw) und du hättest dann im oberen Bereich eine niedrigere Farbauflösung als im unteren Bereich. Evtl. reichen dann selbst die 2 zusätzlichen Bit nicht mehr aus, um die Informationen aus dem Raw zu speichern (jedenfalls bei den hellen Bereichen).

Ich weiß allerdings nicht, wie die Daten im Tiff genau kodiert sind, insofern kann ich nicht sagen, ob das wirklich das ist, was bei User scarl passiert ist, aber zumindest könnte ich mir so die beschriebenen Symptome erklären.

 

[ewm]

...Ich weiß allerdings nicht, wie die Daten im Tiff genau kodiert sind, insofern kann ich nicht sagen, ob das wirklich das ist, was bei User scarl passiert ist, aber zumindest könnte ich mir so die beschriebenen Symptome erklären.

Es ist meiner Meinung nach für den Erhalt der Informationen und damit für die Reserven zur Nachbearbeitung egal, mit welchem (Gradations)Kurve die Helligkeitsinformation im Tiff gespeichert ist, solange kein Clipping auftritt, also Helligkeitswerte am unteren und oberen Ende abgeschnitten werden.


Diese Bedingung einzuhalten obliegt dem Nutzer des RAW-Konverters. Solange man darauf achtet, dass kein Clipping auftritt, sollten alle Werte zur Verfügung stehen.

Im Übrigen stellen auch der RAW-Konverter + der (kalibrierte) Monitor (Stichwort Gamma) selbst den Helligkeitsverlauf angepasst ans menschliche Auge dar.

Ich sehe da keinen grundsätzlichen Unterschied zwischen dem entwickelten RAW und auf dem Monitor dargestelltem RAW und dem daraus entwickelten Tiff.

Ohne Clipping bei der Entwicklung des RAWs und der Tiff-Ausgabe sollten in beiden Fällen die gleichen Reserven im Bereich der Lichter und Schatten vorhanden sein.

Bei extremer Fehlbelichtung kann es natürlich sein, dass schon im RAW von den z.B. möglichen 12Bit deutlich weniger Bit mir Information "besetzt" ist. Dann kann es vorkommen, dass bei der im RAW-Entwickler vorgenommenen "Anpassung ans Auge" in bestimmten Helligkeitsbereichen zu wenig Helligskeitsstufen vorliegen und es zu Tonwertabrissen (Banding) kommt.

Aber in so einem Fall ist es meiner Meinung nach egal, ob man versucht, die Fehlbelichtung bei der Entwicklung des RAWs oder bei der Nachbearbeitung des Tiffs zu korrigieren.

Letztlich muss man immer vor Augen haben, dass man der RAW-Entwickler uns auf dem Monitor nicht das RAW, sondern das entwickelte Foto zeigt.

Das unbearbeitete RAW eines Sensors mit vorgeschalteter Filtermatrix ist immer ein Zwischenprodukt, mit dem wir eigentlich visuell nichts anfangen können. Es bedarf immer einer "Entwicklung".

Gruß
ewm

 

[scorpio]

Dem TO ging es aber auch um den Weißabgleich, nicht nur um Helligkeitswerte.

Dabei ist mir aufgefallen das die weitere Bearbeitung des Tiffs weniger Spielraum beim Weißabgleich und Helligkeitskorrektur bietet.

Wir hatten diese Diskussion übrigens schon einige Mal. z.B.
https://www.dslr-forum.de/showthread.php?t=455898
https://www.dslr-forum.de/showthread.php?t=1114946
https://www.dslr-forum.de/showthread.php?t=1650465

 

[ewm]

Dem TO ging es aber auch um den Weißabgleich, nicht nur um Helligkeitswerte. ...

Der Weißabgleich ist doch lediglich eine Verschiebung der Helligkeitswerte der 3 Farbenverläufe gegeneinander.

Auch hier sehe ich keinen Unterschied zwischen dem RAW-Entwickler, der ja das RAW auch in ein 3farbiges Bitmap zur Anzeige auf dem Monitor umwandeln muss und dem dann später exportierten Bitmap als verlustfreies Tiff, solange die schon diskutierten Voraussetzungen (kein Clipping, entsprechender Farbraum,...) eingehalten werden.

...Wir hatten diese Diskussion übrigens schon einige Mal. z.B.
https://www.dslr-forum.de/showthread.php?t=455898
https://www.dslr-forum.de/showthread.php?t=1114946
https://www.dslr-forum.de/showthread.php?t=1650465

Danke für die Links

Die werde ich mir sehr gern in Ruhe durchlesen.

Ich glaube aber nicht, dass sich dadurch an meiner Sicht etwas ändert.

Diese habe ich hier ausführlich dargestellt und es gibt meinerseits derzeit nichts mehr zum Thema beizutragen.

Gruß
ewm

 

[jo59]

Du behauptest ernsthaft, dass es egal ist, ob pro Pixel 1024, 4096 oder 16484 Helligkeitswerte für die Weiterverarbeitung vorliegen

Das habe ich so nicht geschrieben… Meine Aussage war, dass die Auflösung der Helligkeitswerte für die Grundbetrachtung RAW - TIFF erstmal vernachlässigt werden kann. Ich habe nicht behauptet, dass 10, 12, oder 14 Bit keinen qualitativen Unterschied beinhalten.

Sorry, aber mit dieser Aussage qualifizierst Du Dich mir gegenüber nicht gerade für weitere Diskussionen zum Thema RAW-Entwicklung

Eventuell solltest Du meinen Beitrag nochmal lesen und versuchen zu verstehen, was die Aussage war.

Mag sein, dass das andere anders sehen. Meiner Meinung nach ist diese Aussage absolut falsch!

Aber nur, weil Du mit Deiner Ausgangsmeinung an meine Aussage rangegangen bist, ohne dabei die angesprochenen Tatsachen zu berücksichtigen.

Das ist aber so und wohl kaum nicht zu verhindern.

Es sei denn, man schaut sich das RAW z.B. mit dem RAWDigger an.

Wo Du Recht hast, hast Du Recht.

Nur dürfte das nicht im Sinn des Bildbearbeiters sein

Also muss das RAW entwickelt werden, um es zu bearbeiten.

Genau hier setzt der Unterschied zwischen unseren Betrachtungsweisen an.

Das TIFF ist schon interpretiert und wird aus dem interpretierten Zustand weiterbearbeitet.

Beim RAW wird wird schon die Interpretation bearbeitet.

Ist das jetzt eine sooooo neue Erkenntnis

Wenn ja, dann bin ich hier raus

Ewm - ich schätze im Allgemeinen Deine ruhige nüchterne Art Dinge zu betrachten. Auch Dein Wissen möchte ich nicht anzweifeln.

Trotzdem gibt es meist mehrere Arten, wie man Dinge beurteilen kann und in diesem Fall sehe ich halt eine ganz unterschiedliche Ausgangssituation zwischen RAW und TIFF…

 

[maxRAW]

Hört doch auf damit, es ist nutzlos Meinungen ohne tatsächlichen sachlichen Beweis als diskussionswürdigen Fakt betrachten zu wollen.

 

[ewm]

... Genau hier setzt der Unterschied zwischen unseren Betrachtungsweisen an.

Das TIFF ist schon interpretiert und wird aus dem interpretierten Zustand weiterbearbeitet.

Beim RAW wird wird schon die Interpretation bearbeitet. ...

Stimmt.

Aber woraus wurde den das Tiff des TO erzeugt. Ich habe es so verstanden, dass es aus dem RAW erzeugt wurde.

Und solange man im RAW nichts "wegschnippelt", werden die Daten auch im Tiff bearbeitet werden können.

... Trotzdem gibt es meist mehrere Arten, wie man Dinge beurteilen kann und in diesem Fall sehe ich halt eine ganz unterschiedliche Ausgangssituation zwischen RAW und TIFF…

Ich nicht. Jedenfalls nicht bei den Lichtern, Schatten und dem Weißabgleich.

Dass schon ins RAW-Demosaicing eingegriffen wird, streite ich nicht ab.

Entrauschen per DXO DeepPrime ist da ein Beispiel.

Dass allgemeine Helligkeits-/Kontrast-/usw. Korrekturen in die Interpolation der RAW-Daten beim Demosaicing der Bayer- oder X-Trans-Matrix eingehen, dass zweifele ich aber stark an.

Aber für die Genauigkeit der Interpolation ist es schon entscheidend, ob die Daten in 10, 12 oder 14 Bit vorliegen. Insbesondere bei falsch belichteten Fotos oder Fotos unter ungewöhnlichen Beleuchtungssituationen. Da bleibe ich bei meiner Kritik Deiner oben beschriebenen Sichtweise..

Gruß
ewm

 

[jo59]

…
Aber für die Genauigkeit der Interpolation ist es schon entscheidend, ob die Daten in 10, 12 oder 14 Bit vorliegen. Insbesondere bei falsch belichteten Fotos oder Fotos unter ungewöhnlichen Beleuchtungssituationen. Da bleibe ich bei meiner Kritik Deiner oben beschriebenen Sichtweise..

Das habe ich doch gar nicht behauptet. Ich schrieb:

Das habe ich so nicht geschrieben… Meine Aussage war, dass die Auflösung der Helligkeitswerte für die Grundbetrachtung RAW - TIFF erstmal vernachlässigt werden kann. Ich habe nicht behauptet, dass 10, 12, oder 14 Bit keinen qualitativen Unterschied beinhalten.

Wo siehst Du einen Unterschied zwischen den Aussagen?

 

[ewm]

...Wo siehst Du einen Unterschied zwischen den Aussagen?

Sorry, Du hast natürlich recht. Du hats ja nicht verschiedene Bittiefen miteinader verglichen, sondern nur gesagt, dass die Bittiefe 10, 12 oder 14Bit an sich bei der Betrachtung egal ist.

Also z.B. ein 10 Bit-RAW im RAW-Konverter und das daraus exportierte Tiff.

Oder ein 14 Bit-RAW im RAW-Konverter und das daraus exportierte Tiff.

Ich habe mich mit dem Vergleich zwei verschiedener Bittiefen argumentiert.

Du aber nicht

Bin schon ganz wirr im Kopf

Entschuldige bitte und Gruß
ewm

 

[m@sche]

...

Und solange man im RAW nichts "wegschnippelt", werden die Daten auch im Tiff bearbeitet werden können.
...

Genau da scheint das Problem zu liegen. Die Frage ist, was ist bei welchen RAW-Konvertern einzustellen, dass außer Demosaicing - also interpolieren - nichts an den Daten geändert wird.

Du kannst ja mal versuchen mit dcraw ein tiff zu erzeugen,
mit den optionalen Parametern:

-H 1 -o 5 -4 -T

-H 1 Belässt alle übersteuerten Spitzenlichter in verschiedenen Pink Tönen.

-o [0-5]
Wählt den Farbraum der Ausgabe aus, wenn -p nicht verwendet wird:

0 Raw Farbe (abhängig von der jeweiligen Kamera)
1 sRGB D65 (Voreinstellung)
2 Adobe RGB (1998) D65
3 Wide Gamut RGB D65
4 Kodak ProPhoto RGB D65
5 XYZ

-4 Schreibe lineare 16-bit Daten, produziert dasselbe wie -6 -W -g 1 1.


Beispiel:
dcraw -T DSC01376.ARW
mv DSC01376.tiff DSC01376_1.tiff

dcraw -H 1 -o 5 -4 -T DSC01376.ARW
mv DSC01376.tiff DSC01376_2.tiff

dcraw -H 1 -o 4 -4 -T DSC01376.ARW
mv DSC01376.tiff DSC01376_3.tiff

 

[Blants]

Es ist meiner Meinung nach für den Erhalt der Informationen und damit für die Reserven zur Nachbearbeitung egal, mit welchem (Gradations)Kurve die Helligkeitsinformation im Tiff gespeichert ist, solange kein Clipping auftritt, also Helligkeitswerte am unteren und oberen Ende abgeschnitten werden.

Du kannst auch ohne Clipping Werte verlieren, die dich dann beim Bearbeiten einschränken. Wann immer ein Wert aus dem Eingaberaum im Ausgaberaum nicht mehr genau repräsentiert werden kann, musst du runden und bekommst Quantisierungsfehler. Im schlimmsten Fall werden zwei (oder mehr) unterschiedliche Eingabewerte auf den gleichen Ausgabewert abgebildet und du verlierst dadurch Information.

 

[colias]

Ich fände zusätzlich eine praxisorientierte Herangehensweise an dieses Thema für viele sehr anschaulich.

Ich beobachte bspw. immer wieder, dass sich viele plagen, selbst an sehr gut entwickelten Tiffs eine Mischlichtsituation zu „neutralisieren“ ohne etwa Hauttöne leblos wirken zu lassen. Mit einer gründlicheren bzw. zweiten Raw-Entwicklung schaffen sie es jedoch. Ich bin in Raw-Entwicklung und v.a. in Bildbearbeitung nicht ganz unerfahren, greif aber trotzdem immer wieder mal lieber aufs Raw zurück, wenn ich diesen Weg für ökonomischer betrachte.

 

[RalphBecker]

Du kannst auch ohne Clipping Werte verlieren, die dich dann beim Bearbeiten einschränken. Wann immer ein Wert aus dem Eingaberaum im Ausgaberaum nicht mehr genau repräsentiert werden kann, musst du runden und bekommst Quantisierungsfehler. Im schlimmsten Fall werden zwei (oder mehr) unterschiedliche Eingabewerte auf den gleichen Ausgabewert abgebildet und du verlierst dadurch Information.

Dass Quantisierungsfehler in einem 16-Bit Workflow den Bearbeiter einschränken ist schon sehr theoretisch. Außerdem hat man eventuelle Quantisierungsfehler auch beim Einlesen in den Arbeitsspeicher, diese sind also nicht typisch für die Verwendung von Tiffs.

 

[Martin A]

Ich fände zusätzlich eine praxisorientierte Herangehensweise an dieses Thema für viele sehr anschaulich.

Sehe ich auch so.

Ich beobachte bspw. immer wieder, dass sich viele plagen, selbst an sehr gut entwickelten Tiffs eine Mischlichtsituation zu „neutralisieren“ ohne etwa Hauttöne leblos wirken zu lassen.

Ich denke was hier noch nicht beachtet wurde ist, dass ein Raw linear vorliegt, weshalb sich der Weißabgleich auch noch unproblematisch korrigieren lässt. Bei einem entickelten RAW wurde nicht nur eine Farbraumkonvertierung, vom Kamera- in den Ziel-Farbraum vorgenommen, sondern auch je Kanal eine Gammakorrektur. Stimmt dann der Weißabgleich in der Konvertierung nicht, sind die einzelnen Kanäle im Verhältnis zueinander nicht nur verschoben sondern die Tonwerte sozusagen verbogen.
Kann ja jder in der Praxis mal probieren, ein Raw mit deutlich falschem Weißabgleich konvertieren und anschließend versuchen es zu korrigieren.

 

[ewm]

Leute, es wird langsam kurios:

- habt ihr mal daran gedacht, dass Kameras mit Bayer- bzw. X-Trans-Matrix ein "von Hause aus" auf einem Kompromiss basieren?

- und folglich die RAWs daraus auch

- und nun kommt hier jemand mit Rundungs- und Quantisierungsfehlern bei der Farbraumumwandlung bei

- na toll. Mal daran gedacht, dass das Prinzip und die Technik der Sensoren mit Primärfarbfilter und die Notwendigkeit der RAW-Entwicklung selbst nur so von Kompromissen und Fehlern strotzt?



- und Weißabgleich geht sowieso nur richtig bei RAW

- in Zeiten vor den DigiCams mit Bayer/X-Trans war der Weißabgleich ein gewaltiges Problem

- na klar. Deshalb sind werfe ich jetzt alle, vor der Markteinführung der Digicams erschienenen Bildbände in die Papiertonne.

- Ausdrucke von Farbnegative, die prinzipbedingt einen gewaltigen Farbstich mit sich bringen, taugen nur fürs Familienalbum.

- usw. ...



Ich erinnere mich dunkel daran, wie am Anfang der Digicam-Revolution die Technik der Primärfarbfilter vor dem Sensor und die notwendige Interpolation "runtergemacht" wurde.

Die ultimative Lösung wurde dem Foveon-Sensor nachgesagt. Was draus wurde, das wissen wir



Und heute?

Wir sind heilfroh, dass es RAW gibt

Nur so können wir einen ordentlichen Weißabgleich durchführen, Lichter aus einem "Headroom" retten, ...

Und "leider" muss dann doch irgendwann mit dem schlecht beherrschbaren Teufelsformat Tiff arbeiten, weil im Bearbeitungsprozess leider Schluss mit RAW ist


Ist jetzt von mir alles etwas überspitzt formuliert. Weil die Diskussion aus meiner Sicht langsam absurd wird.

Aber ok, macht mit Euren RAW-"Verschwörungs"theorien weiter. Ich verabschiede mich hiermit aus dieser Diskussion

Gruß
ewm

 

[RalphBecker]

Kann ja jder in der Praxis mal probieren, ein Raw mit deutlich falschem Weißabgleich konvertieren und anschließend versuchen es zu korrigieren.

Hab ich jetzt mal gemacht:

Als erste die Originalentwicklung, weißabgleich über Pipette auf mittleres Grau


Danach Bild erneut geöffnet und WA total verdreht


Dieses 'verdrehte' Bild in PS mit Camara-RAW Filter und Weißabgleich auf das gleiche Graufeld korrigiert



Als letztes der Vergleich:


Ich sehe bei der Korrektur des Weißabgleiches keine Schwierigkeit, zumal es nur mit der Pipette gemacht ist.
Verlustbehaftet kann es werden, wenn Bilder mit hoher Sättigung einen sehr falschen Weißabgleich bekommen. Dann clippen nämliche einzelne Kanäle - aber das hatten wir ja schon.

 

[rodinal]

Dass Quantisierungsfehler in einem 16-Bit Workflow den Bearbeiter einschränken ist schon sehr theoretisch.

Kommt auf die Ansprüche an. Die Sony-Studios haben sich seinerzeit von Adobe verabschiedet und eine eigene 32Bit-Software (Cinepaint) entwickeln lassen, weil bei einer Weitergabe über mehrere Stationen, wie sie in der Filmindustrie üblich ist, bei 16Bit-Formaten inkonsistente Ergebnisse unvermeidlich sind.

Übrigens hat Elle Stone mal ein 32Bit-Rewrite von dcraw (Original 16Bit) geschrieben. Bei ansonsten identischen Einstellungen brachte die höhere Genauigkeit ca. 1/3 EV mher Dynamik in den Lichtern. Auch softwareintern scheinen Rundungsfehler weh zu tun.