SonyUserforum - RAW vs. CRAW

SonyUserforum (https://www.sonyuserforum.de/forum/index.php)

- Sony A-Mount Kameras (https://www.sonyuserforum.de/forum/forumdisplay.php?f=24)

- - RAW vs. CRAW (https://www.sonyuserforum.de/forum/showthread.php?t=91346)

Zitat:

Zitat von aidualk (Beitrag 1037678)

:top: Wenn du ein raw Bild entwickelst, hat es exakt 144MB im Tiff Format. Es scheint tatsächlich nichts verloren zu gehen.
Frage: wieviel MB hat ein entwickeltes craw im Format Tiff? (da ich keines davon auf der Platte habe, kann ich nicht nachschauen, müsste extra eines produzieren, hab aber gerade die Kamera nicht hier ;) )

das ist natürlich genausogross - Pixelzahl*16bit

Es können ja keine Pixel verlorengehen ...

Ich habe eben 2 Testfotos gegen einen kontrastlosen Hintergrund (weisse Wand).
Das RAW Bild ist 36MB das cRAW ist 24MB (bzw. 1/3) kleiner.

Zitat:

Zitat von neonsquare

Doch was heißt das nun bezüglich der Bildqualität? Diese Methode baut darauf, dass innerhalb eines Bereichs von 16 Pixeln niemals der vollständige (theoretische) Dynamikumfang von 12 Bit benötigt wird. Liegen die Werte relativ nah zusammen, dann besteht kein Unterschied zum unkomprimierten RAW. Problematisch wird es nur, wenn der Kontrastunterschied innerhalb dieser 16 Pixel sehr groß wird. Wobei man generell bedenken sollte, dass dies alles sowieso noch vor der eigentlichen Interpolation ist, die aus dem Bayer-Muster überhaupt erst ein RGB-Bild erzeugt.

Verstehe ich das richtig, dass der Komprimierungsalgorithmus nur auf die einzelnen Graumuster der Sensore des Bayer-Pattern angewendet wird? Wenn ja, dann lässt sich mit einem kleinen C-Programm das ARW 2.1 komprimierte Bild in ein unkomprimiertes konvertieren und dann kann ein Vergleich des echten unkomprimierten mit dem komprimierten angeben in wieviele Pixel sich die beiden Versionen unterscheiden. Dann wüßte man wie groß der Unterschied in der Praxis zwischen RAW und cRAW tatsächlich ist.

Wir bräuchten eigentlich ein unkomprimiertes RAW, aus dem wir ein komprimiertes machen. Das Komprimierte wird dann wieder dekomprimiert und mit dem ersten verglichen. Insbesondere wäre auch ein Vergleich der entwickelten Bilder interessant.

Leider ist es nicht so einfach mit dem komprimieren, da ein paar Dinge nicht ganz klar sind wie es die Kameras machen.

Gruß,
Jochen

Zitat:

Zitat von Neonsquare (Beitrag 1037939)

Genau. :top:

Zitat:

Zitat von Neonsquare (Beitrag 1037939)

Leider ist es nicht so einfach mit dem komprimieren, da ein paar Dinge nicht ganz klar sind wie es die Kameras machen.

Da dcraw RAW und cRAW lesen kann, lässt sich vielleicht auch ein craw konverter schreiben.

Das wäre schon möglich - vielleicht gibt es da schon was - in einem der verlinkten Threads wurde das Programm RAWHide (http://www.my-spot.com/RHC/) eines der Mitglieder erwähnt. Damit soll es möglich sein. Wenn ich wieder ein bisschen mehr Freizeit habe, werde ich das auch mal probieren. Trotzdem besteht natürlich das Problem, dass wir nicht entgültig wissen können, ob die dort implementierte Komprimierung wirklich dieselben Annahmen verfolgt wie bei jener in der Kamera. Da geht es beispielsweise um Themen wie Rundungen, oder ob mit den Daten noch irgendeine andere Aufbereitung erfolgt.

Gruß,
jochen

Hochinteressante Diskussion, geht richtig in die Grundlagen. Bin gespannt auf die Fortsetzung :-)

Grüße, Uwe

Zitat:

Zitat von Neonsquare (Beitrag 1037306)

...Es werden immer Blöcke aus 16 Pixeln komprimiert. Dabei wird der größte und der kleinste Wert bestimmt und im cRAW gespeichert (jeweils als 11 Bit Wert). Die Position 0-15 des minimalen Werts und des maximalen Werts werden danach mit jeweils 4 Bit kodiert. Damit sind von 16 späteren Pixeln noch 14 Pixel zu speichern. Diese werden als 7-Bit Offset zum Minimalwert gerechnet. So wird aus ursprünglich 16 x 12 Bit = 192 Bit = 24 Bytes ein komprimierter Block aus 11+11+4+4+(14x7) = 128 Bit = 16 Bytes.

Code:

  11   11    4       4       7           7

[max][min][maxpos][minpos][pixel1]...[pixel14]

...

Die zu klärende Frage: sind es 16 Pixel gleicher Farbe in einem Block?

Zitat:

Zitat von Neonsquare (Beitrag 1037380)

So wie ich es verstehe reduzieren sich die Werte erstmal auf 11 Bit, da ja der maximale und minimale Wert mit 11 Bit abgelegt werden und über die 7-Bit-Werte ja lediglich die Spanne zwischen Max und Min kodiert werden.

Im Prinzip funktioniert das ca. so:

Code:

           12 Bit

      /              \

     /                \

    /                  \

   /                    \

  /                      \

 !  m  M                  ! Kleiner Dynamikumfang

 !          m         M   ! Mittlerer Dynamikumfang

 !m                      M! Großer Dynamikumfang

Insgesamt bieten die cRAW auch 12 Bit Werte - aber gespeichert werden Werte, die anhand des jeweils lokalen Dynamikumfangs bestimmt werden. In der ersten Zeile ist der Dynamikumfang relativ klein - so dass 7 Bit Spanne von m bis M ausreichen. Beim Mittleren Dynamikumfang erreicht man eine Spanne, die sich gerade noch mit 7-Bit kodieren lässt. In der dritten Zeile ist der Dynamikumfang so groß, dass die 7-Bit nicht mehr vollständig ausreichen um sämtliche Zwischenwerte zu kodieren. Betrachtet man das Bild insgesamt, so sollte klar sein, dass der abbildbare Dynamikumfang größer ist - man muss dazu quasi das kleinste Minimum und das größte Maximum gegenüberstellen.
....
Gruß,
Jochen

Um in jedem Fall den theoretisch noch maximal 11 Blendenstufen betragenden Kontrastumfang zu erhalten müssen alle Werte xi aus dem Bereich Min .. Max, d.h. die Differenzen (xi-Min) auf den Bereich (Max-Min) in 7 Bit Auflösung abgebildet werden.
Gespeichert werden dann nicht die Differenzen (xi-Min) sondern die modifizierten Werte.
Bis zu einem Kontrastumfang von 7 Blendenstufen bleiben dann auch alle Zwischenwerte erhalten.

Gruß,
Stuessi

Zitat:

Zitat von Stuessi (Beitrag 1038105)

Die zu klärende Frage: sind es 16 Pixel gleicher Farbe in einem Block?

Ja - da die 16-Bit-Blöcke immer jede zweite Spalte zusammenfassen. Damit vergrößert sich zwar die physikalische Breite der zusammengefassten Pixel, dafür sollte die Variation im isolierten Farbkanal wiederrum kleiner sein.

Zitat:

Zitat von Stuessi (Beitrag 1038105)

Ja - ungefähr das habe ich ja auch beschrieben. Wichtig ist dabei aber, dass es zum einen nur um einen Kontrastumfang innerhalb einer Farbkomponente geht. Es ist auch nicht so, dass dann jeder der 16 komprimierten Pixel falsch bzw. gleich falsch ist. Einzelne Pixel werden mehr, weniger bis gar nicht abweichen. Hinzu kommt außerdem, dass die Interpolation des Bayer-Musters ja - je nach Algorithmus - für jeden Pixel noch viel mehr andere Pixel miteinrechnet und so der Fehler eines einzelnen Pixels sich deutlich weniger stark auf das gesamte Ergebnis auswirkt. Trotz aller Theorie ist weiterhin nicht klar, ob die Kombination aus AA-Filter, Grundrauschen und RAW-Interpolation überhaupt noch zu einem tatsächlichen Verlust im entgültigen Ergebnis führt. Mein Bauchgefühl sagt mir zumindest, dass dies extrem unwahrscheinlich ist. Da ist die Wahl des RAW-Konverters vermutlich signifikanter.

Gruß,
Jochen

Ihr seit schon abgefahren irgendwie :lol::top::cool:

Gibts eigentlich sowas auch bei Nikon, Canon?

Zitat:

Zitat von Stuessi (Beitrag 1038105)

7 Bit entsprechen nicht 7 Blendenstufen, sondern 128 Stufen zwischen maximaler und minimaler Helligkeit in dem lokalen Bereich, der für die Komprimierung betrachtet wird. Dieser Bereich ist bei der A700 16x2x5,5 µm = 176 µm auf dem Sensor, oder gedruckt mit 300 dpi etwa 0,3 mm auf dem Ausdruck. 128 Graustufen auf 0,3 mm ist immer noch ganz ordentlich - JPEG kennt überhaupt nur 256 Helligkeitstufen über das ganze Bild, und dem Auge reicht das völlig ;-)

Streng mathematisch ist es natürlich Augenwischerei: cRAW ist dort verlustfrei, wo der Helligkeitsumfang nur maximal 7 Bit oder 128 Stufen beträgt. Da wäre JPEG aber auch verlustfrei ;-)

Betrachtet man das ganze aber rein pragmatisch vom Ergebnis, scheint cRAW völlig zu reichen. Mit dem Auge lässt sich nach Aussage von Grafikern wohl kein Qualitätsunterschied erkennen, selbst bei Pixel-peeping in 100% Ansicht.

Grüße, Uwe