[TONI_B]

Zitat von aidualk

Wann nimmst du eigentlich deine 'Filmkamera' und wann eine 'normale' Kamera für deine Nachtaufnahmen?

Hast pn, damit wir hier nicht zu offtopic werden.

[usch]

Zitat von mick232

Ausserdem ist die Verdoppelung der Dateigröße nicht die bestmögliche Lösung, da man ja von (im Schnitt) 8-Bit auf 14-Bit gegangen ist, daher wäre ein Anstieg der Dateigröße im Verhältnis 14/8 wünschenswert.

Abwarten, bis das Update tatsächlich verfügbar ist. Vielleicht war das auch nur eine Vorserienversion.

Denkbar ist natürlich, daß sie jetzt gleich auf 16 Bit unkomprimiert gegangen sind. Entweder, um im Fall der Fälle nicht schon wieder ein neues Dateiformat einführen zu müssen. Oder weil prozessortechnisch überhaupt nur 16/8 zu handhaben ist, nicht aber ein krummes Verhältnis von 14/8. Man weiß ja nicht, wie viel bei der Verarbeitung in Hardware gegossen ist – wenn der BIONZ keine Operation wie "bitweises Verschieben mit Übertrag" kennt, weil man das bisher nicht gebraucht hat, dann kommt man an Strukturen unterhalb der Wortbreite gar nicht heran.

Zitat von dey

Warum ist die Dateigröße ein Problem?
An jeder Ecke hört man doch: " Bei den Speicherpreisen ...."

Wahrscheinlich jammern jetzt genau die Leute, die mich immer ausgelacht haben, weil mir die riesigen 24-Megapixel-Dateien schon zu viel sind und ich die α7S auch wegen der kleinen Raw-Dateien liebe.

Ist lossless compressed überhaupt möglich im Bildbereich? Oder bringt es dann noch wirklich etwas? Ist es nicht eher ein invisible compression?

Bei 16-Bit-RAWs mit 14-Bit-Nutzdaten läßt sich sicher noch was komprimieren . Ansonsten hängt der Nutzen wie immer vom Bildinhalt ab, und viel wird sich tatsächlich nicht mehr herausholen lassen. Ein wirklich effektiver Algorithmus wäre zu rechenintensiv und müßte das gesamte Bild analysieren, d.h. man könnte die Verarbeitungskette auch nicht mehr parallelisieren, sondern jede Stufe müßte erst warten, bis die davor komplett fertig ist. Wie ist denn das Verhältnis zwischen unkomprimiert und verlustlos komprimiert bei Nikon?

[*thomasD*]

Am PC könnten die unkomprimierten RAWs ja in verlustlos komprimierted RAWs (DNGs) umgewandelt werden.

Da müsste ich meine Workflow aber überarbeiten. Lightroom müsste das ja recht einfach können? Allerdings traue ich dem DNG-Format noch nicht so recht.

[Ellersiek]

Habe mal eben ein uncompressed RAW der 900er mit 7Zip komprimiert:
Aus 36533 kB wurden 16159 kB, allerdings mit unerträglicher, zusätzlicher Verarbeitungszeit.

Wenn man intern jede Bildzeile oder Blöcke von Bildzeilen (falls das RAW zeilenweise abgespeichert ist) einzeln zippt, könnten man das Zippen parallelisieren und dadurch beschleunigen. Bleibt allerdings die Frage, ob die Hardwarestrukturen so etwas ermöglichen.

Gruß
Ralf

[mick232]

Zitat von usch

wenn der BIONZ keine Operation wie "bitweises Verschieben mit Übertrag" kennt, weil man das bisher nicht gebraucht hat, dann kommt man an Strukturen unterhalb der Wortbreite gar nicht heran.

Nö. Viele Wege führen nach Rom. Herankommen tut man auf jeden Fall, die Frage ist nur wie schnell. Es reicht Multiplikation/Division mit Zweierpotenzen sowie bitweises UND/ODER. Notfalls auch Addition. Schiebeoperationen sind wesentlich schneller als generische Multiplikation/Division. Im übrigen würd es mich wundern, wenn Grundfunktionen wie Schieben nicht verfügbar wären. Da der BIONZ auf MIPS basiert, ist klar, daß bitweises Verschieben mit/ohne Übertrag verfügbar sind (srav, srlv, etc.).

[mick232]

Zitat von Ellersiek

Habe mal eben ein uncompressed RAW der 900er mit 7Zip komprimiert:
Aus 36533 kB wurden 16159 kB, allerdings mit unerträglicher, zusätzlicher Verarbeitungszeit.

Wenn man intern jede Bildzeile oder Blöcke von Bildzeilen (falls das RAW zeilenweise abgespeichert ist) einzeln zippt, könnten man das Zippen parallelisieren und dadurch beschleunigen. Bleibt allerdings die Frage, ob die Hardwarestrukturen so etwas ermöglichen.

Das Beispiel zeigt zwar, daß RAW-Daten gut komprimierbar sind, aber 7-Zip bzw. "Zippen" hat mit RAW-Kompression sonst nicht viel zu tun.

Auch auf Parallelisierung wird man eher nicht setzen. Aus vielfachen Gründen. Du hast sequentielle Anteile, die du nicht parallelisieren kannst und die daher den Speedup begrenzen. Du hast auch gar nicht die Hardware für parallele Ausführung. Du wüsstest nicht, an welche Stelle du die komprimierten Zeilen in den Zielpuffer schreiben kannst, weil die Länge der vorherigen Zeilen noch nicht bekannt ist, etc.

Grundsätzlich sollte man unterscheiden:
- generische verlustlose Verfahren für beliebige Daten (angefangen vom Urvater Huffman-Coding bis hin zu aktuellsten Vertretern, wie 7-Zip es macht)
- für den Bildbereich entworfene Verfahren wie JPEG, basierend auf diskreter Cosinustransformation, die das Bild in den Spektralbereich umwandeln, dadurch hochfrequente Bereiche die viel Platz beanspruchen aber wenig zum Bild beitragen einfach abgeschnitten werden können, und den Rest dann rücktransformieren
- RAW-Kompression wie bei Sony, die auf kleinen und fixen Datenblöcken arbeitet und auf einfachen arithmetischen Operationen basiert, vom Rechenaufwand mit JPEG und ZIP überhaupt nicht zu vergleichen

[benmao]

Zitat von dey

Und öffnen lassen unkomprimierte Dateien ja wohl schnller.

Nicht unbedingt. Es müssen ja mehr Bytes vom Speichermedium gelesen werden. Über Netzwerk mit WLAN wird es wahrscheinlich langsamer sein.

[www_zeeshan_de]

Was ich mit meinem Posting #78 angedeutet hatte, ist jetzt fast schon amtlich:
80,447 megabytes 16 BIT RAW DATEN + Metadaten + JPG Thumbnail = 81,5 megabytes.

Und im übrigen sollte klar sein: Spezialhardware ist jede Hardware, die den RAM Bitweise adressiert. Dabei spielt es keine Rolle, ob es sich um Embedded Systeme, PCs oder Server handelt.

Und an den Kollegen ddd:
Gerne darfst du den gesamt Thread mit all meinen Postings noch einmal durchlesen. In keinem meiner Postings habe ich je behauptet dass ich mich mit "Embedded Devices" auskenne.
Mir darüber fachliche Inkompetenz vorzuwerfen ist absolut daneben wie unangebracht. Wenn das so ist, kann man jedem User im Thread den Vorwurf machen, er hätte keine Ahnung wie das Gefühl ist, wenn man auf dem Mars landet.
Abgesehen davon ist es mir Wurst, was sich in der Kiste der A7RII befindet, ob Prozessor X, Platine Y oder RAM Z und welche Software darauf läuft: Die Frage war, ob der RAM mit 14 Bit oder 16 Bit adressiert wird.
Wie du inzwischen ja selbst gelesen hast: Das Flushen der unkomprimierten RAW Daten erzeugt 16 Bit (Double Bytes) an Daten.
Es kommt als Byte-Weise-Adressierung zur Anwendung, die alte klassische Regel und somit ist es KEINE Spezialhardware.

[SpeedBikerMTB]

Der Workflow wäre sehr einfach zu ändern, einfach beim Import in oben 'Als DNG kop.' anklicken und wird schon umwandelt, aber:

Zitat von *thomasD*

.......Allerdings traue ich dem DNG-Format noch nicht so recht.

Ist DNG wirklich Verlustlos? Verdächtig die DNG-Dateien sind genauso groß wie die cRaws der A99.

[nobody23]

Zitat von SpeedBikerMTB

Ist DNG wirklich Verlustlos? Verdächtig die DNG-Dateien sind genauso groß wie die cRaws der A99.

Waren die Quelldateien von welcher Kamera oder hast du bereits eine Sony die verlustlos arbeitet?