Hohe ISO - größere Dateigrößen?!

[Frank Klemm]

RAW wird verlustfrei komprimiert: Sonst wäre das Bild einer Kamera 4000 x 3000 Pixel x 2x3 Byte für die Farben = 72.000.000 Byte = 72 MB groß; meistens ist es jedoch kleiner.

Wohl eher 4000 x 3000 x (12/8) = 18.000.000 oder 4000 x 3000 x (14/8) = 21.000.000 Bytes. Man braucht nicht jedes Pixel 3x abzuspeichern ...

 

[samhell]

Moin Moin,

doch ich denke ich kann dir folgen Frank.

Als Radio- und Fernsehtechniker rechne ich zwar nicht wirklich täglich mit
solchen Dingen (sondern hab es eher mal nur in der Lehre bis zum Vergasen
durchgenommen, wie zB das Quantisierungsrauschen das mich noch bis heute
in Albträumen verfolgt ), aber ich konnte es nachvollziehen.

Vielen Dank für die Einsicht

Bis zum nächsten Feierabend-Bier hab ich die Formelstellung wahrscheinlich
vergessen, aber das hilft mir doch beim Verständniss, und somit kann ich anderen
die nicht technisch versiert sind ebenso beim Verständniss des ganzen helfen.
Hab jetzt einige Neueinsteiger in DSLR-Fotografie im Bekanntenkreis, und da hab
ich erst letztens feststellen müssen das man starkes Rauschen bei Liveview-Nutzung
und durch ISO1600 doch schnell und einfach Verständlich machen kann.
(was mir bislang durch zu fachlicher Formulierung eher dazu geführt hat das den Leuten nach
dem ersten Satz die Augen zugefallen sind, als das sie sich was gemerkt hätten )


Mal wieder ein insgesamt sehr wertvoller Thread für mich.
Ist bislang auch sauber nachvollziehbar, und ich denke sollte auch für
nicht-technisch-versierte nachvollziehbar sein.


MfG,
Nico

 

[SharkeyCvA]

Wohl eher 4000 x 3000 x (12/8) = 18.000.000 oder 4000 x 3000 x (14/8) = 21.000.000 Bytes. Man braucht nicht jedes Pixel 3x abzuspeichern ...

Dazu habe ich eine Frage..
Angenommen, eine Kamera hat 15 MP (gutes Beispiel, meine 50D hat dies ).
Soweit ich weiß, quantisiert das gute Stück ja mit 14 Bit.. sind das jetzt 14 Bit Information pro Pixel oder 14 Bit Information pro Farbkanal? Hat nicht jeder Pixel die 3 Farbkanäle?

Also mit der maximalen Auflösung gerechnet :
15,1 * 10^6 Pixel * 14/8 Bit = 26,4 MB.

Die RAW-Daten haben aber tatsächlich bei mir immer so um die 20 MB, also irgendwas muss da komprimiert sein..

 

[Leeto]

D
Soweit ich weiß, quantisiert das gute Stück ja mit 14 Bit.. sind das jetzt 14 Bit Information pro Pixel oder 14 Bit Information pro Farbkanal? Hat nicht jeder Pixel die 3 Farbkanäle?

Jedes Pixel steht nur für einen Helligkeitswert. Mit Farbkanälen im - beispielsweise - RGB-Sinn hat das noch nichts zu tun. Schau mal nach Bayer-Sensor.

Grüße
Peter

 

[DSLR-Canonier]

Soweit ich weiß, quantisiert das gute Stück ja mit 14 Bit.. sind das jetzt 14 Bit Information pro Pixel oder 14 Bit Information pro Farbkanal? Hat nicht jeder Pixel die 3 Farbkanäle?

AFAIK kann mit einer 14 Bit Cam ein Pixel einfach einen Farbwert zwischen 1 und 16384 annehmen. Bei 12 Bit kann er nur zwischen 1 und 4096 wählen.

Dadurch werden Verläufe weniger abgehackt, oder du kannst die Helligkeit erhöhen, ohne dass die Farbe "abreißt".

Das merke ich gerade wenn ich Bilder mit der 10D (12 Bit) und der 40D (14 Bit) mache. Bei der 40D kannst du die Füllichter um über 75% erhöhen, ohne dass die Qualität groß leidet. Bei der 10D sieht das Bild bei gleicher Einstellung verheerend aus.

 

[Manni1]

...sind das jetzt 14 Bit Information pro Pixel oder 14 Bit Information pro Farbkanal? Hat nicht jeder Pixel die 3 Farbkanäle?

Nein! Die Pixel habe je einen Pegel, sonst nix. Dazu dann die der Kamera bekannte Information, welcher Filter davor sitzt... das genügt fürs Demosaicing.

 

[Frank Klemm]

AFAIK kann mit einer 14 Bit Cam ein Pixel einfach einen Farbwert zwischen 1 und 16384 annehmen. Bei 12 Bit kann er nur zwischen 1 und 4096 wählen.

Zum einen nimmt ein Pixel nur Helligkeitswerte an (Farben entstehen erst durch Tuscheln mit Nachbarpixeln und Nachbarzapfen), zum anderen sind es Werte zwischen 0 und 4095 bzw. 0 und 16383.

Dadurch werden Verläufe weniger abgehackt, oder du kannst die Helligkeit erhöhen, ohne dass die Farbe "abreißt".

Es gibt keine abgehackten Werte. Zumindest, wenn man keine Kapitalfehler bei der Signalverarbeitung durchführt. Dauermärchen in fast allen Laienforen wie DSLR-Forum, Dforum, ...

Das Signal einer DSLR rauscht genügend, so daß es selbst bei ungeschickter Verarbeitung egal ist, ob man mit 9 bit, 10 bit oder 11 bit arbeitet. 8 bit ist etwas wenig, zumindest bei ISO 100 und 200.

Das merke ich gerade wenn ich Bilder mit der 10D (12 Bit) und der 40D (14 Bit) mache. Bei der 40D kannst du die Füllichter um über 75% erhöhen, ohne dass die Qualität groß leidet. Bei der 10D sieht das Bild bei gleicher Einstellung verheerend aus.

Füll-Lichter haben wenig mit der Digitalisierungstiefe als vielmehr mit der Uniformität des Rauschens zu tun. Bekommt man die besser in den Griff (was bei Nikon z.Z. gut er Fall ist), kommt man weiter bei hohen ISOs und beim Pushen von Schatten.

Zur Canon EOS 40D bei ISO 100 (14 bit):

Das Ausleserauschen beträgt 5,66 ADUs.
Die Konversationsrate 3,36 Photonen/ADU.
Schwarz wird als 1024 kodiert.
Maximalwert ist 16383.

Ohne erkennbare Verluste ist das ganze mit 9 bit kodierbar. 10 bit wäre noch akzeptabel. Ab 11 bit fängt der Overkill an.

Code #-100 = 458.000 (wird an sich nicht benötigt)
...
Code #-1 = 1018.340
Code #0 = 1024.000 (Schwarz)
Code #1 = 1029.660
Code #2 = 1035.467
...
Code #100 = 2320.888
...
Code #200 = 5099.841
...
Code #300 = 9363.652
...
Code #419 = 16373.776

Für andere ISO-Werte reichen für die Kodierung zwischen Schwarz und AD-Wandlerüberlauf mit einen Kodierungsverlust von 8,33% zusätzlichem Rauschen aus:

ISO 100: 421 Codes (nichtlinear)
ISO 200: 303 Codes (nichtlinear)
ISO 400: 216 Codes (nichtlinear)
ISO 800: 153 Codes (nichtlinear)
ISO 1600: 107 Codes (nichtlinear)
ISO 3200: 74 Codes (nichtlinear)

Es spricht zwar nichts gegen 14-bit-AD-Wandler und eine interne 14 bit-Verarbeitung, aber 14 bit in RAW-Files ist reine Platzverschwendung. Unhöflicher ausgedrückt: Dummenverarschung.

Für die 5DII:
ISO 100: 449 Codes (nichtlinear)
ISO 200: 328 Codes (nichtlinear)
ISO 400: 237 Codes (nichtlinear)
ISO 800: 170 Codes (nichtlinear)
ISO 1600: 122 Codes (nichtlinear)
ISO 3200: 85 Codes (nichtlinear)

Jedes einzelne Pixel der 5DII ist nicht so viel besser als das der 40D. Die Qualitätsverbesserung ergibt sich aus dem Mehr(!) an Pixeln (22 MP statt 10 MP).
Die Qualität von Pixeln ergibt sich aus deren Größe, die von Bildern aus der Größe der benutzten Chipfläche. Jeweils bei gleichem technologischem Stand (und gleichem ISO-Wert).

Die Dateigröße von RAW könnte man durch

• nichtlineare Kodierung
• mit guter Predictor
• und anschließender Huffman-Kodierung,
• zusätzlich einem/zwei kleinem Vorschaubild(ern) im JPEG (z.B. 1280 x 848 @256KB + 320 x 212 @16KB)
• und der Realisierung von Playback-Zooms > 2 durch Lesen der Rohdaten von der CF-Karte + erneutem Processing

in eine Größe von kleiner 200% der Größe von JPEG Large Fine drängen.
40D Rohbilder mit durchschnittlich knapp 7 MByte (bei ISO 200) bzw. 5 MByte (bei ISO 1600) sind technisch kein Problem, wenn man will.

Aber eher wird man wahrscheinlich 24 bit RAW-Files mit xxx MPixeln finden, weil es die Kunden nicht anders wollen: Fetter = Besser.

 

[Frank Klemm]

Wie errechnen sich die 106%?
Ich hätte gedacht sqrt(1^2 + 0,5^2) = 111,8%

Edit: Ah, 0.5 ist ja der maximale Fehler durch die Quantisierung. Sigma ist ja ein Stück kleiner.

Sorry, es sind 108,3333333333333333333%.

Sie kommen aus dem Runden auf Ganzzahlen, was ein zusätzliches Rauschen von 1/12 des Quantisierungsabstands^2 verursacht.

Das ganze kommt aus dem Integral von -0,5 bis +0,5 von x², was 1/12 ist.
-0,5 bis +0,5 ist der Fehler durch das Runden, x² ist das Fehlerquadrat bzw. die Rauschleistung.

 

[zzzip]

Code #-1 = 1018.340
Code #0 = 1024.000 (Schwarz)
Code #1 = 1029.660
Code #2 = 1035.467

Welche Kodierung soll das sein?

 

[Frank Klemm]

Welche Kodierung soll das sein?

Nichtlinear.

Das Rauschen eines Sensors kann genähert werden durch:

Rauschen_in_Photonen = sqrt ( RON^2 + Photonenanzahl )

mit (Beispiel für Canon EOS 40D bei ISO 100 mit 14 bit):

Konversationsfaktor (K) = absorbierte Photonen pro ADC-Schritt (3,36 e-/digit)
BIAS (BIAS) = ADC-Wert für Schwarz (1024)
Ausleserauschen (RON) = Standardabweichung fuer Schwarz in Photonen (18,68 e-)
Photonenanzahl (Photonenanzahl) = Anzahl der absorbierten Photonen (z.B. 0 / 100 / 1000 / 10000 / 50000 e-)

Das ergibt in Falle des Beispiels:

Rauschen_in_Photonen(0 Photonen) = sqrt ( 18,68^2 + 0 ) = 18,68 e-
Rauschen_in_Photonen(100 Photonen) = sqrt ( 18,68^2 + 100 ) = 21,19 e-
Rauschen_in_Photonen(1000 Photonen) = sqrt ( 18,68^2 + 1000 ) = 36,73 e-
Rauschen_in_Photonen(10000 Photonen) = sqrt ( 18,68^2 + 10000 ) = 101,73 e-
Rauschen_in_Photonen(50000 Photonen) = sqrt ( 18,68^2 + 50000 ) = 224,39 e-

Uns interessieren aber nicht die Photonen oder befreiten Elektronen, sondern die Digitalwerte des 14 bit-Wandlers:

ADC-Wert mit BIAS: X = 14 bit-Wert           
ADC-Wert ohne BIAS: x = X - BIAS
Photonenanzahl: c = x * Konversationsfaktor    
Rauschen_in_Photonen = sqrt ( Ausleserauschen^2 + c )
Rauschen_in_Digits = Rauschen_in_Photonen / Konversationsfaktor

Ineinander eingesetzt ergibt das:

Rauschen_in_Digits = 
    sqrt ( RON^2 + (X - BIAS) * K ) / K

X - BIAS kann durch Rauschen selbst negativ werden, daher schreibt man das am besten als:

Rauschen_in_Digits = 
    wenn X > BIAS, dann
        sqrt ( RON^2 + (X - BIAS) * K ) / K
    ansonsten
        RON / K

Das ergibt

Rauschen_in_Digits(Wert 0) = 18,68 / 3,36 = 5,56 digit
Rauschen_in_Digits(Wert 1024) = 18,68 / 3,36 = 5,56 digit
Rauschen_in_Digits(Wert 1040) = sqrt ( 18,68^2 + (1040-1024) * 3.36 ) / 3.36 = 5,97 digits
Rauschen_in_Digits(Wert 1200) = sqrt ( 18,68^2 + (1200-1024) * 3.36 ) / 3.36 = 9,13 digits
Rauschen_in_Digits(Wert 2000) = sqrt ( 18,68^2 + (2000-1024) * 3.36 ) / 3.36 = 17,93 digits
Rauschen_in_Digits(Wert 8000) = sqrt ( 18,68^2 + (8000-1024) * 3.36 ) / 3.36 = 45,90 digits
Rauschen_in_Digits(Wert 16383) = sqrt ( 18,68^2 + (16383-1024) * 3.36 ) / 3.36 = 67,84 digits

Für das Tolerieren von 8,333% zusätzlichem Fehler sind das gleichzeitig die maximal zulässigen Abstände der Codeworte.
Für andere zusätzliche Fehler sind die Abstände folgendermaßen zu berechnen:

Abstand = Rauschen * sqrt ( Zulässiger_Fehler_in_Prozent * 12 / 100 )

Das ergibt:

Rauschen+1%: Abstand = Rauschen * 0,35
Rauschen+2%: Abstand = Rauschen * 0,49
Rauschen+3%: Abstand = Rauschen * 0,60
Rauschen+4%: Abstand = Rauschen * 0,69
Rauschen+6%: Abstand = Rauschen * 0,85
Rauschen+8%: Abstand = Rauschen * 0,98
Rauschen+10%: Abstand = Rauschen * 1,10
Rauschen+12%: Abstand = Rauschen * 1,20
Rauschen+15%: Abstand = Rauschen * 1,34
Rauschen+20%: Abstand = Rauschen * 1,55

Wer sich über die nichtganzen Werte wundert:

Aus dem AD-Wandler kommen zwar 14-bit-Werte raus, aber je nach Modus haben hier schon 2 bis 4 (sinnvolle) Verarbeitungsschritte stattgefunden, die zu jeder Menge Nachkommastellen führen. Wie genau man die Rechnung durchführt, ist eine andere Sache, aber man sollte sich von dem Gedanken verabschieden, das Ganzzahlen verlustfrei sind. Auch hier ist schon gerundet worden mit maximalen Fehlern von 0,50 digit und durchschnittlichen Fehlern von 0,28 digit.

 

[Frank Klemm]

oder einstellbar:
- unkomrimiert

Unsinnig. Frißt zusätzlichen Strom (längere Speicherdauer gegenüber einfachen Verarbeitungsschritten) und Speicher auf dem Flash.

- verlustfrei

Da schon vorverarbeitet, müßte man, wenn man gar nicht rundet, 30 bis 32 bit pro Pixel abspeichern, wobei der Informationsgehalt maximal 10 bit pro Pixel beträgt

- mit Verlust

Mit Verlust, aber bitte wählbar.
Weiterhin wählbar die Auflösung des eingebetteten JPEGs.

Zusätzliches Rauschen
(_) 1 Prozent (+2,3 MB)
(_) 2 Prozent (+1,4 MB)
(_) 3 Prozent (+0,9 MB)
(_) 4 Prozent (+0,5 MB)
(x) 6 Prozent
(_) 8 Prozent (-0,4 MB)
(_) 10 Prozent (-0,7 MB)
(_) 12 Prozent (-0,9 MB)
(_) 15 Prozent (-1,2 MB)
(_) 20 Prozent (-1,6 MB)

Embedded High Resolution JPEG
(_) Full Resolution 4752 x 3168 (+4 MB)
......(_) for immediate Zoom up to 30 = 400%
(_) Three Quarter Resolution: 3564 x 2376 (+2,2 MB)
......(_) for immediate Zoom up to 30 = 400%
......(_) for immediate Zoom up to 11 = 150%
......(_) for immediate Zoom up to 5,5 = 75%
(_) Half Resolution 2376 x 1584 (+1 MB)
......(_) for immediate Zoom up to 7,4 = 100%
......(_) for immediate Zoom up to 3,7 = 50%
(x) none

Embedded Preview
(_) Very High Resolution 1920 x 1280 ( for immediate Zoom up to 3 ) (+0,2 MB)
(x) High Resolution 1280 x 848 ( for immediate Zoom up to 2 )
(_) Low Resolution 640 x 424 ( for immediate Zoom up to 1 ) (-0,1 MB)

Thumbnail
(x) Half Resolution 320 x 212

Funktionen

Thumbnail: Wird benutzt für
- Indexanzeige mit 2x2, 3x3, 4x4 Bildern
- Schnelle erste Vorschau beim Durchblättern durch den Bildbestand

Embedded Preview
- Anzeige von Bildern mit Zoom 0,75 bis 1/2/3 (je nach Auflösung)

Embedded High Resolution JPEG
- Anzeige von Bildern mit Zoom 2 bis 30 (je nach Auflösung)

RAW
- Anzeige von Auflösungen, die nicht durch andere Modi abgedeckt sind (Zoom 2 bis 30)
- Processing dafür notwendig

 

[Charles]

Bei meiner Kamera (Sony A700) gibt es neben Raw auch noch compressed Raw. Bei cRaw handelt es sich meines Wissens um verlustbehaftete Kompression. Ob Sony die normalen Raws auch (verlustfrei) komprimiert kann ich nicht sagen. Nach meiner Abschätzung sollte ein Raw einer 12 MP Kamera bei 12 bit 18 MB groß sein. Das kommt auch hin. Viele Hersteller binden auch noch ein Jpeg als Vorschaubild ein. Durch dessen größe wird natürlich auch die Raw Größe beinflußt. Ebenso wie die ISO ist die Größe auch Motivabhängig.

 

[Manni1]

Die RAW-Daten haben aber tatsächlich bei mir immer so um die 20 MB, also irgendwas muss da komprimiert sein..

Halt nochmal (steht doch schon ganz oben in einem der ersten Beiträge): RAW wird i.a. verlustfrei komprimiert. Jedenfalls bei Nikon, soweit ich weiß auch bei Canon. Das bringt zwar weniger als die verlustbehaftete JPG-Komprimierung, aber immerhin etwas schon.
Daraus folgert, daß bei großen ISO-Werten weniger Komprimierung möglich ist, weil dabei eben die Unterschiede eines scheinbar homogenen Bildbereichs deutlich werden.

 

[zzzip]

Das Rauschen eines Sensors kann genähert werden durch:

Verstehe ich das richtig, daß Du vorschlägst nicht die Meßwerte der Sensorelemente abzuspeichern, sondern die Rauschleistung, die sich aus ihnen berechnen läßt? Und weil die Rauschleistung netterweise mit der Wurzel der Meßwerte geht, muß man nur noch einen kleineren Wertebereich abdecken, wodurch weniger Bits (Beispiel 9-10) erforderlich sind. Ist das die grobe Richtung?

 

[Frank Klemm]

Verstehe ich das richtig, daß Du vorschlägst nicht die Meßwerte der Sensorelemente abzuspeichern, sondern die Rauschleistung, die sich aus ihnen berechnen läßt? Und weil die Rauschleistung netterweise mit der Wurzel der Meßwerte geht, muß man nur noch einen kleineren Wertebereich abdecken, wodurch weniger Bits (Beispiel 9-10) erforderlich sind. Ist das die grobe Richtung?

Nein.

Es werden schon Meßwerte abgespeichert, aber diese werden nicht linear abgespeichert.

UINT14  CODE2ADU [  1024 ] ;
UINT10  ADU2CODE [ 16384 ] ;

Beim Abspeichern wird aus den 14-bit-ADC-Worten ein 10-bit-Code bestimmt,
beim Bildberechnen aus den 10-bit-Codes die originalen 14-bit-ADC-Worte.

void
Initialisiere_Quantisierungstabelle ( 
    unsigned int  BIAS =  1024 ,  // ADC-Wert für Schwarz 
    float         RON  = 18.68 ,  // Ausleserauschen in Elektronen
    float         K    =  3.36 ,  // Elektronen pro Digit
    float         Loss =  0.03 )  // Kodierungsverlust (0,03 = 3%)
{
    float         NoiseMultiplikator = sqrt ( 12 * Loss ) ;
    float         CodeWort = 0 ;
    float         Noise ;
    unsigned int  i ;

    for ( i = 0 ; i < 16384 ; i++ )
    {
        if ( i <= BIAS )
            Noise = RON/K ;
        else
            Noise = sqrt ( RON*RON/K/K + (i-BIAS)/K ) ;

        Noise      *= NoiseMultiplikator ;
        CodeWort   += 1/Noise ;
        ADU2CODE[i] = iround ( CodeWort ) ;
    }
}

 

[Manni1]

14-bit-ADC-Worten ein 10-bit-Code bestimmt, beim Bildberechnen aus den 10-bit-Codes die originalen 14-bit-ADC-Worte.

Wie kann man denn aus 10-bit-Codes die originalen 14-bit-ADC-Worte ermitteln? Für mich ein mathematisches Rätsel...

 

[stephan2807]

Sorry, es sind 108,3333333333333333333%.

Sie kommen aus dem Runden auf Ganzzahlen, was ein zusätzliches Rauschen von 1/12 des Quantisierungsabstands^2 verursacht.

Das ganze kommt aus dem Integral von -0,5 bis +0,5 von x², was 1/12 ist.
-0,5 bis +0,5 ist der Fehler durch das Runden, x² ist das Fehlerquadrat bzw. die Rauschleistung.

Mit 8,33% meinst Du die zusätzliche Rauschleistung, oder? Ansonsten hab ich die Rechnung noch nicht kapiert...

Beispiel:
- Rauschen Ausgangssignal: 10e
- Rauschleistung Ausgangssignal 100e^2
- Quantisierung auf 10e
- Quantisierungsrauschen: 8,33 e^2

> Gesamtrauschleistung: 108,33e^2
> Gesamtrauschen: 10,41e
> Erhöhung durch Quantisierung: 4,1%

 

[zzzip]

Gut, die Sensorwerte werden also in Quantisierungsstufen ausgedrückt, die das Rauschen berücksichtigen. Leider ist mir noch nicht klar, warum das gut ist, aber mathematisch ist es doch wie ich schrieb:

sqrt(RON^2/k^2 + (i-BIAS)/k) = sqrt(RON^2/k + i - BIAS) / sqrt(k) = sqrt( R_C + i ) / sqrt( k ), mit R_C = RON^2/k - BIAS, also R_C eine gerätespezifische Konstante, die Rauschen, Wandlereffizienz und Offset zusammenfasst.

Was sich mir noch nicht erschließt, und das kann durchaus an meinen mangelhaften Kenntnissen über Rauschen liegen, wie man 14 Bit in 10 Bit und zurück wandelt, ohne 4 Bit Information zu verlieren. Beschreiben die Größen, die ich zu R_C zusammengefasst habe, irgendwie den Effekt, daß in den Meßwerten nur 10 Bit Information sind? Mal angenommen daß dem so ist, warum sollte dieses Verfahren im Sinne der Redundanzvermeidung besser sein als irgendein anderer Kompressor, z.B. einfaches RLE oder bzip oder 10 Bit JPEG?

Selbst wenn 4 Bits an Information verloren gehen sollten, bleibt natürlich immer noch die Frage der praktischen Relevanz. Aber hier liegt der Knackpunkt: Der Vorzug von RAW liegt ja gerade darin keine Information zu verlieren, auch keine praktisch irrelevante, im Gegensatz zu z.B. JPEG, das Annahmen über den Betrachter macht.

 

[Frank Klemm]

Gut, die Sensorwerte werden also in Quantisierungsstufen ausgedrückt, die das Rauschen berücksichtigen. Leider ist mir noch nicht klar, warum das gut ist,

Die Dateien werden kleiner -- oder -- die Nebenwirkungen von RAW oder RAW+JPEG gegenüber JPEG only werden geringer. Man kann mehr und schneller fotografieren und verliert dabei einen genau definierten Betrag an SNR, den man frei auswählen kann.

aber mathematisch ist es doch wie ich schrieb.

sqrt(RON^2/k^2 + (i-BIAS)/k) = sqrt(RON^2/k + i - BIAS) / sqrt(k) = sqrt( R_C + i ) / sqrt( k ), mit R_C = RON^2/k - BIAS, also R_C eine gerätespezifische Konstante, die Rauschen, Wandlereffizienz und Offset zusammenfasst.

Was sich mir noch nicht erschließt, und das kann durchaus an meinen mangelhaften Kenntnissen über Rauschen liegen, wie man 14 Bit in 10 Bit und zurück wandelt, ohne 4 Bit Information zu verlieren.

Die 14 bit sind keine Information, sondern Information und Rauschen. Man sorgt dafür, daß die Information nicht zu Schaden kommt. Dafür ist es ausreichend, zwischen 1 bis 3,3 bit Rauschen mitzukodieren, aber nicht 4 bis 8 bit Rauschen.

Beim Kodieren mit einem Codewortabstand von 1 Sigma kodiert man schon etwa 1,8 bit Rauschen mit, bei 0,5 Sigma sind es 2,8 bit.

Beschreiben die Größen, die ich zu R_C zusammengefasst habe, irgendwie den Effekt, daß in den Meßwerten nur 10 Bit Information sind? Mal angenommen daß dem so ist, warum sollte dieses Verfahren im Sinne der Redundanzvermeidung besser sein als irgendein anderer Kompressor, z.B. einfaches RLE oder bzip

zip, LZW, RLE, bzip2 = Entfernen von Redundanz (was man immer ohne Veränderung von Daten machen kann)
Nichtlineare Quantisierung = Reduzieren von Irrelevanz.
Nichtlineare Quantisierung + Predictor + LZW = Reduzieren von Irrelevanz + Weitgehendes Entfernen von Redundanz.

oder 10 Bit JPEG?

JPEG = weitgehend verdaut. Man will ja gerade kein künstlerisch schon durchinterpretiertes Bild haben, sondern ein technisches Bild. Die JPEG-Komprimierung ist ja bei JPEGs noch nicht mal das allerschlimmste, sondern das, was davor stattfindet.

Selbst wenn 4 Bits an Information verloren gehen sollten, bleibt natürlich immer noch die Frage der praktischen Relevanz. Aber hier liegt der Knackpunkt: Der Vorzug von RAW liegt ja gerade darin keine Information zu verlieren,

Man muß nur das aufheben, was man wirklich braucht und ein klein wenig mehr.
Sigma-Delta-Wandler (Audio-ADCs) verwendet man ja auch nicht, um den originalen Bitstream zu speichern (~3...6 MByte/s/Ch), sondern man nimmt im besten Fall die 96 kHz/24 bit nach der Dezimierung (~0,3 MByte/s/Ch) und selbst das ist für das meiste viel zu viel. 48 kHz/20 bit (~0,12 MByte/s/Ch) tun es eigentlich immer auch. MPEG Layer 3 mit max. 0,02 MByte/s/Ch liegt da nochmal deutlich drunter.

auch keine praktisch irrelevante, im Gegensatz zu z.B. JPEG, das Annahmen über den Betrachter macht.

RAW "unkomprimiert" => 99,9% der Nutzinformation + sehr sehr viel Irrelevanz
RAW "komprimiert" => 99% der Nutzinformation + noch genügend Irrelevanz
TIFF oder PNG => weitgehend vorverdaut, Datenmenge dabei trotzdem auf das 1,5...2x aufgeblasen
JPEG => weitgehend vorverdaut + vorsichtiges Entfernen von nicht sichtbares Details

Oder man unterscheidet zwischen

• Redundanz
• technischer Irrelevanz
• physiologischer Irrelevanz

 

[Frank Klemm]

Mit 8,33% meinst Du die zusätzliche Rauschleistung, oder? Ansonsten hab ich die Rechnung noch nicht kapiert...

Beispiel:
- Rauschen Ausgangssignal: 10e
- Rauschleistung Ausgangssignal 100e^2
- Quantisierung auf 10e
- Quantisierungsrauschen: 8,33 e^2

Du hast folgende Fehler nach dem Quantisieren auf 10 e-:
-4,5e, -3,5e, -2,5e, -1,5e, -0,5e, +0,5e, +1,5e, +2,5e, +3,5e, +4,5e
Jeder Fehler taucht mit 10% Wahrscheinlichkeit auf:

Durchschnittlicher Fehler^2 = 0.1 * ( 2 * (4,5² + 3,5² + 2,5² + 1,5² + 0,5²) ) = 8,25 e^2

Die Abweichung zwischen 8,333333333333333% und 8,25% kommt durch die Betrachtung einer diskreten Verteilung (statt einer stetigen Verteilung).

> Gesamtrauschleistung: 108,33e^2
> Gesamtrauschen: 10,41e
> Erhöhung durch Quantisierung: 4,1%

Ja.
Richtig.
Aus ISO 100 wird trotzdem etwa ISO 108,33, was für die meisten hier besser verständlich ist.