DNG Komprimiert in der S2 verlustfrei?

[lik]

Advertisement (gone after registration)

Danke, Danke - als Mac-User ist FLAC nicht so das Format, aber andere "Lossless"-Formate schon.

 

Aber meine Paranoia ist eh' geheilt - werde komprimieren und mich der Automatik des Dekomprimierens erfreuen

 

HG

Lik

[Advertisement]

The Leica Q3 is available for pre-order at B&H Photo Video and Adorama

[isaac]

Hallo Michael!

Wenn ein Bit der Bilddaten einer unkomprimierten Datei kippt, sehen am Ende einige wenige Pixel komisch aus,

Wenn ein Bit umkippt, ist doch auch nur maximal ein Pixel betroffen.

aber wenn das bei einer verlustfrei komprimierten Datei passiert, können die Auswirkungen gravierender sein.

Na ja, wenn der Dekompressor "robust" ist, dann ist maximal eine Pixelreihe verloren, wenn der Dekompressor dazu auch noch "intelligent" ist, wiederum nur ein Pixel.

Und da ein unbotmäßtiges Pixel des Sensors eigentlich sehr leicht auszumappen ist, können wir berechtigt hoffen, daß der "Intelligente" Dekompressor sowas ebenfalls kann/macht.

 

Also eher nur ein Mailüfterl im Wasserglas, die ganze Sorge...

 

PS: aber eine wirklich wirksame, verlustlose Kompression (etwa auf 50%) ist schon eine echte Herausforderung an die Rechenleistung.

[mjh]

Wenn ein Bit umkippt, ist doch auch nur maximal ein Pixel betroffen.

Wenn ein Pixel der Rohdaten fehlerhaft ist, betrifft das so ungefähr neun Bildpixel, nämlich dieses und die acht Pixel drumherum. Man kennt das ja von den „stuck pixel“, die auch immer helle Flecken erzeugen, die ungefähr neun Pixel umfassen, obwohl der Auslöser ein einziges schadhaftes Sensorpixel ist.

 

Na ja, wenn der Dekompressor "robust" ist, dann ist maximal eine Pixelreihe verloren, wenn der Dekompressor dazu auch noch "intelligent" ist, wiederum nur ein Pixel.

Ein verlustloses Kompressionsverfahren erzeugt ja einen Strom von Bits; welche Bits dann zusammen ein Pixel ergeben, muss man erst einmal herausfinden. Das ist eben der Unterschied zur unkomprimierten Datei, bei der man immer weiß, dass die Bilddaten in gleich langen Zeilen von Pixeldaten organisiert sind, wobei jedes Pixel zwei Bytes belegt. Die verlustbehaftet komprimierten Dateien der M8 und M9 sind ebenso regelmäßig organisiert; die Pixel belegen lediglich ein statt zwei Bytes.

 

Und da ein unbotmäßtiges Pixel des Sensors eigentlich sehr leicht auszumappen ist, können wir berechtigt hoffen, daß der "Intelligente" Dekompressor sowas ebenfalls kann/macht.

Ein schadhaftes Sensorpixel wird schon vor der Kompression ausgemappt; das spielt bei der Dekompression gar keine Rolle mehr. Die Frage ist, was für eine Folge eine Beschädigung der bereits komprimierten Datei hat.

 

Also eher nur ein Mailüfterl im Wasserglas, die ganze Sorge...

Große Sorgen muss man sich deshalb nicht machen, das ist richtig.

 

aber eine wirklich wirksame, verlustlose Kompression (etwa auf 50%) ist schon eine echte Herausforderung an die Rechenleistung.

Das ist wohl wahr. Deshalb schaffen es die M8 und M9 ja auch nicht; ihr Prozessor ist zu langsam. Die verlustbehaftete Quadratwurzel-Kompression benötigt hingegen fast gar keine Zeit.

[isaac]

Hallo Michael!

Wenn ein Pixel der Rohdaten fehlerhaft ist, betrifft das so ungefähr neun Bildpixel, nämlich dieses und die acht Pixel drumherum.

Ja, du hast natürlich recht, weil man ja nicht weiß, welches Pixel betroffen ist und der RAW-Konverter nur seine Arbeit macht.

Aber ich denke, beim Lesen vom Datenspeicher wird man schon die gröberen Probleme haben, wenn die Prüfsumme nach dem Lesen ungleich zu der ist, die beim Schreiben ermittelt worden ist.

Im Falle einer Datenrettung kommt es darauf wohl auch nicht mehr an...

Ich denke, wir können uns auch darauf einigen, daß bei einem umgefallenen Bit in einer verlustlos komprimierten Datei eine Pixelzeile - im schlimmsten Fall komplett - gestört wird.