RAW vs. CRAW
 

Hallo,

habe bisher immer das craw-Format verwendet. Hat hier jemand Erfahrung ob es da große Unterschiede bezüglich der Qualität zum raw-Format gibt?

Für ein paar Hinweise wäre ich sehr dankbar (bin mit einer A900 u. Aperture 3 unterwegs).

Peter

Laut Sony gibt es keine Qualitätsunterschiede zwischen craw und raw.

Gruß,
Jochen

Da gibt es ein paar Threads zu. Es gibt Testbilder auf denen man einen Qualitätsverlust nachweisen konnte, allerdings sehr technisch Testbilder die selten der Realität entsprechen (am nächsten dran kam Astrofotografie). Anders gesagt der Qualitätsverlust ist minimal.

Ich habe länger mit RAW fotografiert, dann mit CRAW. Macht in meinen Augen in der Praxis keinen Unterschied.
RAW hat aber dann einen Vorteil, wenn man die Bilder - so wie ich - zum Speicherplatz-Sparen in dng konvertiert. Interessanterweise sind konvertierte RAWs kleiner als konvertierte CRAWs.

Danke,

werde dann bei craw bleiben.

Peter

Ich hab mir die Implementierung der Sony cRAW-Dekomprimierung in dcraw.c mal näher angeschaut. Das ist ganz schön gewieft was da passiert :D (keine Angaben auf Gewähr)

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.

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.

Gruß,
Jochen

Hallo Jochen,

Danke für den Einblick. Ich als Informatiker teile Deine Meinung: sehr gewieft und ausgefuchst. Allerdings sind diese Algorithmen schon länger bekannt und finden hier ein sehr sinnvolles Anwendungsfeld.

... und damit deutlich weniger Einfluß auf die Bildqualität hat als die Interpolation selber, oder?!

Grüße,

Jörg

Hallo Jochen,

vermutlich wird dann das niederwertigste Bit weggelassen und hinterher durch eine Null ergänzt.
Ich sehe für die Bildqualität eher einen Nachteil, wenn nur geringe Kontraste auftreten, z.B. bei einem Bild im Nebel.
Aus xxxxxxxx0000 bis xxxxxxxx1111 wird dann xxxxxxxx0000 bis xxxxxxxx1110, statt 16 Stufen existieren nur noch 8.

Gruß,
Stuessi

Hallo,
laut Sony ist das RAW-Format eine verlustfreie Komprimierung der Daten und das cRAW ein verlustbehaftete Komprimierung der Bilddaten. JPEG ist auch eine verlustbehaftete Komprimierung. Der entstehende Verlust an Bildinformation ist sicherlich Situationsbedingt.

@wolfram.rinke
Wo kann man dieses Statement von Sony nachlesen?

Gruß,
Jochen

Doppelt komprimieren macht halt groß - kurz gesagt ;)
Der Gewinn beim Komprimieren von RAW nach DNG ist aber nicht soooo erheblich im Vergleich zu RAW zu cRAW.

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:

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.

Was mir noch nicht klar ist:
1) dcraw.c benutzt ein Feld "curves" um das Dekomprimierte 11-Bit Resultat auf den finalen Wert zu setzen. Mir ist noch nicht klar was für eine Abbildungsfunktion dahintersteckt
2) Ist das wirklich der Algorithmus oder womöglich eine nicht ganz stimmige Rekonstruktion. Ich habe da ein paar Indizien gesehen, die andeuten, dass das noch nicht das ganze Ding ist.

Gruß,
Jochen

Grübel, was will mir der Autor damit sagen:?:

Grüße
Uwe

er meinte wohl RAW -> cRaw und RAW -> DNG

Meinte er (vor seinem ersten Kaffee) - Sorry!

Sony a900 - cRAW vs RAW

The consolidated CRAW compression thread

:)

Da auch hier immer wieder DNG ins Spiel gebracht wird.

Wer sicher auch zukünftig immer in der Adobe-Welt bleiben will, mag sich überlegen, seine Raws durch gewandelte DNGs zu ersetzen. Wer auch andere Konverter einsetzen will - oder zumindest nicht ausschließen will, das später einmal zu tun - der sollte sich diesen Schritt gut überlegen. Die meisten Nicht-Adobe-Konverter kommen nicht, oder nur sehr eingeschränkt mit DNGs zurecht. Da nützt es auch nichts, wenn immer wieder die "Zukunftssicherheit" von DNG im Vergleich zu den "proprietären" Formaten beschwört wird. Das Gegenteil ist der Fall.

Rainer

Das Benutzerhandbuch zur Alpha700 beschreibt cRAW als "komprimiert" und RAW als "Rohdaten". (S96) Eine weitere Fußnote verweist auf eine Komprimierung von 60-70% (!). Dies dürfte sicher aber nicht auf cRAW sondern auf die "JPEG fein" Formateinstellung beziehen. Zitat: "Die Daten werden um 60 bis 70% im vergleich zu einem nicht komprimierten Bild komprimiert."

Im Benutzerhandbuch der Alpha850 wird auf S100 ebenfalls cRAW als "komprimiert" beschrieben und mit der Anmerkung "Die Daten werden um 60 bis 70% im vergleich zu einem nicht komprimierten Bild komprimiert." angegeben.

Im Alpha 700 handbuch sind 2 Fußnoten angegeben im Alpha850 Handbuch nur mehr eine Fußnote mit dem selben Text. Ich vermute, dass es sich dabei um einen Übersetzungsfehler handelt. Bzw sich die Angaben bei der A850 nicht auf das cRAW sondern auf das "JPEG fine" Format beziehen (wie bei der Alpha700).

Scheibl beschreibt in seinem Buch "Sony Alpha 700" auf Seite 19ff das RAW-Dateiformat leider nicht korrekt. Er stellt das RAW als "völlig unkomprimiert" und cRAW als "verlustfrei komprimiert" dar. Frank Exner beschreibt in seinem Buch "Sony Alpha 700 (Digital ProLine, Data Becker)" das cRAW Format als komprimiertes RAW Format mit "nahezu" verlustfrei.

Die schwankenden Dateigrößen eines RAW Bildes, sind durch die eine Verlustfreiekomprimierung zu erklären, da ein völlig unkomprimiertes Bild mit zB 24MPixel und 12Bit ADC je Farbpixel ergibt 48 Bit je Pixel (wegen RGBG Bayer-Pattern), d.h. 6Byte je Pixel. Somit liefert ein RAW Sensor 144MB an Daten. Tatsächlich hat die RAW Datei aber nur zw. 34-36MByte. Was bedeutet, dass die RAW Daten verlustfrei komprimiert sein müssen. Das cRAW Format interpretiert mit seinem Verfahren den Bildinhalt bzw. und interpoliert zwischen den Min und Max Wert, wodurch zumindest theoretisch und auch real ein Datenverlust auftritt, der sich aber in der JPEG Ausarbeitung nicht erkennbar macht.

Ein technisches Benutzerhandbuch wäre zur Alpha Serie sicher sehr hilfreich.

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

Hm... steht da wirklich "um"? Bei cRAW sind die Bilder gegenüber RAW auf 60-70% der Größe komprimiert. Unterschiede ergeben sich durch das eingebettete JPEG.

Das kommt halt darauf an wie pfennigfuchserisch man sein möchte. Betrachtet man isoliert den Komprimierprozess nach Aufnahme der Sensordaten, dann kann es in der Tat so sein, dass die später dekomprimierten Werte teilweise von den eigentlichen Sensorwerten abweichen. Allerdings: Es ist nicht bekannt, in welchem Rahmen sich die Sensorwerte wirklich bewegen und inwiefern überhaupt innerhalb eines 16 Pixel Zeilensegments einer Farbe (!) derart starke Wertunterschiede vorkommen können. Schon der Antialiasingfilter könnte die möglichen Inputdaten ausreichend beschränken. Dann kommt hinzu inwiefern Wertunterschiede überhaupt über das Sensorrauschen hinweg messbar bleiben - denn was bringt es, exakt die gemessenen Sensorwerte zu haben, wenn die Unterschiede bloß innerhalb des Rauschens liegen würden. Nicht zuletzt sollte man bedenken, dass bei RAW-Fotos basierend auf dem Bayer-Muster IMMER ein Interpolationsschritt erfolgt, der alleine schon je nach Algorithmus unterschiedliche Resultate liefert. Also: isoliert betrachtet und unter der Annahme, dass die Inputdaten tatsächlich ausreichend variieren können wäre die cRAW-Komprimierung verlustbehaftet. Betrachtet man das Gesamtsystem, dann ist das aber nicht mehr so klar. Dazu sollte man bedenken, dass "verlustbehaftet" bei Formaten wie MP3 oder JPEG bedeutet, dass man als Mensch im besten Fall keine Unterschiede wahrnimmt während bei der cRAW-Komprimierung die Unterschiede womöglich schon durch die Bearbeitungspipeline nicht mehr nachvollziehbar sein könnten.

Die schwankenden Dateigrößen liegen in erster Linie mal an den eingebetteten JPEG-Vorschaubildern. Die 24MPixel eines Bayersensors sind allerdings alle Graupixel - es zählen also die R G und B Pixel alle mit rein. Die Datenmenge sind also 12x24/8=36MByte an Graupixeln, die beim Demosaicen entsprechend dem Bayer-Muster interpoliert werden. In den RAW-Dateien liegen die Daten also völlig umkomprimiert vor.

Übrigens sind es natürlich im TIFF 144MB, weil das TIFF 24MPx(16Bitx3)/8 = 144MB an Daten enthält. Die R, G und B Pixel des Bayer-Sensors werden nicht kombiniert! Für jeden der 24MP wird anhand seines Wertes und seiner Umgebung die R, G und B Komponente errechnet. Sonst würde die "Pixelposition" im späteren Bild ja gar nicht mehr mit der "Pixelposition" auf dem Sensor übereinstimmen.

Ob bei cRAW tatsächlich real ein Datenverlust auftritt kann man so nicht klar sagen. Das gesamte Prinzip eines Bayer-Sensors ist statistisch und nicht exakt - ob die technisch möglichen Variationen der Sensorwerte sich also innerhalb der ganzen Pipeline von Sensordaten zu 16Bit RGB-Daten (also noch vor JPEG-Wandlung!) tatsächlich als statistisch signifikant erweisen, das ist so nicht klar.

Oh ja, das wäre es wirklich!

Gruß,
Jochen

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.

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

Genau. :top:

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

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

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

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.

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?

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

@Karsten
Das Thema ist vielleicht wieder etwas interessanter, wenn man bedenkt, dass außer bei A700, A850 und A900 der nicht-komprimierte RAW-Modus gar nicht existiert! Alle anderen Modelle implementieren heute cRAW! Die A3x0, A5x0 liefern also als RAW ausschließlich cRAW!
Bei Nikon gibt es ähnliches:

http://regex.info/blog/photo-tech/nef-compression
http://majid.info/blog/is-the-nikon-...ruly-lossless/

Erst ab der D300 aufwärts gibt es "lossless compressed" NEF.

Vorsicht! Der Vergleich mit JPEG hinkt hier ziemlich. JPEG arbeitet ja einerseits viel später in dieser Pipeline und ist schon ein sehr viel stärkerer Eingriff (Diskrete Cosinus-Transformation). Das alles würde auch implizieren, dass die Auswirkungen der Komprimierung sich tatsächlich über die RAW-Interpolation hinweg so lokal und gleich stark auswirken könnten. Gerade diese RAW-Interpolation ist es jedoch, welche das ganze ziemlich stark relativiert - denn in jeden Pixel der 0,3mm spielt ja nicht nur die Information der komprimierten 16 Pixel sondern auch Information aus ganz anderen Bereichen mit rein. Desweiteren betrifft der Fehler ja erstmal nur eine Farbkomponente. Wie krass da unterschiedliche RAW-Interpolationsalgorithmen sein können demonstriert diese Seite sehr gut:

http://www.rawtherapee.com/RAW_Compare/

Man sollte sich bewusst sein, was ein Bayer-Sensor - mit seinem 1-Chip-Design und den spatial getrennten Farbkomponenten im Bayer-Muster für jeden einzelnen Pixel bedeutet! Ein herkömmlicher RGB-Pixel besteht bereits aus allen drei Komponenten - ein Bayerpixel wiederrum ist nichts wert ohne den Kontext in dem er sich befindet.

Wie bereits gesagt - der JPEG-Vergleich hinkt hier. Bei JPEG liegen die Pixel bereits als RGB vor. Jeder einzelne Pixel enthält 3 Farbkomponenten mit jeweils 8 Bit. Beim Bayer-Sensor gibt es isoliert nur eine einzige Farbkomponente und die wird mit theoretisch maximal 12 Bit aufgezeichnet (praktisch gesehen weniger). Die eigentliche Farbe nach RGB ergibt sich nur, indem man die Umgebung des Bayer-Pixels in Betracht zieht und deren Intensitäten miteinander verrechnet. Eine Primitivmethode würde einfach die Farbkomponenten der Nachbarwerte aufaddieren und durch die Anzahl der Nachbarn teilen - also eine Mittelung. Dieses Verfahren funktioniert aber nicht sonderlich gut. Kurz: Bei der JPEG-Komprimierung gibt es einen korrekten Ausgangswert nach R, G und B in jeweils 8 Bit kodiert. Bei Bayer ist der "korrekte Ausgangswert" Interpretationssache.

Gruß,
Jochen

Das stimmt. Das ist interessant. Nur in der berühmten Praxis wahrscheinlich zu 99,99% irrelevant.

@Karsten
ich sehe das Problem eher als psychisch - obwohl die praktische Relevanz vermutlich wirklich völlig vernachlässigbar ist, kann ich mir gut vorstellen, dass darüber der eine oder andere A900-Nutzer anders denkt.

Gruß,
Jochen

Ich wollte nicht JPEG-Kompression mit cRAW Kompression vergleichen, außer in dem einen Aspekt: Wo keine Dynamik im Bild ist, also z.B. in einer einfarbigen Fläche gleicher Helligkeit, verliert man durch Kompression keine Information (außer die Farbe und Helligkeit selbst würden durch abweichende Werte ersetzt).

Was Du schreibst ist alles richtig und spiegelt etwas den Unterschied im Ansatz von Mathematikern und Physikern wider ;)

Als "nullte Näherung" wird ein Physiker die ganze Weiterverarbeitung zunächst vernachlässigen (mathematisch die Übertragungsfunktion =1 setzen), um zu einer ersten Abschätzung zu kommen. Dass die tatsächlichen Auswirkungen der Kompression durch die nachfolgenden Weiterverarbeitungsschritte abgemindert (oder aber auch verstärkt!!!) werden können, sei damit nicht bestritten. Solange wir diesen Einfluss aber nicht kennen, ist die einfachste Näherung, ihn zunächst einmal zu vernachlässigen - sonst sind wir nur am spekulieren ;)

Unter dieser Vereinfachung noch mal ein quantitativer Versuch:

cRAW arbeitet mit 11 Bit. In einem lokalen Bereich von 16 Pixeln kann ungünstigstenfalls sowohl der dunkelste Wert = 0 als auch der hellste Wert = 2^11 = 2048 vorkommen. cRAW kann 2^7 = 128 Zwischenwerte zwischen dem hellsten und dem dunkelsten der 16 Pixel darstellen. Bei einer linearen Teilung wären das schlimmstenfalls Helligkeitsschritte von 2048/128 = 16 Bit Breite (bei einem Dynamikumfang des Sensors von 12 Blendenstufen entspräche eine Stufe der Breite 16 Bit durchschnittlich maximal 1/10 Belichtungsstufe). Alle digitalen Helligkeitswerte von "0" bis "15" würden in cRAW dann z.B. zu einem Näherungswert "ungefähr 8", alle Helligkeitswerten von "16" bis "31" zu "ungefähr 24", alle Helligkeitswerte "32" bis "47" zu "ungefähr 40" usw.

Was kann schlimmstenfalls passieren:

a) Kleine Unterschiede von weniger als 1/10 Belichtungsstufe können "weggebügelt" werden (z.B. eine feine Struktur mit Helligkeitswerten zwischen "0" und "17" würde zu einem unstrukturierten einheitlichen Wert "8").

b) Kleine Unterschiede können auf maximal 1/10 Belichtungsstufe "übertrieben" werden (z.B. wenn benachbarte Pixel gerade in unterschiedliche Bereiche fallen: "17" würde zu "ungefähr 8" abgerundet, "18" würde zu "ungefähr 24" aufgerundet).

Die maximale Abweichung von 1/10 Belichtungsstufe würde nur an Stellen im Bild auftreten, an denen innerhalb von 16 Pixeln die Helligkeitswerte von Null auf Maximal springen.

Mal ganz abgesehen von allen Überlagerungen durch Rauschen, Bayer-Interpolation, JPEG-Konversion usw. bei der anschließenden Weiterverarbeitung bis zum fertigen Bild ist die Frage, ob das Auge eine mögliche Helligkeitsschwankung von 1/128 des maximalen Dynamikumfangs auf 0,3 mm Bildfläche auflösen kann. Und selbst wenn es das kann bleibt die Frage, ob es für den Bildeindruck wichtig ist, was innerhalb dieses Pünktchens passiert.

Eine interessante Frage ergibt sich natürlich aus der ganzen Diskussion: Braucht man überhaupt 12 oder 14 Bit A/D Wandler, solange der ganze Dynamikumfang des Sensors auf nur 10-12 Belichtungsstufen absolut begrenzt ist? Sind die digitalen Helligkeitsstufen nicht schon zu fein, ist da überhaupt noch Information enthalten - oder nur noch Fluktuation durch Rauschen? Geht solche feine Information nicht im weiteren Prozess eh verloren? Und könnte unser Auge am Ende der ganzen Kette solche feinen Information aufnehmen und verarbeiten?

Ich habe mal gelesen, dass 16 deutlich unterscheidbare Grauwerte ein brilliantes, scharfes s/w-Bild ergeben. Da sind wir dann wieder bei der Verkaufs-Psychologie, und in der Schlussfolgerung beinander ;)

Grüße, Uwe

moin, Du nimmst hier implizit an, dass die RAW-Werte die Helligkeit sehrichtig darstellen. Stimmt aber nicht, die RAW-Werte sind (näherungsweise) linear, der Seheindruck hat aber eine deutlich nichtlineare Kennlinie mit mindestens zwei Wendepunkten (2.Ableitung=0). Die Dynamik lässt sich keinesfalls irgendwie mit der Bit-Tiefe korrelieren, und auch die Tonwertauflösung ist in erster Linie von der Abbildungsfunktion abhängig und der Bit-Tiefe im Zielformat bzw. dem Ausgabemedium.
Von daher ist es sinnvoll, die RAW-Werte mit einer möglichst hohen bit-Auflösung darzustellen, um bei der Entwicklung (Bayer-Demosaicing und Dynamik-Kompression und Tonwertkorrektur) möglichst viel Reserve zu haben.

cRAW bringt jedenfalls kaum Vorteile, Speicherplatz kostet ja fast nix mehr. Schneller werden die Kameras dadurch nicht.

PS: auch die NEX kennen offenbar nur cRAW, jedenfalls sind die RAWs zu klein für unkomprimierte Dateien.
A700/850/900 kennen beide Modi, aber keinen verlustfrei komprimierten RAW-Modus: wenn man die einzelnen Farblayer als TIFFs ablegt, könnte man die z.B. mittels lzw komprimieren und so ähnliche (allerdings stark inhaltsabhängie) Kompressionsraten erzielen wie das eben gerade nicht verlustfreie cRAW. Per 7zip(lzma) oder bzip2 lassen sich die RAWs der a900 z.B. auf typisch 60-70% verlustfrei komprimieren; das wäre eine Option, wenn man den inneren Aufbau der RAWs nicht ändern möchte.

Beim füllen des Puffers macht sich das schon bemerkbar (speziell wenn man eine langsamme CF Karte verwendet)

@ddd
Inwiefern kannst du wissen, ob cRAW keine Vorteile bietet? Der Algorithmus scheint sich - nach allem was ich bisher gesehen habe - ideal für eine Hardwareimplementierung eignen. Die Kompressionsrate ist fix - das sind alles Eigenschaften, die ein so zeitkritisches System wie eine Kamera sehr beeinflussen können. Du machst es dir also glaube ich etwas zu einfach, wenn du den Nutzen von cRAW gleich abschreibst. Unsere Vorstellungen der Sensorverarbeitungspipeline ist ebenfalls oft zu simpel: In einem der beiden von mir gezeigten Nikon Links wird u. a. erwähnt, dass viele A/D-Wandler-Implementierungen auf einfacher zu bauenden D/A-Wandlern aufbauen, kombiniert mit einem Zähler und einem "precision voltage comparator". Im beschriebenen Fall beschleunigt das den Capture-Prozess um das 8-Fache. Die quantisierten Daten des RAW-Sensors wären also tatsächlich nicht "lossy" und die Komprimierung eigentlich nur eine optimale Speicherung der sowieso vom Sensor gelieferten Daten. Für eine auf Geschwindigkeit ausgelegte Kamera durchaus ein brauchbares Design. Genau genommen ist nichteinmal klar, ob das "unkomprimierte" RAW der A700 nicht womöglich einfach ein entpacktes cRAW ist! Zumindest gibt es nichts offizielles dazu.

Deine Ausführung zu Reserven durch möglichst hohe Bitauflösungen kann ich so ebenfalls nicht einfach teilen. Zum einen gilt nunmal einfach "Garbage in" -> "Garbage out". Was nützen denn feiner aufgelöste RAW-Werte, wenn schon alleine Objektiv, AA-Filter und A/D-Wandler diese Auflösung einfach nicht bringen - das Leben ist kein Wunschkonzert.

Gruß,
Jochen

moin,

wenn ich mich recht entsinne, schafft die a900 auch in cRAW nicht mehr Bilder bis "buffer full" als im RAW-Modus (ich hatte das ausprobiert, aber bin mir jetzt nicht sicher). Das Wegschreiben der Daten dauert selbst mit einer Extreme Pro (90MByte/s) auf jeden Fall zu lange, um die 5B/s aufrecht zu erhalten.

Jochen, Deine links zum NEF-Format sind interessant, aber die Sony-cRAW-Kompression funktioniert fundamental anders. (Vorsicht: die "Kompression" z.B. der Dimage A2 ist wieder was anderes und definitv lossless). Die dort beschrieben NEF-Kompression stellt eine Art Gammakurve dar, wohingegen der Sony-Algorithmus eine Art HAM-Modus mit optionaler Tonwertkompression ist (Amiga-Freunde wissen, was ich meine).

Damit greift auch Dein Hinweis auf die Beschleunigung nicht, ist auch (bei der a900) nicht nötig: der Sensor hat auf jeder Spalte einen A/D-Wandler, und jeder der über 6000 A/D-Wandler muss pro Frame nur gut 4000 Werte digitalisieren. Das ist nun wirklich vom timing her nicht sehr anspruchsvoll...
Den Rest erledigen DSPs, die a900 hat mehrere davon.

Nebenbemerkung: alle mir bekannten schnellen A/D-Wandler basieren auf dem "umgekehrten" Prinzip; ich bin mir nicht mal sicher, dass es andere überhaupt (noch) gibt.
Noch mehr Speed kann man rausholen, wenn man den Zähler durch einen B-Tree ersetzt, dann ist man schon nach maximal <bit-Tiefe>-Schritten+Einschwingzeit fertig statt nach <zielauflösung>-Schritten.

Garbage-In > Garbage-Out: das Problem hast Du bei jeder Messung. Wenn man das aber zu Ende denkt, würden 8bit-A/D-Wandler oder sogar 6bit-Wandler völlig ausreichen... Warum sollte man 12bit, 14bit oder gar 16bit (bei MF-Rückteilen üblich) verwenden, welche viel aufwändiger sind...
Nein, lieber "Überabtastung" und hinterher in Ruhe den "Müll" (Rauschen, jetzt nicht wie hier üblich sondern als Rauschen im Sinne des universalen Messproblems zu lesen) erkennen und aussortieren/abschneiden/verwerfen. Denn alle o.g. Algorithmen machen per se-Annahmen, legen also vorher fest, was weggelassen wird. Nachträglich kann man dagegen feststellen, wo die Grenze zwischen Inhalt und Müll ist und situationsangepasst nur den Müll verwerfen.

Ok, real dürfte z.Zt. der Unterschied zwischen RAW und Sony-cRAW gering sein und bei 99% aller Bilder bei 99% aller Nutzer keine Rolle spielen. Es muss jeder für sich selbst entscheiden, ob sie/er diese marginale Reserve haben möchte oder nicht.

Das ist auf jeden Fall interessant - wobei man das auch noch mal versuchen könnte irgendwie empirisch auszuprobieren. Allerdings kann das bei Kameras wie der A550 wieder anders aussehen; man wird es nur nicht ausprobieren können, weil diese Kameras eben nur diesen Modus kennen.

:D - Ja HAM kenne ich noch sehr gut. Hatte selbst mal einen A500, A1200 und A4000. Für mich war das auch der Einstieg in die Programmierwelt (Copper, Blitter usw.). Ich meinte gar nicht, dass die Mechanismen von compressed NEF und cRAW ähnlich sind, sondern dass eben beides gewissermaßen verlustbehaftete Verfahren sind, deren realer Verlust, durch das Gesamtsystem zumindest stark relativiert wird. Dabei sind beide Verfahren natürlich ebenso unterschiedlich, wie JPEG zu beiden vollkommen unterschiedlich ist.

Für die A900 ist es vielleicht nicht nötig und womöglich wirklich bloß eine schnelle Komprimierung - aber bei der A300, A350, A450, A500 und A550 und vielleicht sogar A700 sieht das vielleicht wieder ganz anders aus. Die Column-Parallel A/D-Wandler waren eine A900 Neuerung; die anderen haben weniger. Das gilt auch für die DSPs. 14,2 Mio. x 7 FPS = ca. 100 Mio.

Nebenbemerkung (hat nichts mit deinem Post zu tun): Ich finde es immer wieder lustig, wie im Rahmen der Diskussion immer wieder erbost angemerkt wurde, dass man doch mit Algorithmen wie "bzip" oder "RAR" ebenso stark komprimieren könne und dass Ergebnis "lossless" wäre. Wer derartiges ernsthaft vorschlägt hat noch nie auf so hardwarenaher Ebene gearbeitet ;-).

Ich denke du meinst einen Binärbaum und keinen Bayer-Baum oder? ;). B-Tree ist eigentlich für letzteren die gängigere Bezeichnung. Aber klar - durch eine binäre Suche kann das noch verbessert werden.

Irgendwo muss man eben die Grenze ziehen - umgekehrt könnte ich auch fragen, warum Sony nicht 14bit-Wandler statt 12bit-Wandlern verbaut wenn doch zusätzliche Reserven so viel besser sind?

Du unterschätzt hier ein bisschen die Möglichkeiten, wie leicht es ist nachträglich noch den Müll vom nicht-Müll zu unterscheiden, weswegen ja durchaus schon vorher gegen so etwas vorgegangen wird: Also am besten Müll gar nicht erst aufzeichnen. Es bringt dem System nur unnötig Last, wenn es zufällige Werte im "Nachkommabereich" mit herumschleppt, obwohl man bereits weiß, dass nur die vorderen "Stellen" relevant sind.

99% der Bilder würde bedeuten, dass es für jedes 100ste Bild eine Rolle spielt - das wäre schon sehr deutlich. Die Ausschussquote wird SEHR viel geringer sein. Da sind vermutlich Fehlfunktionen der Kamera wahrscheinlicher. Genau das ist dann wieder die Informatiker-Denke: Es gibt Algorithmen, die streng genommen nur mit sehr hoher Wahrscheinlichkeit die Wahrheit sagen - aber die Wahrscheinlichkeit ist so hoch, dass das Ergebnis eher von kosmischer Strahlung gestört würde, als dass der Algorithmus falsch liegt. Ein Beispiel ist Miller-Rabin als Primzahltest. Ich schätze cRAW auf eine ähnliche Art ein: theoretisch könnte etwas schiefgehen, praktisch gesehen geht vorher (oder nacher) eher etwas anderes schief.

Gruß,
Jochen

Hallo,

da wir uns ziemlich einig über den Algorithmus für craw sind ist es an der Zeit, zu überlegen, welche Aufnahmesituationen evtl. einen Unterschied zwischen aus craw- und raw-Format entwickelten Bildern erkennen lassen.

Gruß,
Stuessi