Verfasst: Mi 22. Dez 2004, 19:27
Roland, natürlich hast Du recht, dass die Sensordaten prinzipiell ein Schwarz/Weiss-Bild beschreiben, wobei im RAW-Bild eine feste Position für das Beyer-Pattern aus den pixelbezogenen Farbfiltern vorausgesetzt wird. Das hat aber mit dem Thema RAW-Kompression zunächst mal nichts zu tun.Blue Heron hat geschrieben:Hier noch mal für's Protokoll:
Das Bild vom Sensor ist SW und es wird so umgewandelt.
Die Kompressions-Diskussion bei Raw-Dateien geht nicht um die Zuordnung, welches Pixel zu welcher Farbe gehört, sondern darum, wie die Helligkeitswerte der ausgelesenen Pixel in Zahlenwerte in der Bilddatei umgesetzt werden. Denn das Format dieser Zahlenwerte bestimmt ganz wesentlich die Dateigrösse der RAW-Bilddatei.
Ich will diesen Sachverhalt mal ein wenig aus der Sicht des Nachrichtentechnik-Inscheniörs
mit etwas theoretischem Hintergrund verdeutlichen - hoffentlich halbwegs verständlich:Beispiel:
- Wenn die Helligkeitswerte als echte 12-Bit Daten abgelegt werden, dann muss für jedes Pixel eine 12-Stellige Binärzahl in die Bilddatei eingetragen werden. Würde man anstelle der 12-stelligen Zahlen nur 10-stellige Zahlen verwenden, so erntspräche dies automatisch einer Verringerung der Dateigröße (bei gleichbleibender Pixelzahl) um ca. 17% - einfach weil weniger Bits gespeichert werden müssen. Und wenn weniger Bits zu speichern sind, dann lassen sich diese weniger umfangreichen Daten auch schneller speichern.
- Eine 12-stellige Binärzahl kann 4096 unterschiedliche Werte für den gegebenen Helligkeitsbereich beschreiben. Eine 10-stellige Zahl löst für den gleichen Helligkeitsbereich nur 1024 unterschiedliche Werte auf. Das andere Zahlenformat kann die Daten also nicht in der gleichen Auflösung abbilden, denn die Differenz zwischen einem der 4096 Schritte und seinem Nachbarn ist natürlich kleiner als der Unterschied zwischen einem aus 1024 Schritten und dessen Nachbarwert - sofern beide Zahlendarstellungen den gleichen Helligkeitbsbereich beschreiben.
- Mit ihr kann man bei niedrig auflösenden Zahlenformaten trotzdem eine höhere Auflösung abbilden - nur eben nicht über den ganzen Wertebereich! Klingt sonderbar, ist aber tatsächlich so.
- Das bedeutet, dass der Schritt von einem Zahlenwert zum nächsten immer konstant ist - dass die Helligkeitswerte in einem linearen Zusammenhang zur zugehörigen Zahl stehen. Beispiel: Der Unterschied zwischen den Werten 3578 und 3579 ist gleich (Gesamt-Helligkeitsbereich / 4096), und die Differenz zwischen den Werten 475 und 476 hat genau die gleiche Größe. Bei linearer Codierung sind diese Schrittwerte immer gleich - egal, um welche Zahl (im zulässigen Wertebereich) es geht.
- Dann kann ich mir die Werteauflösung genau so "hinbiegen", wie ich sie für die technische Aufgabenstellung brauche - und ich benötige dafür nicht mehr so viele unterschiedliche Zahlenwerte. Dementsprechend lässt sich damit die Menge der zu speichernden Daten verringern.
- die sieht oft so ähnlich aus wie eine S-förmig gestellte Gradationskurve. Nur - sie beschreibt etwas anderes: Auf der horizontalen Achse sind in linearer Skalierung alle Zahlenwerte des verwendeten Zahlenformats aufgeführt (z.B. 0 - 1023), auf der vertikalen Achse stehen die Helligkeitswerte (von schwarz bis weiss). Dort, wo die Kurve flach ist, beschreibt ein Schritt von einer Zahl zum benachbarten Wert nur einen kleinen Helligkeitsunterschied. An einer steilen Stelle sieht's ganz anders aus: Dort ist der Helligkeitsunterschied zwischen zwei benachbarten Werten viel größer! Sowas nennt man eine nichtlineare Codierung.
- Im Gegenzug sieht man an anderen Stellen im Helligkeitsbereich (wo's nicht so wichtig ist) eine wesentlich gröbere Helligkeitsauflösung vor, um trotzdem mit der gewünschten niedrigen Anzahl unterschiedlicher Zahlenwerte auszukommen. Das ist Datenkompression (mit dieser Technik arbeiten übrigens auch alle unsere digitalen Telefone).
Wenn man diese Methode zusamen mit anderen Verfahren der Datenkompression für Datenströme (z.B. Zip- oder LZW-Kompression) verwendet, so lässt sich die Größe der RAW-Bilddateien erheblich verringern, ohne dass (im Gegensatz zur JPEG-Kompression, einer fundamental anderen Technik) geometrische Details des Bildes verloren gehen!
Wenn man den Adobe Raw-Converter per Reverse Engineering analysiert, und dort für D70 RAW-Dateien auf Kompression schliessen kann, so kann ich mir nicht vorstellen, dass diese Info aus den Fingern gesogen ist. Denn wenn die Analyse korrekt ist, und der Adobe RAW Konverter die D70-Dateien unbestrittenermaßen korrekt lesen kann, dann lässt dies tatsächlich auf Dateikompression schliessen - sonst könnte der Konverter die Daten ja schliesslich nicht lesen.
Die Frage, ob RAW-Daten verlustbehaftet ("lossy") oder verlustfrei ("lossless") abgespeichert werden können, hängt sehr stark von der verwendeten Kompressionstechnik ab - und davon, ob die technischen Kompromisse bei der nichtlinearen Codierung richtig gewählt wurden. Die Helligkeitswahrnehmung unserer Augen ist logarithmisch, also stark nichtlinear. Insofern ist es durchaus sinnvoll, auch RAW-Daten zu komprimieren, und zwar in den Bereichen, die unser Auge ohnehin nicht unterscheiden kann.
Fazit: Ob man Raw-Daten ohne wahrnehmbaren Qualitätsverlust komprmieren kann oder nicht , ist eine Frage der verwendeten Technik, und keine Glaubensfrage. Letzten Endes sind alle diese technischen Tricks zulässig, so lange sie nicht zu einer wahrnehmbaren Verschlechterung des erfassten Bildes führen!
Klar, das mache ich gerne! Allerdings möchte ich damit noch ein wenig warten, denn wer weiss, was in diesem Thread noch für technische Fragen hochkommen...