RAW = cRAW?

[ABC_Freak]

Servus,

mir ist aus Zufall aufgefallen das z.b. die A900 ca. 38mb RAWs auswirft und in cRAW ungefähr 25mb.

Schätzung: (24Mp x 12bit)/8 = 36mb, kommt hin mit vorschau jpg

Meine RAW files aus der A200 sind aber keine 15mb [(10mp x 12bit)/8] groß sondern 8-9mb. Dort kann ich aber keine cRAW einstellen sondern nur RAW - RAW+JPEG.

Sind diese RAW files also alle cRAW?

Ist keine überlebenswichtige Frage, interesiert mich aber :-)

Danke schon mal.

[CarpeDiemJen]

Das cRAW steht glaub ich für komprimierte RAW Daten was natürlich dann auch die Verarbeitungszeiten verlängern dürfte, könnte ich mir vorstellen wobei das speichern wieder schneller geht. Also glaub ich nicht ganz das das cRAW was bringen sollte außer verluste in der Qualli vll.

Bei der A200 hast du ganz normales RAW die sind blos kleiner weil du ja nur die hälfte an Pixeln hast nich oder?

LG
Jens

[ABC_Freak]

nein glaube ich nicht, denn die 900er raws sind ungefaehr so gross wie ich mir das vorstelle (siehe schaetzung) die cRaws sind kleiner (logisch)

meine raws bei der A200 sind kleiner als ich es bei einem normalen raw vermuten wuerde, naemlich so gross wie die heruntergerechnete Groesse einer a900 cRaw.

Deswegen die frage, bei der A200 wuerde ich mit einer Raw groesse von 15Mb rechnen, die ich aber def. nicht habe.

[Sparcky]

Die A100 macht etwa die gleiche RAW-Größe wie die A200. Die Bilder sind bei mir etwa zwischen 7 und 12 MB groß.

[Reloaded]

Ich glaube, das hängt bei cRaw davon ab, wieviel im Bild drin ist. Ein Sensordreck-Testbild wird garantiert kleiner wie Oma's Garten, wo alle Farben und Formen drin vorkommen. Weiterhin denke ich, dass die kleinen Alphas das cRAW einfach als normales RAW-Format beinhalten (da es in dieser Verbraucherklasse sowieso keinen Unterschied macht, ob das RAW komprimiert ist oder nicht), während die grossen Alphas in den Genuss von purem RAW kommen...

[Ernie]

Die Raws der A700 sind ca. 18 MB groß. Bei CRaw schrumpft die Größe auf ca. 12 MB. Daher müssen die Raws der A200 und auch der A100 komprimiert sein. Wie von ABC_Freak schon geschrieben müssten die Raws der A200 ohne Kompression auf ca. 15 MB kommen.

[roli_ch]

Mit der A700 fotografiere ich übrigens immer auf cRAW. 12MB scheinen mir für den Platz auf der Festplatte doch noch etwas verträglicher als 18MB und als ich ganz am Anfang mit der Kamera einmal die beiden Formate etwas verglichen habe, konnte ich nicht wirklich einen Qualitätsunterschied fetstellen.

[Sparcky]

Bei cRAW's wird die Dateigröße durch rausrechnen eines Bildpunktes und somit der Verkleinerung der Auflösung um 30% reduziert.
Die Kompression ist immer die Gleiche.

Ein wirklicher Unterschied ist dabei nicht zu sehen. Lediglich die cRAW's sind in der Vergrößerung etwas fleckiger in den Farben.

Die kleinen Kameras produzieren "echte" RAW's.

[ddd]

moin,

bei der a900 und a700 sind die cRAWs kastrierte RAWs: nur 8bit/Pixel statt 12bit/Pixel.
Das ist keine verlustfreie Kompression!
Sparcky hat definitiv nicht Recht ;), die (Orts-)Auflösung der RAWs und cRAWs ist gleich.

Man merkt das nur bei sehr weichen Farbverläufen oder wenn man die Dynamikreserve antasten muss, da man bei der Belichtung geschlampt hat (passiert mir öfter :oops: ) oder das Motiv den Dynamikumfang des normalen Bereiches überrissen hat.

Übrigens sind selbst Innenaufnahmen des Objektivdeckels bei der a900 ca 36MByte (RAW) bzw. 24MByte (cRAW) groß. Das ist auch nicht verwunderlich, der unvermeidliche Rauschanteil sorgt für eine sehr schlecht verlustfrei komprimierbare Datei (ein "weißes Rauschen" kann man gar nicht verlustfrei komprimieren).

Wenn die "Kleinen" RAWs liefern, die deutlich weniger als 1,5Byte/Pixel groß sind, wird bereits an den RAWs gefummelt. In welcher Weise kann man nur mittels Dateianalyse feststellen, oder Sony verrät es (extremst unwahrscheinlich). Die einzelnen Farbkanäle sind TIFFs, die könnte man extrahieren und anschauen z.B.

Eventuell mal mit PhilHarveys ExifTool reinschauen, die zeigen z.B. die Bittiefe an, und die muss stimmen, denn sonst lässt sich das RAW nicht mehr "entwickeln".

[ABC_Freak]

moin,

also wird an den A200 Bilder "irgendwas" gemacht. Ich war also zumindest nicht auf dem Holzweg. Danke für die Antworten.

Weis schon jemand was über die A500/550 das machen?

[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]

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




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-consolidated-craw-compression-thread_topic22802_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 :top:
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 :flop: 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).

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 :?: