[Joshi_H]

Moin,

Im Handbuch zur A700 steht wörtlich und tatsächlich mit all diesen Anführungszeichen:

"c" bei "cRAW" steht für "komprimiert"

Als Fußnote steht dann noch:

Die Daten werden um 60 bis 70% im Vergleich zu einem nicht komprimierten Bild komprimiert. Verwenden Sie diese Einstellung, wenn Sie möglichst viele Bilder aufnehmen möchten.

Also mal ehrlich: Auf Texte dieser Art im Handbuch kann man doch echt verzichten, oder?! Es ist so, dass eine Komprimierung verlustfrei sein kann. Im diesem Falle ist sie aber mit Verlust verbunden, denn sonst würden die Dateien bei der Bearbeitung durch z.B. den Image Converter wieder in der Größe wachsen - so wie beim Auspacken einer Zip-Datei. Ehrlich gesagt würde mich aber eine Funktionalität dieser Art schon ansprechen: Komprimierung á la zip in der Kamera (die Rechenleistung sollte das hergeben und "entzippen" mit Image Converter.

Bisher habe ich gedacht, dass die Komprimierung bei cRAW mit geringen Verlusten behaftet sind - wenn ich aber lese, dass von 12-bit auf 8-bit reduziert wird, dann werde ich nur noch das RAW-Format (ohne "c") benutzen, denn Speicherplatz sollte im Jahre 2009 das geringere Problem sein.

Grüße,

Jörg

[oduis]

Hallo,

ich hatte das cRAW vor einiger Zeit mal untersucht, hier das Ergebnis:
http://visualbakery.oliverduis.de/Sony_cRAW_vs_RAW.html

Wie ich in damals in einem developer-chat dcraw fand, ist es nicht so simpel mit 8 bit vs. 12 bit. Vielmehr werden wohl ein paar Punkte genau und die anderen als Differenz davon ausgedrückt.

Gruß
Oliver

[X-700]

Zitat von oduis

Hallo,

ich hatte das cRAW vor einiger Zeit mal untersucht, hier das Ergebnis:
http://visualbakery.oliverduis.de/Sony_cRAW_vs_RAW.html

Wie ich in damals in einem developer-chat dcraw fand, ist es nicht so simpel mit 8 bit vs. 12 bit. Vielmehr werden wohl ein paar Punkte genau und die anderen als Differenz davon ausgedrückt.

Gruß
Oliver

Na ja, Rauschen ist wohl nicht das probate Mittel, um eventuelle Schwächen eines Kompressionsverfahrens auszuloten oder gar offen zu legen.
Wenn man davon ausgeht, daß Sensorrauschen statistisch unabhängige Einzelwerte liefert, dann hat ein wie auch immer gearteter DPCM- oder ADPCM-Algorithmus überhaupt keine Chance, die Datenmenge zu verringern. Im Gegenteil, die Differenzwerte benötigen weiterhin die volle Wortbreite. Da gibt es nichts wegzuwerfen.
Da wird noch mehr passieren: mindestens noch eine Art Transformationscodierung mit abschließender Entropiecodierung.

Für den Vergleich RAW vs. cRAW wäre ein Testbild, das gleichermaßen Farbflächen, regelmäßige Muster und Rauschanteile besitzt, sinnvoller.

Du siehst ja an den Bildern selber, daß jedes anders aussieht.

[oduis]

Na das ist ja gerade die Aussage: ein DPCM hat Probleme, wenn du z.B. statistisches Rauschen hast, da Rauschen ja gerade geprägt ist von einzelnen Pixeln, die sich ungewöhnlich und massiv vom Nachbarn unterscheiden.
Die Größe der cRAW in so einem Rauschfall aber immer noch kleiner ist, also werden die Sony Entwickler nicht gesagt haben "ok, Kompression geht bei dem Bild schlecht, lass das mal das volle RAW speichern", sondern Zulasten des Details bei starken Sprüngen zwischen Pixeln einfach abgeschnitten haben. Ergo sieht kann man die Differenz beim Rauschen sehen, aber weniger bei gleichmäßigen Farbübergangen.
Nur mit einem DPCM-Typ zu arbeiten statt einfach pauschal von 12 auf 8 Bit Auflösung zu gehen macht auch Sinn, da es ja nun doch wenige Motive gibt, bei denen es ausgeprägte Bitsprünge gibt (außer Rauschen), aber viele, bei denen es auf weiche Farbübergänge ankommt.
Deckt sich auch mit meinem bisherigen Beobachtungen, da cRAW bei gleichmäßigen Übergängen (z.B. Himmel zur Sonne am Abend o.ä.) keine Probleme zu haben scheint.
Mit der neuen Firmware kann man den RAW-Rauschfilter aber ja ganz abschalten. Wenn ich mal Zeit habe wiederhole ich das Experiment nochmal, dann werden die Ergenisse deutlicher.

[ABC_Freak]

wie sieht es denn bei cRaw mit harten kanten aus? Das ist kein Rauschen und trotzdem muss ein harter übergang da sein.

Mein Herleitungsversuch:

Wenn ich das richtig verstanden habe wird statt Pixel für Pixel als 12bit Wert zu beschreiben, für eine Menge an benachbarten Pixeln ein Offset und für jeden weiteren Pixel ein Delta gespeichert.

Nimmt man also eine 9x9 Pixelmatrix hat man 12bit + 8*8bit = 76bit was nur ein wenig mehr ist als 9*8bit sind, womit man für das ganze bild insgesamt auf etwas mehr als 8bit codierung pro Pixel kommen würde (8,44bit/pixel).

Je mehr Pixel für eine solche "Gruppenkodierung" verwendet werden desto näher kommt man an 8 bit pro Pixel. Je weniger desto mehr gehts in die 12 bit Richtung (wobei man bei 2 Pixel auf 10 bit und bei 4 Pixel schon auf 9bit kommt)

Schwarz-Weis-Kanten müssten dann, wenn sie zwischen das Pixelgruppenraster fallen, nicht richtig Dargestellt werden (je nach Strategie bei der Umrechnung).
Rauschen: bei hohen Werten die 256 delta überschreiten würde nach meiner Logik ähnliches gelten.
Ist das Rauschen gering und sind die übergänge der zu messenden Werte innerhalb des Deltabereiches, sollte dies sogar komplett verlustfrei funktionieren. Gilt eines von beidem nicht, treten Verluste auf.

Soweit meine Gedankenspiele, ich hoffe ich bin da nich so arg auf dem Holzweg.

Warum nicht standardmäßig ein verlustfreies Verfahren angewendet wird kann ich mir nur dadurch erklären das die DSPs das evtl. nur umständlich ausführen können und somit viel länger bräuchten, was auf die Serienbildgeschwindigkeit geht wenn der Größenunterschied weniger Zeit braucht ihn zu Übertragen als ihn "herauszurechnen".

Gruß,
Stefan

[danichtfuer]

Zum Thema kleinere Daten bei den a200 RAWs:
die RAW-Daten der CCD-Sensoren haben generell kleinere Dateigrößen, weil diese sich gegenüber CMOS-Sensoren besser verlustlos (LZW) komprimieren lassen. Das hat was mit der Art und Weise zu tun wie die Daten von dem Chip ausgelesen werden. Bei CCD geschieht das in Reihe, bei CMOS für jedes Pixel individuell. Durch das Auslesen "in Reihe" erreicht man bei der (höchstwahrscheinlich) angewendeten LZW-Komprimierung bessere Ergebnisse – RAW-Daten sind kleiner, enthalten aber genauso viel Bildinformation.

[Suchlicht]

Hi

Zitat von Joshi_H

Also mal ehrlich: Auf Texte dieser Art im Handbuch kann man doch echt verzichten, oder?! Es ist so, dass eine Komprimierung verlustfrei sein kann. Im diesem Falle ist sie aber mit Verlust verbunden, denn sonst würden die Dateien bei der Bearbeitung durch z.B. den Image Converter wieder in der Größe wachsen - so wie beim Auspacken einer Zip-Datei.

Tut sie denn genau das nicht? Wenn Du z.B. mit ACR oder mit Lightroom ein CRAW in DNG konvertierst, wird das DNG grösser, als wenn man diese Konvertierung mit einem RAW vornimmt. Man müsste also mal verlässlich den Speicherverbrauch des Rechners messen, wenn eine RAW und eine CRAW-Datei z.B. im IDC geöffnet wird.

Ehrlich gesagt würde mich aber eine Funktionalität dieser Art schon ansprechen: Komprimierung á la zip in der Kamera (die Rechenleistung sollte das hergeben und "entzippen" mit Image Converter.

Das war eigentlich bisher mein Verständnis davon und auch Gar Friedman beschreibt das in seinem Buch zur a900 so und weisst darin sogar noch auf eine Meinungsverschiedenheit zu David Kilpatrick hin.


cu

[oduis]

Ok, finale Aufklärung: hab den Post gefunden mit dem Kommentar von dem Typen, der sich den realen Code zum Decodieren angesehen, genauer gehts nicht:

After a quick look at dcraw, cRaw is indeed lossy, and using 8 bits.
It seems that at each group of 16 bayer pixels, it stores the max value, and then the following 16 pixels will be stored using 8 bits with values that can go up to this max value.
So overall dynamic range is preserved, but you only have 8bits of dynamic per 16 pixels.
This is a very simple scheme, and for sure it could have been a bit more efficient, but overall it's not that bad.
(http://www.dyxum.com/dforum/the-cons...802_page1.html)

Zu Deutsch:
=> Delta-Verfahren über 16 BAYER-Pixel (Achtung, Bayer, nicht Bildpixel am Ende!)
=> Volle 12 Bit Dynamik, solang es nicht innerhalb von 16 Pixel zu großen Sprüngen kommt (die dürfen nur nur 8 Bit groß sein, sonst Verlust)
=> Es gibt damit wie vorhergesagt Probleme beim Rauschen und bei sehr harten Kanten (innerhalb von 16 Pixel). Farbübergänge sind kein Problem.

Aber in der Realität lässt sich wohl nur bei extremen Motiven und auf 100% ein realer Verlust nachweisen. Also solange man nicht Astronomie-Fotografie o.ä. macht...

PS: Ich fotografiere trotzdem lieber auf RAW, da ich gerne in DNG konvertierte. Die (verlustlose) DNG-Komprimierung klappt bei RAWs besser als bei cRAWs. Also am Ende auf der DVD ist mit RAW=>DNG kleiner als cRAW oder cRAW=>DNG.

[ddd]

moin,

Danke oduis für das Raussuchen
Sorry, ich habe mich an der vollkommen statischen Größe der Dateien orientiert (die geringen Differenzen liegen ausschließlich an den eingebetteten jpeg-Thumnail- und Vorschaubildern) und den Angaben im EXIF-Header im Vergleich RAW/cRAW (a900). Ich habe gerade nochmal nachgesehen: selbst ein (fast) vollkommen schwarzer Frame (Boden-Feuerwerk) ist RAW 38MByte groß.
Mit 7z lässt sich diese RAW-Datei auf knapp 9MByte verlustlos eindampfen, es dauert aber einige 10 s (dualcore 2,4GHz, genug RAM, ohne Last). Ein "normales" Bild lässt sich mit 7z deutlich schneller komprimieren, allerdings nur auf ca. 24MByte. 7z ist für sowas suboptimal, aber liefert schon mal einen Anhaltspunkt (7z ist effektiver als zip und schneller als bz2).

Am meisten störte mich am Anfang an cRAW, dass der IDC (und andere Programme) deutlich länger brauchten, die kleineren Dateien aufzumachen. In der Kamera bringt es gar nix, die Pufferkapazität bei Serienaufnahmen usw. wird nicht größer.
Dank oduis' Hinweis ist mir auch klar warum: das Verfahren erinnert entfernt an den HAM-Modus der seligen Amiga, geschickt eingesetzt kann man damit mit minimalen Resourcen sehr viel erreichen, aber es ist aufwändig und gelingt im generischen Fall eigentlich fast sicher nicht.
Mein Fazit: für die Tonne Besser wäre ein echter verlustloser Komprimierer auf Ebene der Pixeldaten, der könnte sogar Speed bringen (die Schreib-/Lesegeschwindigkeit ist geringer als die Verarbeitungsgeschwindigkeit eines gut angepassten Algorithmus, speziell wenn dieser hartverdrahtet in der Kamera on-the-fly von einem DSP ausgeführt wird) statt wie dieser Pseudo-Komprimierer effektiv Speed und teilweise Qualität zu kosten und nur eine geringe und statische Speicherplatzersparnis zu bringen.

Allerdings ist damit immer noch unklar, wie die kleinen Modelle die offenbar schwankende Größe der RAWs erzeugen.
Wie ist das bei der a100?
Es kann ja sein, dass ab der a200 ein Komprimierer wie oben vorgeschlagen implementiert ist, was auch cRAW seines Sinnes berauben würde und damit das Weglassen dieses "Schrott"modus erklären würde. Allerdings stellt sich dann die Frage, warum bei der nach der a200 erschienenen a900 noch der cRAW-Modus der a700 implementiert ist. Naheliegende Vermutung: die a900 ist viel "älter", als es den Anschein hat (es sprechen noch mehr Hinweise dafür).

Zitat von danichtfuer

Zum Thema kleinere Daten bei den a200 RAWs:
die RAW-Daten der CCD-Sensoren haben generell kleinere Dateigrößen, weil diese sich gegenüber CMOS-Sensoren besser verlustlos (LZW) komprimieren lassen. Das hat was mit der Art und Weise zu tun wie die Daten von dem Chip ausgelesen werden. Bei CCD geschieht das in Reihe, bei CMOS für jedes Pixel individuell. Durch das Auslesen "in Reihe" erreicht man bei der (höchstwahrscheinlich) angewendeten LZW-Komprimierung bessere Ergebnisse – RAW-Daten sind kleiner, enthalten aber genauso viel Bildinformation.

sorry, aber das ist leider so nicht richtig. Erstens sind die RAW/cRAW-Daten der a700/850/900 gar nicht komprimiert (cRAW kann man im engeren Sinne nicht als Kompression bezeichnen), zweitens ist LZW zwar bei TIFF optional (die meisten RAW-Formate nutzen intern TIFF), aber hier eher nicht für Bilder sondern für grafische Strukturen geeignet (Druckvorlagendateien z.B.), es ist ein recht altes Verfahren, heute gibt es (etwas) effektivere Algorithmen. Das Ausleseverfahren hat nix mit der Komprimierbarkeit zu tun. Klassische Kompressionsverfahren entfernen Redundanz aus den Daten, daher lassen sich Texte oder geometrische Grafiken so schön komprimieren. Bilder, speziell von grundsätzlich rauschenden Sensoren aufgenommene, enthalten aber eher wenig Redundanz. Selbst einfarbig erscheinende Flächen sind eben nicht einfarbig. Hier hängt es von der Korrelation der Daten ab, ob überhaupt ein endlicher Kompressionsfaktor herauskommt. Im Extremfall (weißes Rauschen) gibt es gar keine Korrelation, damit keinerlei Redundanz und folglich keine (verlustlose) Komprimierbarkeit. Die einfachste Methode zum Nachweis, dass ein Signal ein weißes Rauschen ist, ist übrigens die Nicht-Komprimierbarkeit zu zeigen...

Ob die RAWs der a200ff wirklich "alle" Bildinformationen enthalten, ist bisher hier nicht geklärt. Wer meldet sich freiwillig zu Quellcode-Analyse des ARW-Moduls von dcraw