Forum Übersicht - RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen - 4

ZITAT(Neonsquare @ 2014-01-22, 10:48) So wie es für mich aussieht ist die Deltakompression nur ein Aspekt der gesamten Kompression. Der eigentliche Schlüssel hinter der Frage wie RAW-Daten von einem 14bit ADC in einem Schema wie der 2x11bit + 7x4Bit Deltakompression dargestellt werden können liegt in einer Nicht-Linearen Repräsentation der Tonwerte: Einerseits werden die Tonwerte halbiert und dafür ein erhöhter Schwarzpunkt in die RAWs eingetragen und andererseits werden die linearen Tonwerte über eine nichtlineare Kurve auf 11 Bit abgebildet.[/quote]
Das ist schon richtig, aber die nicht-lineare Abbildung von (vermutlich) 14 Bit auf 11 Bit kommt einer Requantisierung gleich. Sie mag optimal an die Verhältnisse der Kamera angepaßt sein, aber ein kleiner zusätzlicher Fehler entsteht dabei immer. Den könnte man vermeiden, wenn man die 14 Bit-Daten 1:1 überträgt oder eine verlustfreie Kompression zur Anwendung bringt - es ist ja nicht so, daß das technisch nicht möglich wäre...

ZITATWenn man es extrem vereinfacht von der anderen Seite sehen möchte könnte man wohl sagen: Reine, lineare 14 Bit RAW-Daten sind hochredundant. Das unterste Bit besteht praktisch nur aus Rauschen. Auch der restliche Bereich ist nicht homogen und macht keine 13 Bit notwendig - was soweit ich mich erinnere sogar irgendwo an einem Beispiel von 12Bit RAW aus einer A900 demonstriert wird. Sony komprimiert den linearen Tonwertraum anhand von offenbar Sensor-spezifischen Kurven. Wenn das stimmt, dann ist das genau das "Wissen über den realen Eingabe-Wertebereich" den ich immer als fehlendes Puzzlestück gesehen habe.[/quote]
Mit dem Kurvenverlauf legst Du den Fokus aber nur auf einen Teilaspekt von Sonys Kompressionsverfahren, nämlich wie man die Daten an einem beliebigen, gedanklich isoliert betrachteten Punkt möglichst gut eindampfen kann und später wieder expandiert. Das Analogon dazu wäre wohl ein einfacher Dynamikkompressor und -expander. Das funktioniert nie ohne Verluste, aber es kann gut sein, daß der Fehler so gering bleibt, daß er keine nennenwerten Auswirkungen auf die Qualität hat.

Der Großteil unserer Diskussion oben bezog sich aber nicht auf die Kurve, sondern darauf, daß Sonys Algorithmus nicht jeden Wert für sich isoliert betrachtet und komprimiert, sondern eine Abhängigkeit zu einem mehr oder weniger willkürlich gewählten Block benachbarter Werte herstellt. Es ist also nicht so, daß wir die Kompression oder die spätere Expansion eines Wertes isoliert von anderen Werten im Umfeld betrachten können. Je nachdem, welche Werte in der Umgebung vorkommen, kann es sein, daß sich ein Wert ziemlich genau darstellen läßt oder eben auch nicht. Das funktioniert mit hoher Genauigkeit, wenn die Werte in der Nachbarschaft nicht allzuviel vom betrachteten Wert differieren, aber es erzeugt Fehler in Bereichen, in denen sich die Werte in der Umgebung relativ stark unterscheiden. Diese Fehler fallen in Bereichen, in denen "Chaos" herrscht, vermutlich kaum auf (nichtsdestotrotz existieren sie), aber zumindest in Übergangszonen zwischen mehr oder weniger homogenen Bereichen, also z.B. an Kontrastkanten oder Spitzlichtern werden diese Fehler als Artefakte, die über den jeweiligen Punkt hinaus in die Fläche gehen, sichtbar.

ZITATDie Frage die man sich nun stellen kann: Wäre eine "dumme" 14 Bit Speicherung nicht trotzdem besser?[/quote]
Absolut betrachtet eindeutig ja.
ZITATHätte diese potentiell weniger "Banding"?[/quote]
Ja, genauso wie eine Kompression, die einen Wert unabhängig von Werten in der Nachbarschaft betrachtet (zumindest in Bezug auf die zur Verfügung gestellte Auflösung - es wäre ja durchaus legitim, Nachbarwerte mit einzubeziehen, um eine wie auch immer geartete kompaktere Darstellung eines Wertes zu finden, solange der mögliche Wertebereich dadurch nicht eingeschränkt wird).
ZITATAngenommen die nicht-lineare Kurve maskiert insbesondere jene Bereiche, die aufgrund von Rauschen sowieso bedingt nutzbar sind - dann würden die zusätzlichen Bits bei "dummer 14 bit"-Speicherung praktisch nur aus Nicht-Information (= Rauschen) bestehen.[/quote]
Wie meinst Du das?
ZITATDiese Nicht-Information kann durchaus den Effekt haben Banding zu unterdrücken - aber denselben Effekt würde man durch gezieltes Dithern erreichen.[/quote]
Eine Form von Dithering würde ich in der Kompression auf die Wahl des Minimum-Wertes des jeweiligen Fensters anwenden, um einen durch den Algorithmus bedingten möglichen systematischen Fehler zu verdecken. Ob Sony sowas zur Anwendung bringt, wissen wir natürlich nicht - unsere ad-hoc-Kompression oben weist sowas natürlich noch nicht auf.

Dithering sollte meines Erachtens darüber hinaus auch nach der Expansion im Raw-Converter erfolgen.
ZITATDer Ansatz scheint besser als befürchtet, aber mein Bauchgefühl wäre einfach beruhigter, wenn man auch einfach eine "dumme" Repräsentation einstellen könnte. Vermutlich würde ich aber trotzdem auf cRAW weiter fotografieren.[/quote]
Mir geht es ähnlich:

Ich finde es gut, daß es cRAW gibt, obwohl wir oben ja gesehen haben, daß das Verfahren nicht verlustlos arbeitet und sich durchaus noch weiter verbessern ließe, indem bislang ungenutzte Parameterkonstellationen adaptiv für eine höhere Genauigkeit genutzt würden.

Trotzdem hätte ich gerne die Möglichkeit, komplett verlustfrei zu arbeiten. Dabei darf durchaus eine Kompression zur Anwendung kommen, aber dann bitte eine verlustfreie. Wenn man frühere ARW-Dateien (die noch keine cRAWs waren) z.B. mit einem verlustfrei arbeitenden Dateikompressor wie ZIP komprimiert, stellt man fest, daß sich ähnlich hohe oder gar bessere Kompressionsraten erzielen lassen wie mit Sonys verlustbehaftetem Verfahren. Sicherlich benötigt ein solcher Algorithmus mehr Ressourcen (Rechenzeit und Speicher) als Sonys Algorithmus, der für die parallele Verarbeitung von 128-Bit-breiten Datenströmen in DSPs optimiert ist und somit vermutlich nahezu verzögerungsfrei in Echtzeit arbeitet, aber man kann dem Anwender ja zur Auswahl stellen, ob er für maximale Serienbildgeschwindigkeit verlustbehaftete cRAWs wünscht, oder bei einer etwas langsameren Geschwindigkeit verlustfreie 14-Bit-RAWs mit oder ohne Kompression haben möchte (wobei je nach Speicherkarteninterface, Speicherkarte und Motiv die verlustfreie Speicherung mal ohne, mal mit Kompression schneller sein dürfte). Solange man die verlustfreie Kompression nicht im DSP implementiert, sondern dem Linux-basierten Backend überläßt (und ein kleines Päuschen vor dem Speichern jedes Bildes akzeptiert), wäre das mit minimalem Aufwand zu realisieren.

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2014-01-25, 3:04) Wie meinst Du das?[/quote]

Die linear repräsentierten Tonwerte werden unterschiedlich stark beeinflusst durch Störungen (Rauschen). Rauschen mindert letztlich die effektive Tonwertauflösung - und das eben nicht-linear. Auch wenn es hier im Rahmen der cRAW-Diskussion verdeutlicht wurde, gehe ich fest davon aus, dass jeder Hersteller derartige Kompressionskurven zur Aufbereitung der Sensorsignale benutzt. Die linearen Signale sind einfach hochredundant und eine Rauschminderung und Kompression kann am Ende einfach zu besser nutzbaren Ergebnissen führen als die "ungeschönte Wahrheit" . Das ist auch ein bisschen der Grund, warum mir immer etwas widerstrebt wenn von "Verlustfreiem RAW" gesprochen wird. Ich weiß wie es gemeint ist, aber der Weg vom Pixel zum Bit in der Datei wird begleitet von einer Menge unerwünschten und gezielt gewünschten "Verlusten".

ZITAT(matthiaspaul @ 2014-01-25, 3:04) Eine Form von Dithering würde ich in der Kompression auf die Wahl des Minimum-Wertes des jeweiligen Fensters anwenden, um einen durch den Algorithmus bedingten möglichen systematischen Fehler zu verdecken. Ob Sony sowas zur Anwendung bringt, wissen wir natürlich nicht - unsere ad-hoc-Kompression oben weist sowas natürlich noch nicht auf.[/quote]

Klar - es gibt immer noch eine Menge Fragezeichen. Das einzige was irgendwo klar ist: was Sony macht bringt durchaus gute Ergebnisse hervor. Was auch immer für Tricks dazu notwendig sind.

ZITAT(matthiaspaul @ 2014-01-25, 3:04) Dithering sollte meines Erachtens darüber hinaus auch nach der Expansion im Raw-Converter erfolgen.[/quote]

Auf jeden Fall - ich gehe auch davon aus, dass die guten RAW-Konverter das tun. Auch Photoshop dithert z.B. künstliche Verläufe - ohne das würden sie auf heutigen Displays grauenhaft aussehen.

Was ist es eigentlich was wir konkret von Sony als "umkomprimiertes" Format erwarten?

1) Keine Deltakompression:
Mittlerweile scheint es ja konkrete Beispiele zu geben - Ich hatte bislang immer gedacht, dass bei zunehmender Pixelauflösung die Problematik immer mehr verschwindet - doch ich glaube gerade der 36MP-Sensor hat nun Pixelpeepern die Möglichkeit gegeben gezielt Beispiele zu finden.

2) Tonwertkompression
Speicherung von "lineareren" Werten? Ich bin unschlüssig ob ich das wirklich will - zu einem gewissen Grad spielt da ja auch die resultierende Bildqualität mit rein. Zu rohe Ergebnisse bieten zwar mehr Potential, aber das ist dann auch nur mit entsprechend Aufwand nutzbar.

Gruß,
[neon]

ZITAT(tatatu @ 2014-01-25, 0:22) Ich habe da nochmals ein bisschen nachgelesen...[/quote]
ZITAT(matthiaspaul @ 2014-01-25, 1:34) Ich weiß es auch nicht, möchte aber anmerken...[/quote]
Aha und Danke!

ZITAT(Neonsquare @ 2014-01-25, 14:18) Was ist es eigentlich was wir konkret von Sony als "umkomprimiertes" Format erwarten?

1) Keine Deltakompression:
Mittlerweile scheint es ja konkrete Beispiele zu geben - Ich hatte bislang immer gedacht, dass bei zunehmender Pixelauflösung die Problematik immer mehr verschwindet - doch ich glaube gerade der 36MP-Sensor hat nun Pixelpeepern die Möglichkeit gegeben gezielt Beispiele zu finden.

2) Tonwertkompression
Speicherung von "lineareren" Werten? Ich bin unschlüssig ob ich das wirklich will - zu einem gewissen Grad spielt da ja auch die resultierende Bildqualität mit rein. Zu rohe Ergebnisse bieten zwar mehr Potential, aber das ist dann auch nur mit entsprechend Aufwand nutzbar.[/quote]
Nach der A/D-Wandlung findet eine wandlerspezifische Linearisierung oder andere geeignete Parametrisierung statt, und die Daten werden in der Kamera sowieso weiterverarbeitet. Daß es dabei in einem digitalen Rechenwerk zu Rundungsfehlern kommt, ist normal, sollte aber bei einem genügend breiten Datenpfad und einer überlegten Implementierung auf das unvermeidbare Minimum beschränkt bleiben. Insofern habe ich diesen Punkt, zu dem ich auch die Tonwertkompression zähle, bisher nicht als wirklich kritisch angesehen. Fehler betreffen hier je nach Betrachtungsweise entweder einzelne isolierte Punkte oder die Gesamtheit aller Punkte, sind also halbwegs gleichmäßig verteilt (Dithering lassen wir mal außen vor) und damit praktisch nicht vom Grundrauschen unterscheidbar.

Bauchschmerzen habe ich jedoch mit der hier zur Anwendung kommenden Deltakompression, die für meinen Geschmack zu wenig adaptiv arbeitet und bei bestimmten Eingangsdaten flächige Artefakte in der näheren Umgebung erzeugt. Dadurch fällt dieser Fehler ins Auge, wird als solcher erkennbar.
Die Sache sähe schon ganz anders aus, wenn der Algorithmus die Daten in den Bereichen, in denen sichtbare Artefakte auftreten (also eben gerade an den Kontrastkanten), nicht mit verminderter Genauigkeit weitergeben würde, wenn der Startpunkt für einen Datenblock in gewissen Grenzen verschoben werden könnte und die Blockgröße angepaßt werden könnte. Die erste Maßnahme ließe sich noch relativ einfach und mit wenig zusätzlichem Rechenaufwand realisieren, aber durch die anderen beiden Punkte würde der Algorithmus seine besondere Eignung für 128-Bit-breite Datenpfade verlieren und wohl auch schwieriger zu parallelisieren sein. An dieser Stelle würde sich dann die Frage aufdrängen, warum man nicht gleich auf ein technisch verlustfrei arbeitendes Kompressionsverfahren ausweicht. Das heißt im Umkehrschluß aber auch, daß Sony für ein komprimierte Ablage vielleicht ein ganz guten Kompromiß gefunden hat - ärgerlich ist nur die fehlende Wahlmöglichkeit.

Viele Grüße,

Matthias

Übersicht über Unterstützung der verschiedenen Sony-ARW-Rohdateiformatvarianten in Sony-Kameras (vielleicht besonders interessant in Hinblick auf mögliche Unterschiede zwischen ARW 2.3.0 und ARW 2.3.1 sowie darauf, welche Kameras komprimierte oder unkomprimierte Daten speichern):

http://www.mi-fo.de/forum/viewtopic.php?t=34887

Viele Grüße,

Matthias

Alexey Tutubalin ("lexa" und Iliah Borg diskutieren das Thema ebenfalls anhand eines speziellen Visualisierungsmodus ihres RawDigger-Werkzeugs:

http://www.rawdigger.com/howtouse/sony-cra...ation-detection
http://www.dyxum.com/dforum/sony-lossy-com...opic105317.html
http://www.sonyuserforum.de/forum/showthread.php?t=144459

Viele Grüße,

Matthias

Alexey Tutubalin hat in seinem Blog eine Übersicht über die resultierenden Bitbreiten der Bilddaten nach der Dekompression und Linearisierung bei unterschiedlichen ISO-Einstellungen mit verschiedenen Sony-Kameras erstellt.

Er schreibt:
ZITATThe tone curve (decompression curve) is the same for all Sony cameras using cRAW format (all NEX, all SLT, all RX*, A7/A7R, and latest DSLR-Axxx).

A7(R), SLT-A99 and RX1® cameras are really 13-bit in shadow part (below level 1488 after decompression and bias subtration): only even bins are non-zero, while odd bins are zero (to see this clearly you need to examine small selection. On the entire image the picture is not so clear because of possible post-processing, such as vignetting compensation)

Other cRAW cameras (NEX, RX100, remaining SLT models) are 12-bit in shadows: only one bin of 4 is non-zero.

Here is the post in my blog (in Russian) with all Sony models bit-count table: http://blog.lexa.ru/2014/01/25/o_bitnosti_u_kamer_sony.html

Also, please note, that noise-reduction is performed after ADC, so histogram patterns are not so clear if noise reduction is turned on.[/quote]

http://blog.lexa.ru/2014/01/25/o_bitnosti_u_kamer_sony.html

ModellISO 100ISO 400ISO 3200ILCE-3000121211ILCE-712.912.912.7ILCE-7R131312.9DSC-RX112.912.912.9DSC-RX1R12.912.912.9DSC-RX10121211.6DSC-RX100121211.6DSC-RX100II121212DSLR-A10012----DSLR-A20011.511.412DSLR-A23011.511.59DSLR-A29011.611.69DSLR-A3001211 (ISO 800)10 (ISO1600)DSLR-A33011.511.59DSLR-A35011.911.912DSLR-A38011.711.712DSLR-A39011.611.612DSLR-A45011.611.611.3DSLR-A50011.811.811.3DSLR-A55011.811.811.3DSLR-A58011.811.811DSLR-A700 cRAW11.8----DSLR-A700 uncompressed11.611.611.2DSLR-A850 cRAW------DSLR-A850 uncompressed11.511.511.2DSLR-A900 cRAW11.611.611.3DSLR-A900 uncompressed11.611.611.2NEX-311.811.811.6NEX-3N121211.3NEX-511.811.811.6NEX-5N11.811.811NEX-5R121210.6NEX-5T121210.6NEX-6121210.6NEX-711.811.811NEX-C311.311.311NEX-F3121211.3SLT-A33121211SLT-A3511.811.811SLT-A37121210.6SLT-A55V11.311.310.6SLT-A57121210.6SLT-A58121210.6SLT-A65V11.811.810.6SLT-A77V11.811.810.6SLT-A99V131312.9
Auch der russische Artikel ist interessant.

Viele Grüße,

Matthias

Vielleicht interessiert das hier noch im Zusammenhang mit den Auswirkungen des cRaw-Formates auf die Bildqualität:
http://www.fredmiranda.com/A7R-review/
ZITATSony’s compressed RAW (cRAW) can be described as a "visual" lossless compression but technically it's nearly lossless. Overall, you would be hard-pressed to find artifacts due to compression. Basically, in my real world landscape images, I was unable to detect any problems. Sony’s files size remains reasonably consistent at around 37mb regardless of the complexity of the scene so the benefit of the compression is getting 40-50% smaller files when compared to fully uncompressed RAWs...When I came back home and examined the files, I hunted for artifacts. I finally found them hiding in the blacks - near the transition between light and dark. But, it took terrible lighting and ridiculously harsh conditions to capture it. Don't get me wrong. It's there, but it's rare.

At first, I though it could be an issue with Adobe's demosaicing algorithm, but the artifacts show up on Capture One and Sony's Image Data Converter as well.[/quote]