[www_zeeshan_de]

Zitat von usch

Ich weiß nicht, was Lightroom da macht, aber das sieht nicht nach Kompressionsartefakten aus dem cRAW aus, sondern eher nach Demosaik-Fehlern, die durch die Nachbearbeitung verstärkt werden. Ich möchte fast wetten, daß bei einem verlustlosen RAW dasselbe herauskommen würde.

Zur Erinnerung: cRAW-Artefakte äußern sich in einem maximal 16 Pixel breiten, senkrechten Streifen mit verstärktem Rauschen auf der dunklen Seite von harten Kontrastkanten. Alles andere muß andere Ursachen haben.

Hallo usch!

+ Allgemein: Deine Beiträge waren nie Fanboy-Art, waren nie offensiv oder persönlich beleidigend (mir gegenüber).
+ Deine sachliche und fachliche Beiträge gefallen mir sehr und ich lese diese immer still und heimlich mit.

Und nun zum Thema:
Wenn ich genau das geschrieben hätte was du gepostet hast, wären bei mir alle Türen von Interpolations-Fanboys eingerannt worden. Schön dass die Worte von dir kommen, und ich darüber kommentieren kann...

Grundsätzlich sollte JEDEM Laitruhm (Anmerkung: Produktname geändert) User klar sein: Niemand von der Anwenderseite weiß, wie und was Laitruhm macht. Als Fotograf überlässt man das Steuer der Automatik (bequemlichkeitshalber).
Ich habe kein Laitruhm. Ich weiß nur dass es Proprietäre SW ist und es angeblich nicht möglich ist, mit Laitruhm Bilder OHNE INTERPOLATION (zero mod) zu generieren.

Komressionsartefakte können erst dann entstehen, wenn man Daten (verlustbehaftet) komprimiert. An dieser Stelle aber waren Daten schlicht NICHT VORHANDEN (!!!).
Diese nun als Demosaik Fehler zu bezeichnen, wäre aber unrichtig. Den die Demaosaik-Algorightmen habe die Aufgaben, Daten künstlich per Hokus-Pokus-Sim-Sala-Bim zu erzeugen (also das Gegenteil von Fotografie, die Tatsache, die Wahrheit, das Reale, die Realität), selbst dann, wenn gar keine Daten vorliegen.
Und genau das ist im Grunde genommen auch passiert.

Der junge Mann von dpreview hat es ernst gemeint, nachts ein Bild mit EV -7 (oder mehr -) zu knipsen und boostet die Helligkeitswerte anschließend inklusive Interpolationsverfahren auf EV +7 per proprietärem Laitruhm.

Ich habe mir Spaßeshalber von
http://www.dpreview.com/articles/745...ent=7922735968
die
DSC09021.arw
runtergeladen, und diese per dcraw zero mod ohne interpolation mit original helligkeit und orginalfarben
" -v -h -w -T -W"
erzeugt. Was ich dann auf dem schwarzem original Bild (100 % Datenmenge) gesehen habe war fast nichts. Es wurde also fast nichts fotografiert.
Mit dem Boosten der Helligkeit um EV +7 konnte ich dann an der Artefaktbetroffenen Ladenbeleuchtung "underU4men" erkennen, dass im original Bild ohne Interpolation GAR KEINE Artefakte und gleichzeitig aber auch GAR KEINE Informationen vorliegen, aus denen ein Interpolationsverfahren hätte die Artefakte generieren können.

Für mich ist es, so wie für dich wohl auch, offensichtlich, dass die Artefakte vom Interpolationsverfahren aufgrund "fehlender Daten für das Interpolieren" erzeugt wurden.

Natürlich kann man als Ursache auf die verlustbehaftete Aplha RAW (ARW) mit dem Finger zeigen, erzeugt wurde die Artefakte aber vom Interpolations/Demosaiking-Verfahren.

Da ich meine Bilder ausschließlich OHNE Interpolation generiere, hatte ich noch NIE irgendwelche Artefakte dieser oder ähnlicher Art in meinen Bildern.

Nun wird es spannend bleiben, wenn lossless Alpha RAW eines Tages verfügbar sein sollte in den Alphas (egal auf welchem Weg), ob und in welcher Menge man als Fotograf profitiert, wenn die Dateigröße pro Bild auf 80,447 megabytes (lossless, unkomprimiert) ansteigen wird.

[dinadan]

Zitat von mick232

Durch die verlustbehaftete Kompression werden die vollen 14-Bit nicht erreicht.

Wie kommst du denn darauf? 14bit gegenüber 12bit RAW heisst nur, dass 16384 statt 4096 Helligkeitsabstufungen pro Sensorpixel gespeichert werden. Mit der Kompression hat das erstmal nichts zu tun.

[dey]

Capture one 8.3.3 produziert die gleiche posterization, die im dpreview-Artikel bemängelt wird. Auch beim Startrailsbild aus dem weiter verlinkten Artikel.

[benmao]

Zitat von mick232

Sony verspricht 14-Bit-RAW, siehe zB http://www.sony.de/electronics/wechs...specifications

Durch die verlustbehaftete Kompression werden die vollen 14-Bit nicht erreicht. ...

Zitat von dinadan

Wie kommst du denn darauf? 14bit gegenüber 12bit RAW heisst nur, dass 16384 statt 4096 Helligkeitsabstufungen pro Sensorpixel gespeichert werden. Mit der Kompression hat das erstmal nichts zu tun.

Waren es nicht 11bit? Aber egal, wenn 14 bit pro Pixel mit 11 bit gespeichert werden, ist das doch Kompression. Zwei von 16 Pixeln werden ja so gespeichert. Dass die anderen mit 7bit als Offset gespeichert werden, kommt noch dazu.

Und wenn man davon ausgeht, dass bei den 14bit Zahlen alle Zahlen vorkommen können und nicht nur bestimmte wie z.B. 1,2,4,8,16,32,64,128,256,512,1024,2048,4096,8096 - dann ist es auch verlustbehaftet.

[mick232]

Zitat von dinadan

Wie kommst du denn darauf? 14bit gegenüber 12bit RAW heisst nur, dass 16384 statt 4096 Helligkeitsabstufungen pro Sensorpixel gespeichert werden. Mit der Kompression hat das erstmal nichts zu tun.

Es werden eben nicht 16384 Helligkeitsabstufungen pro Pixel gespeichert.

[mick232]

Zitat von usch

Im Gegenzug könnte Sony dann natürlich auch hingehen und das Menü nachbessern statt des Dateiformats.

Ich bezweilfe, daß Sony das Dateiformat in einem Firmware-Upgrade ändert. Soetwas führt man höchstens in einer neuen Kamera ein. Und genau das lässt auch vermuten, daß es in der Tat "uncompressed" statt verlustlos komprimiert sein wird, denn das gibt es im ARW-Format schon.

[usch]

Das alte unkomprimierte RAW speichert exakt 12 Bit pro Pixel, nicht mehr und nicht weniger. Für 14 Bit muß also auf jeden Fall ein neues Dateiformat definiert werden.

Ich rechne aber aus zwei Gründen damit, daß es wirklich unkomprimiert sein wird:

Erstens würde bei einem neuen komprimierten Format gleich wieder spekuliert, ob es nicht vielleicht doch immer noch Verluste verursacht. Das würde ich mir als Kamerahersteller nicht antun wollen.

Zweitens muß zum Hineinzoomen im Wiedergabemodus die Position jedes Pixels innerhalb der Datei einfach berechnet werden können. Das geht aber bei einem komprimierten Format mit variabler Wortlänge nur, indem man erst das gesamte Bild entpackt, mit entsprechender Wartezeit beim Laden. Oder man müßte eine blockweise Kompression mit einer Indextabelle verwenden; die wäre dann aber nicht sehr effektiv und könnte im Extremfall sogar dazu führen, daß die Datei größer wird statt kleiner.

[www_zeeshan_de]

Die Dateigröße pro Bild mit 80,447 megabytes (lossless, unkomprimiert) galt für die A7RII, und zur Berechnung habe ich 16 Bits pro Pixel verwendet.
Warum?
Ganz einfach:
Adressieren kann man nur Byte-Weise. Ein Byte ist die kleinste adressierbare Menge im RAM, wobei 1 Byte = 8 Bits.
Wenn man also Bits im Bereich 9 bis 15 speichern möchte, muss man trotzdem Double-Bytes verwenden. Die Adressierung erfolgt also immer Byte-Weise im RAM mit den größen Single-Byte (8 Bit), Double-Byte (16 Bit), Triple-Byte (24 Bit), Quad-Byte (32 Bit) usw...

Man darf mich gerne korrigieren, sollte ich falsch liegen.

Aufgefallen ist mir die bei der Tatsache, dass mit Android 5 das DNG RAW Format vom Nexus 6 mit 13 MP Kamera in etwa gleich große RAW Dateien produziert als meine 24 MP Kamera A99.
Ich habe es dann für Nexus 6 ausgerechnet:
4200*3112=13070400
13070400*2=26140800
26140800/1024/1024=24,929810 megabytes
Eine Beispiel DNG hat
25,0 MB (26.288.148 Bytes)
Für Android ist lossless unkomprimiert die schnellste Option die 16 Bit RAW-Datenmenge aus dem RAM auf interneb/externen Speicher zu flushen. Eine Komprimierung würd das ganze Handy für ein paar Sekungen freezen und massive Hitze erzeugen (inklusive Akkuverbrauch).

Ich gehe davon aus, dass auch in den Sony Digitalkameras GENERELL 16 Bits (also Double-Bytes) im RAM adressiert werden, nur mit dem Unterschied, dass die RAW Daten vor dem flushen eventuell per speziellem HW-Chip komprimiert werden. Bit 15 und 16 werden wohl vermutlich genullt. Über Bit 13 und 14 kann ich keine Aussage machen.

Ich finde es erstaunlich was für Bilder mit welcher Bildqualität aus meinen 24 megabytes A99 möglich sind mit dem Gegenvergleich Nexus 6 mit 25 megabytes Dateigröße pro Bild, die bei ISO 100 gefühlt so viel Bildrauschen enthalten wie die A99 bei ca ISO 3200 bis 6400.

Man bedenke nun mal die Platzverschwendung der Nexus 6 RAW Dateien.

RAW Dateien sollten GENERELL verlustfrei komprimiert werden, es sei denn jemand beweist mir dass mit der AD Wandlung in 16 Bits RAW Daten noch schönere Bilder möglich sind als das womit ich momentan voll zufrieden bin.

[Ellersiek]

Zitat von www_zeeshan_de

....Adressieren kann man nur Byte-Weise....

Da möchte ich direkt widersprechen. Es handelt sich hier (in diesem Fall Bionx) um spezielle Prozessoren und Anwendungsgebiete - die werden auf alles Mögliche hin optimiert und dabei werden ganz sicher nicht 2 Bit verschenkt - zu wichtig sind Platz, Verarbeitungsgeschwindigkeit und Stromverbrauch.

Und was das Zoomen angeht: Auf der Kamera wird doch nicht das RAW sondern das darin enthaltene JPG angezeigt, oder?

Gruß
Ralf

[DonFredo]

Moin,

Zitat von Ellersiek

...Und was das Zoomen angeht: Auf der Kamera wird doch nicht das RAW sondern das darin enthaltene JPG angezeigt, oder?

Ja.