[Neonsquare]

@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.

Zitat von Dewus

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

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.

Zitat von Dewus

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

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

[Karsten in Altona]

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

[Neonsquare]

@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

[Dewus]

Zitat von Neonsquare

Vorsicht! Der Vergleich mit JPEG hinkt hier ziemlich.
...

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

[ddd]

moin,

Zitat von Dewus

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?

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.

[Ta152]

Zitat von ddd

< snip >

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

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

[Neonsquare]

@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

[ddd]

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.

[Neonsquare]

Zitat von ddd

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.

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.

Zitat von ddd

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

- 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.

Zitat von ddd

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.

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

Zitat von ddd

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.

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.

Zitat von ddd

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...

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?

Zitat von ddd

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.

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.

Zitat von ddd

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.

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

[Stuessi]

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