Dateigröße NEF vs. psd und tif

Thread Status
Hello, There was no answer in this thread for more than 30 days.
It can take a long time to get an up-to-date response or contact with relevant users.

Linsengucker

Sehr aktives NF Mitglied
Registriert
Hallo Zusammen,

ich fotografiere mit D300 und D700. Beide etwa 12 Mpx (die D300 hat ein paar tausend mehr). Bislang war ich in RAW "verlustfrei komprimiert" unterwegs, was NEFs mit gut 10 MB zur Folge hatte. Wenn ich die Bilder in ACR (9.1.1) entwickle und als psd oder tif zur Weiterbearbeitung in Photoshop rausschreibe "explodiert" die Dateigröße auf etwa 70 MB.

Habt ihr eine Erklärung dafür?

PS: Probeweise habe ich die beiden Kameras auch mal auf "NEF unkomprimiert" umgestellt. Die Dateien haben dann gut 18 MB. Wie kommt ACR auf 70 MB?
 
Anzeigen
Ich glaube mich erinnern zu können, dass "Farbtiefe" hier wohl das Zauberwort ist.
Probier mal eine Umwandlung in tiff mit 8 Bit, dann wird die Datei erheblich keiner ...
 
Kommentar
NEF sind Sensor-Rohdaten, PSD oder TIF sind Bilddateien. Oder auch "das Ganze ist mehr als die Summe seiner Teile".

Wenn ich aus 500g Mehl einen Pizzateig backe ist der so gross, dass er nicht mehr in die Mehltüte passt. Hasst Du eine Erklärung dafür?

PS: Probeweise habe ich dem Teig auch mal die doppelte Menge Hefe und etwas Zucker eingeknetet. Er wird dann noch viel grösser und dicker.
 
Kommentar
Ich glaube mich erinnern zu können, dass "Farbtiefe" hier wohl das Zauberwort ist.
Probier mal eine Umwandlung in tiff mit 8 Bit, dann wird die Datei erheblich keiner ...

ist klar, aber die NEFs haben ja auch keine 8 Bit Farbtiefe. Vielleicht geht das jetzt aber schon in die richtige Richtung. Ich habe gerade nochmal nachgesehen: In den Kameras habe ich 12 Bit für NEF eingestellt (16 Bit können die Kameras nicht). Bridge gibt diese mit 16 Bit an (aber mit 10 MB resp. 18 MB). Ich kann mir nicht erklären was da passiert.

NEF sind Sensor-Rohdaten, PSD oder TIF sind Bilddateien. Oder auch "das Ganze ist mehr als die Summe seiner Teile".

Wenn ich aus 500g Mehl einen Pizzateig backe ist der so gross, dass er nicht mehr in die Mehltüte passt. Hasst Du eine Erklärung dafür?

PS: Probeweise habe ich dem Teig auch mal die doppelte Menge Hefe und etwas Zucker eingeknetet. Er wird dann noch viel grösser und dicker.

Hallo Stefan,
das mit der Pizza kann ich Dir gerne erklären. Aber das machen wir dann besser über PN, weil OT. Hast Du auch was zum Thema, oder nur Hunger? :D
 
Kommentar
ein .NEF enthält keine Farbkanäle sondern nur die Information über die Stärke des Lichteinfalls auf den jeweiligen Sensorpunkt (Helligkeit). Es gibt also keine Farbtiefe oder Dergleichen abzuspeichern. Von de X-Millionen Photositen auf dem Sensor sind die allermeisten grün-empfindlich, einige rot und einige blau. zu jedem Photositen muss nur die Helligkeit gespeichert werden.

Zweistellig kommt man bereits auf 256 Werte (00 bis FF), vierstellig auf 65536 und achtstellig auf 4,3 Milliarden (Helligkeitsstufen pro Photosit). Letzteres braucht kein Mensch.; viel Cooler ist es, in einem Byte sowohl die X und Y Position, wie auch die Helligkeit abzuspeichern (und diese dann 12 oder 14 Bit tief, also zB in 16,8 mio Abstufungen (12 Bit) oder eben 65 mio Abstufungen (14 Bit).

Komprimiert oder unkomprimiert? Nutzen wir trotzdem die gesamte Länge, auch wenn die Werte so kurz codiert werden können, dass man sie kurz beschreiben kann kann? Links unten (0,0) Schwarz (00) eins weiter rechts (0,1) auch schwarz (00). Oder müssen wir JEDE Position vierstellig schreiben (sozusagen mit führender Null) 0000,0000 FFFF 0001,0000 FFFF? Ersteres nennt sich dann "verlustfrei komprimiert" und ist sinnvoll und OK.
 
Kommentar
ein .NEF enthält keine Farbkanäle sondern nur die Information über die Stärke des Lichteinfalls auf den jeweiligen Sensorpunkt (Helligkeit). Es gibt also keine Farbtiefe oder Dergleichen abzuspeichern. Von de X-Millionen Photositen auf dem Sensor sind die allermeisten grün-empfindlich, einige rot und einige blau. zu jedem Photositen muss nur die Helligkeit gespeichert werden.

... und diese RGB-Information wird bei der Konvertierung in psd und/oder tif interpoliert, was die Datengröße vervielfacht?
 
Kommentar
... und diese RGB-Information wird bei der Konvertierung in psd und/oder tif interpoliert, was die Datengröße vervielfacht?

Nnnnnicht so ganz, aber du bist in der richtigen Richtung unterwegs. Aus den unterschiedlichen Werten wird eine neue Datei erschaffen, die ungefähr (!) gleich viele Pixel hat, wie der Sensor Photositen. Jedem Pixel wird nun eine von drei Farben und deren Intensität zugewiesen. Je Farbtiefe desto Abstufung. Durch die drei Farben (plus 0/F für S/W) vervierfachen wir also (bei maximaler Farbtiefe) die Informationsmenge.

Das ist "nice to have" aber meist unnötig - weswegen auch kein Mensch .TIF braucht. In allen Bildern (99,99999%) gibt es mehr oder minder grosse Flächen gleicher Farbwerte, oft sogar mehrere davon. Benachbarte Pixel unterscheiden sich nicht voneinander: schwarzer Rahmen, 5 Pixel breit, strahlend blauer Himmel mit nur geringer Farb- und Helligkeitsvarianz, rote Autotür .... im JPG wird nicht jeder Pixel einzeln definiert, sondern erstmal sein Unterschied zum Nachbarn überprüft. Gibt es den nicht, ist alles super. Gibt es einen Unterschied, wird eine neue Farbe definiert - und die drei Farben sind auch nur jeweils 256 Abstufungen tief (8 Bit). Das klappt ganz ausgezeichnet bei Bildern mit starkem Kontrast und wenig Farbtönen (schwarze Striche auf weissem Blatt) und deutlich weniger gut bei bunt und kleingemustert.

Ein .JPG von einem Schachbrett wird also bei gleicher Pixelzahl eine wesentlich kleinere Dateigrösse haben, als das .JPG von Monets Sonnenuntergang über St. Georges-Majeur. Ensprechend sind auch S/W .JPG deutlich kleiner als farbige.
 
Kommentar
Das TIF Format würde ich generell meiden in der Fotografie. Es ist per Definition nicht nur eine Bilddatei sondern ein Containerdateiformat.
D.h. sehr vereinfacht ausgedrückt, es ist ein eigenes Dateisystem innerhalb einer Datei. Der eigentliche Inhalt wird über Metadaten näher in Aufbau und Form beschreiben.
Man kann z.B. eine TIFF Datei erstellen, die lediglich ein hochkomprimiertes JPEG enthält.

Für das Internet ist TIFF auch aus Gründen des Aufbaus ungeeignet, da es nicht streaming-fähig ist.

Fazit für mich ist: Wenn man TIFF verwendet, dann sollte man es auch verstehen. Mir ist es schlicht und einfach zu komplex und ich sehe für mich keinerlei Nutzen darin.
 
Kommentar
Nnnnnicht so ganz, aber du bist in der richtigen Richtung unterwegs.

Ich glaube ich habs kapiert. Die jpg-Komprimierung kannte ich schon, aber der Weg von der Photozelle (heißt die eigentlich Photozelle? Du schreibst von "Photosites".) zur Bilddatei war mir noch unklar. Danke für Deine geduldigen Erklärungen.

PS: Schmeckt Pizza eigentlich noch, wenn man doppelt soviel Hefe für den Teig verwendet? :confused:
 
Kommentar
Das Thema tif kann man noch detaillierter mit den NEFs oder anderen Raw-Daten vergleichen. Wichtig ist aber hauptsächlich: wenn man jemanden ein Bild weitergeben möchte, dass alle Bildinformationen möglichst genau enthält, dann macht ein Tif schon Sinn. Sonst müsstest du das Raw-File weitergeben, mit einer entsprechenden Bearbeitung dazu und derjenige, dem du das dann weitergibst, der bräuchte dann auch ein Programm, dass die von dir bearbeiteten Schritte mit dem Raw verrechnet und ihm das Ergebnis auch wieder korrekt anzeigt (also z.B. Lightroom, Capture One, DxO o.ä.). Macht also wenig Sinn. Ein Tif kann man eben in fast jedes gängige Programm importieren oder auch nur anzeigen lassen - zwar sehr schön detailliert, aber eben auch saumäßig große Dateien, weil alle Bildinfos standardisiert zu jedem Pixel abgespeichert sind. Das geht bei Raw einfacher, weil es nur die Rohdaten sind + einigen Extras wie z.B. den Metadaten. Aber wie genau die Hersteller das noch anstellen, weiß eh niemand ganz genau, auch nicht der Riese Adobe. Da lassen sich Nikon, Canon, Sony usw. Nicht in die Karten gucken...
Aber wie oft muss man jemanden so Bilder weitergeben? Braucht man eigentlich wirklich nur selten...


Gesendet von iPhone mit Tapatalk
 
Kommentar
Ja. es macht den Teig locker und dadurch lässt er sich sehr (!) dünn ausrollen. Das muss auch so sein, denn Pizza mit dickem Boden mag ich gar nicht. Wir backen den Boden einmal kurz an und belegen ihn erst dann.

500g Mehl
1/2 Würfel Hefe (oder ein Beutel Hefepulver)
1 ziemlich grosser Löffel Salz (viel hilft viel)
1 gestrichener Teelöffel Zucker
1 Schnapsglas (oder zwei) Olivenöl
250ml handwarmes/lauwarmes Wasser (+/- 30 - 35°)

Hefepulver im Wasser auflösen oder Hefewürfel zerbröseln
Zucker und Salz ins Mehl kippen
Wasser und Hefe drauf
- kneten
Öl dazu
- kneten
den Teigball abdecken und aufgehen lassen (wird bei Zimmertemperatur in drei bis vier Stunden mehr als doppeltes Volumen einnehmen)
...fettich....
 
Kommentar
Zweistellig kommt man bereits auf 256 Werte (00 bis FF), vierstellig auf 65536 und achtstellig auf 4,3 Milliarden (Helligkeitsstufen pro Photosit). Letzteres braucht kein Mensch.; viel Cooler ist es, in einem Byte sowohl die X und Y Position, wie auch die Helligkeit abzuspeichern (und diese dann 12 oder 14 Bit tief, also zB in 16,8 mio Abstufungen (12 Bit) oder eben 65 mio Abstufungen (14 Bit)

Da bringst du glaub ich Binär- und Hexadezimal-Zahlen durcheinander ;-)
mit 12 Bit kannst du 4096 Abstufungen darstellen, und mit 14 bit 16384 (was ja auch schon ausreichend ist weil soviele Helligkeitsstufen sicher kein menschliches Auge unterscheiden kann), Hexadezimal 4-Stellig wären bereits 16Bit und entsprechend Hex 8-Stellig sind 32Bit. Im Grundsatz hast du aber Recht und jeder weiß was gemeint ist...

und jetzt gibt's Pizza... ;)

lG Peter
 
Kommentar
-Anzeige-
Zurück
Oben Unten