Zitat:
Zitat von usch
Nein, nur die Dokumentation und die Ausgabe von RawDigger, aber der basiert ja auf libraw. Außerdem steht es in den Exif-Daten (hier anhand der Beispieldateien, die aidualk zur Verfügung gestellt hatte):
Code:
>exiftool -G0:1 -quality -photometric* -bitspersample -ext arw .
======== ./7R503744.ARW [1/3]
[MakerNotes:Sony] Quality : S-size RAW
[EXIF:SubIFD] Photometric Interpretation : YCbCr
[EXIF:SubIFD] Bits Per Sample : 15 15 15
======== ./7R503745.ARW [2/3]
[MakerNotes:Sony] Quality : M-size RAW
[EXIF:SubIFD] Photometric Interpretation : YCbCr
[EXIF:SubIFD] Bits Per Sample : 15 15 15
======== ./7R503746.ARW [3/3]
[MakerNotes:Sony] Quality : RAW
[EXIF:SubIFD] Photometric Interpretation : Color Filter Array
[EXIF:SubIFD] Bits Per Sample : 14
Solange man innerhalb des normalen Dynamikbereichs bleibt, sollten sich YCrCb und RGB verlustlos in einander umrechnen lassen, da kann also eigentlich nichts verloren gehen. IMHO leidet nur der Headroom bei Überbelichtung. Wenn von den drei Farbkanälen nur einer überbelichtet ist, kann ein guter Raw-Konverter anhand der anderen beiden die fehlenden Werte eventuell noch rekonstruieren. Wenn aber beim Konvertieren der Luminanzkanal ausfrisst, sind halt gleich alle drei Grundfarben betroffen. |
Danke Usch! Du bist der beste und hast immer fundierte Aussagen.
Ich habe es zwar nicht so Wissenschaftlich gemacht, sondern einfach ein paar Szenen nachgestellt, die ich brauche und da habe ich eigentlich keinen nennenswerten unterschied zum Compressed Raw feststellen können, außer das die Datenmenge geringer war. Deshalb wollte ich es für diesen Einsatz mal nutzen. Nun sind ca 2500 Bilder zusammengekommen und da es keine Lösung für das von mir angesprochen Thema gibt, hab ich nun mit großen Dateien zu arbeiten mit Auflösungen die der Kunde nicht braucht.