Diskussion:Rohdatenformat

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Rohdatenformat“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleibt mindestens ein Abschnitt.

Archiv

ab 2005

Wie wird ein Archiv angelegt?

Freie Software

Gibt es einen Grund, warum LightZone nicht aufgeführt wird? Vielleicht gibts sogar noch weitere?

Weil die Software keinen eigenen Artikel hat? Gibt es einen Grund, warum Software nach Lizenzmodellen unterschieden wird? --M@rcela 22:00, 3. Mai 2017 (CEST)

Rohdatenformat?

Imo widerspricht sich "Rohdaten" und "Format".

• "Rohdaten" sind Daten, die ohne Einhalten einer bestimmten Konvention (also ohne Format) so abgespeichert werden, wie es dem Gerät/der Software eben passt, z.B. weil sie sich eben in dieser Struktur aus der Hardware ergeben.
• Ein "Format" ist eine Übereinkunft, die übergreifend gilt; entweder zwischen verschiedenen Parteien (z.B. mehrere Hersteller, Softwareproduzenten) oder zumindest Produkt-übergreifend (d.h. alle Produkte eines Herstellers machen es immer gleich).

--arilou (Diskussion) 13:35, 23. Mai 2017 (CEST)

Auch in einem RAW werden ja nicht einfach 1:1 linear die Spannungswerte runtergeschrieben, die Sensor liefert. Das ist keine nackte Messkurve, sondern ein bereits digital aufbereitetes Signal, dass in einem Hersteller definierten Format komprimiert und gespeichert wird. Nur ist dieses Format eben was Auflösung, Dynamik usw angeht sehr viel näher an dem was der Chip liefert als eine JPG.

Und natürlich gibt es dabei Format-typische Konventionen – sonst wäre es wohl kaum möglich, dass Hersteller über mehrere Kameras hinweg dasselbe Format verwenden und dass RAWs mit Dritthersteller-Software geöffnet und zu bearbeitet werden können?! // Martin K. (Diskussion) 15:20, 23. Mai 2017 (CEST)

Tabelle "Gegenüberstellung"

Bzgl. diesem Re-Revert und voriger Änderungen. --arilou (Diskussion) 15:40, 23. Mai 2017 (CEST)

Du bist langgenug dabei um zu wissen, dass man nach einen begründeten Revert einer umfangreichen Änderung nicht rerevertiert, sondern erst eine Verständigung auf der Disk sucht. Ich habe den Artikel daher wieder auf den Status quo ante zurückgesetzt und würde Dich bitten in so zu belassen, bis wir hier einen Konsens haben. // Martin K. (Diskussion) 16:03, 23. Mai 2017 (CEST)

Gegenüberstellungs-"Partner" JPEG

Es gibt nicht nur JPEG als Nicht-Raw-Format. Viele Punkte dieser "Gegenüberstellung" sind JPEG-spezifisch und gelten für andere Formate, z.B. PNG, nicht. --arilou (Diskussion) 15:42, 23. Mai 2017 (CEST)

Es geht hier nicht um RAW vs. irgendein Nicht-Raw-Format, sondern um RAW vs. direkt von der Kamera entwickelte Formate. Und abgesehen von wenigen teuren Profikameras handelt es sich bei diesen direkt von der Kamera entwickelte Formaten immer um JPGs. // Martin K. (Diskussion) 16:24, 23. Mai 2017 (CEST)

Hm, da prallen wohl mal wieder zwei Welten aufeinander.

Ich nehme mal an, du entstammst deutlich aus der "Fotografen-Ecke" - viel Wissen über Fotografie, auch noch aus der "Analog-Zeit".

Ich wiederum hab' nur (sehr) eingeschränkt Ahnung vom Fotografieren selbst (ich besitze nicht mal einen Fotoapparat), als Informatiker lese ich aber viel über Technik (auch die von Fotoapparaten).

Als Techniker dreht sich mir der Magen um, wenn ein "Nicht-Raw-Format" als "entwickelt" bezeichnet wird. Das deutet an, dass hierbei ein wesentlicher Be- oder Verarbeitungsschritt stattfände, und anschließend kaum weitere Be- oder Verarbeitung möglich sei. Das ist aber nicht der Fall (genauer: es hängt erheblich davon ab, was die Kamera tatsächlich macht, und in welches Zielformat, ggf. mit welchen Einstellungen/Parametern, konvertiert wird). Afaik gibt es Kameras, die bereits in ihre Raw-Daten so manche "Korrektur" einrechnen; deren "Nicht-Raw-Bilder" stellen dann nur noch geringfügige Änderung zu den Raw-Daten dar.

Allgemeine Aussagen zum Unterschied Raw <-> mögliches anderes Bildformat müssen also auch für solche Situationen stimmen.

Was ich nicht weis: Beherrschen denn praktisch alle Fotomodelle als Nicht-Raw-Format ausschließlich JPEG, und bieten niemals an, in JPEG verlustlos zu speichern (was das JPEG-Format nämlich durchaus kann)? Dann wäre es gerechtfertigt, bei einer Gegenüberstellung fest vorzugeben, dass die (einzige) Alternative zu Raw stets JPEG_mit_Verlust ist.

Das zu belegen stell' ich mir aber schwierig vor; es genügt ja auch 1 Gegenbeispiel, um zu zeigen, dass zumindest nicht alle Fotoapparate nur JPEG_mit_Verlust können.

--arilou (Diskussion) 09:48, 24. Mai 2017 (CEST)

@Arilou: Da ich sowohl Photograph als auch Webentwickler bin, bilde ich mir eigentlich schon ein, einen gewissen Einblick in beide Seiten der Materie zu haben.

Natürlich findet beim "Entwickeln" der Rohdaten (ob nun in der Kamera oder außerhalb) ein wesentlicher Bearbeitungschritt statt. Dabei wird u.a.:

• das Signal der monochromen rot-, grün- oder blau-gefilterten Zellen des Bayer-Sensors auf RGB-Pixel interpoliert.
• der Weißabgleich festgelegt (was sich auf Basis eines JPGs nur noch sehr unzureichend ändern lässt).
• Tonwertgrenzen und Gradation festgelegt und dabei der Dynamikumfang von ~12bit auf 8bit pro Farbe reduziert.
• die Bildinformation entrauscht (irreversibel)
• und nachgeschärft (was ebenfalls nicht wirklich umkehrbar)
• usw.

Das sind erhebliche Interpretationen und Informationsreduktionen des Ursprungsmaterials, die sich im Nachhinein nur noch mit erheblichen Verlusten korrigieren lassen. Die Analogie zum entwickeln eine Films und Erstellen eines Papierabzugs ist hier schon berechtigt.

Ich weiß ja nicht, ob Du selbst mal RAWs bzw. JPGs nachbearbeitet hast? Falls ja müsstest Du eigentlich wissen, dass eine Unterschied wie Tag und Nacht ist:

• So lässt sich ein in der Kamera falsch eingestellter Weißabgleich lässt sich bei einem RAW problemlos korrigieren; bei einem RGB-JPG führt das zu erheblichen Farbverfälschungen.
• Ausgebrannte (weiß) oder abgesoffene (schwarz) Bildbereiche sind bei einem JPG einfach weg (da gibt es schlicht keine Bildinformationen mehr, mit der man irgendwas machen könnte). Bei einem RAW hingegen lässt sich oft noch sehr viel aus den sonst abgeschnittenen Dynamikbereichen herausholen um z.B. einen hellen Himmel wieder sichtbar zu machen oder etwas Zeichnung in die Schatten zu bringen.
• Wenn auf einem in der Kamera entwickelten JPG noch Rauschen zu sehen ist, dann wurde das bereits mitgeschärft und lässt sich entsprechend schwieriger entfernen.
• Dasselbe gilt für Chromatische Aberration. Auch die lassen sich wesentlich besser herausrechnen, wenn man die Ursprungsdaten hat und nicht ein bereits durch etliche Bildmanipulatuionsprozesse verändertes JPG.

Nochmal zum Verständnis: Es geht hier weniger um den Vergleich zwischen zwei Dateiformaten, sondern um der Vergleich zwischen (weitesgehend) unbearbeiten Daten und solchen, die bereits durch etliche automatische Bildoptimierungsalgorithmen gelaufen sind und in ein verfassungskonformes Standardformat runtergebacken wurden.

Außerdem gilt in diesem Projekt WP:Q und WP:KTF. D.h. wenn die verfügbare Literatur das von der Kamera generierte JPG als "entwickeltest Bild" bezeichnet, dann sollten auch wir das tun, statt hier irgendwelche eigenen Theorien zu entwickeln.

Was die Frage nach unterstützen anderen Dateiformaten angeht. Es gibt im professionellen Bereich noch einige Kameras die in der Lage sind, TIFs zu speichern. Da das aber im Vergleich zu JPGs kaum Vorteile bei gleichzeitig erheblich größeren Dateien bietet und bei weitem nicht die Nachbearbeitungsmöglichkeiten eines RAWs hat, ist das eher ein aussterbendes Feature. Wenn dann setzen die Hersteller heutzutage eher das weitgehend standardisierte DNG-Format.

Und genau das ist der Knackpunkt in Deiner Argumentation: Gäbe es ein Standardformat, dass unkomprimiert wäre, eine hohe Bittiefe besäße und auch sonst alle Bearbeitungsmöglichkeiten eines RAWs bieten würde, wäre das per definitionem ebenfalls ein Rohdatenformat. Und mit DNG gibt es ja ein solches Format. // Martin K. (Diskussion) 10:43, 24. Mai 2017 (CEST)

Verlustfreies Komprimieren bei JPEG

JPEG kann sehrwohl verlustfrei komprimieren. Dann komprimiert's aber nicht besser als andere Verfahren, z.B. PNG. --arilou (Diskussion) 15:42, 23. Mai 2017 (CEST)

Das mag in der Theorie so sein, in der Praxis (wir sprechen hier über das von Digitalkameras generierte Format) wird aber meines Wissens aber nur eines der verschiedenen in der JPEG-Norm definierten Formate unterstützt. Und dieses teilt das Bild in einer 8x8 Blöcke auf die dann in mehrern Schritten verlustbehaftet komprimiert werden. Im Gegensatz zum PNG-Format werden hier keine einzelnen Pixel gespeichert, weshalb das wieder de komprimierte Bild nie 100% mit dem Original identisch ist. // Martin K. (Diskussion) 16:24, 23. Mai 2017 (CEST)

Es ist richtig, dass "das JPEG-Format" so viele Einstellmöglichkeiten und Parameter bietet, dass man fast davon sprechen kann, dass es mehrere "Unterformate" davon gibt.

Aber: Die von Kameras verwendete Variante kann sehrwohl verlustlos komprimieren. Was genau ein bestimmtes Kameramodell bei Einstellung "JPEG - höchste Qualität" macht, gibt natürlich der Hersteller vor. (Theoretisch Können und tatsächlich Machen sind halt immernoch zwei Paar Stiefel.)

(PS: Dass das JPEG-Format vom Bildraum in den Frequenzraum transformiert, und anstatt von Pixeln Schwingungen speichert, ist eine verlustlose Wandlung, und kann wieder auf's Bit genau auf dieselben Pixeldaten rückgerechnet werden.)

(PPS: Andere Restriktionen bleiben natürlich; z.B. ist die verbreitetste JPEG-Variante, die wohl so ziemlich alle Kameras erzeugen (können), auf 8 Bit pro Farbkanal beschränkt, richtig. Diese Vorab-Wandlung wird aber i.A. nicht als Bestandteil der "verlustbehafteten Kompression" von JPEG bezeichnet - dazu wird nur verglichen: Wie groß waren die (3*8-Bit-)Daten vorher, und wie klein und mit wieviel Verlust zu selbigen ist das JPEG-Bild nachher.)

--arilou (Diskussion) 10:03, 24. Mai 2017 (CEST)

Lies mal JPEG#Die_JPEG-Komprimierung. Von den sechs Bearbeitungsschritten bei der JPG-Komprimierung sind vier verlustbehaftet. Der erste davon ist bereits die Konvertierung in den YCbCr-Farbraum. Und damit kann ein einmal als JPG gespeichertes RGB-Bild nie 100% identisch mit den Originaldaten sein. Probier's einfach mal aus:

• Such Dir ein Foto und öffne es in Photoshop.
• Beschneide/verschiebe/skaliere es so, dass Du nicht mehr im 8x8 des Ursprungs-JPGs bist.
• Speichere das Bild bei 100% JPG-Qualität.
• Öffne die JPG-Datei und kopiere sie in Photoshop auf eine Eben genau über dem Original.
• Stell diese Ebene auf den Mischmodus "Differenz" (Jetzt solltest Du etwas ziemlich Schwarzes sehen).
• Jetzt öffne die Tonwertkorrektur und zieh den Weißregler so weit runter, bis Du etwas siehst.

Wären die Bilder identisch müsste das Ergebniss einfarbig schwarz sein. Das ist es aber nicht. Es rauscht in allen Farben des Regenbogens. Und das liegt an der Verlustbehafteten JPG-Komprimierung. // Martin K. (Diskussion) 11:03, 24. Mai 2017 (CEST)

"rein kameraseitig zu beachtenden Bildparameter"

Wie weiter unten zu lesen ist, rechnen einige Kameras bereits Bildverbesserungen in ihre Raw-Daten. Somit ist "unverfälscht" kein sicheres Raw-Merkmal, und jede Position von " Weißabgleich, Farbsättigung bzw. angewandter Farbfilter (für Schwarz-Weiß-Fotografie), Farbraum, Kontrast," ... kann genauso in die Rawdaten eingeflossen sein. Außerdem gibt's doch bestimmt Kameras, denen man sagen kann, dass sie in das Nicht-Raw-Format bitte keine "Bildverbesserungen" reinrechnen sollen? --arilou (Diskussion) 15:47, 23. Mai 2017 (CEST)

Hast Du schon mal RAWs und JPGs parallel photographiert und dann mal versucht bei beidem z.B. den Weißabgleich anzupassen? // 16:24, 23. Mai 2017 (CEST)

Schon mal Bildbearbeitung mit PNG gemacht, bei 16 Bit Farbtiefe pro Kanal?

--arilou (Diskussion) 10:29, 24. Mai 2017 (CEST)

Ja, hab ich. Dummerweise kommt nur an so ein 16bit PNG wenn man es sich entweder digital baut (rendert) oder eines aus einem RAW exportiert (was praktisch 0 Vorteile bringt). Eine Kamera, die so etwas speichert ist mir nicht bekannt. // Martin K. (Diskussion) 11:21, 24. Mai 2017 (CEST)

"Verlusten an Bildinformation"

Das direkte Arbeiten mit Raw-Daten schützt ebenfalls nicht davor, dass (afaik) jede Bildbearbeitung einen Verlust an Information bedeutet. --arilou (Diskussion) 15:49, 23. Mai 2017 (CEST)

In praktisch jedem guten RAW-Konverter findet die Bildbearbeitung heute verlust frei statt. D.h. die Software (z.B. Adobe Lightroom) speichert nur die Bearbeitungsbefehle und führt diese bei jeder Anzeige und jedem Export ausgehend von der identischen Originaldatei erneut aus. So wird auch bei späteren Veränderungen das bestmögliche Ergebnis gewährleistet. // Martin K. (Diskussion) 16:24, 23. Mai 2017 (CEST)

Jedes "gute" Bildbearbeitungsprogramm kann das genauso bei anderen Datenformaten.

Das ist kein Alleinstellungsmerkmal von Raw.

--arilou (Diskussion) 10:27, 24. Mai 2017 (CEST)

Das Problem ist, dass bei "anderen Daten" bereits das Ausgangsmaterial verlustbehaftet ist (s.u.). // Martin K. (Diskussion) 11:21, 24. Mai 2017 (CEST)

Bittiefe, Kompressionsverluste

JPEG-spezifisch. Andere Formate, z.B. PNG, können 16 Bit pro Farbkanal, und komprimieren verlustlos. --arilou (Diskussion) 15:51, 23. Mai 2017 (CEST)

Die werden von marktüblichen Kameras aber nicht automatisch gespeichert.

Außerdem geht es nicht nur um die Bittiefe, sondern z.B. auch um das Interpolieren des Bayer-Musters // Martin K. (Diskussion) 16:24, 23. Mai 2017 (CEST)

1. Ob man zwischen Raw und Jpeg in der Kamera umstellt, oder zwischen Raw, Jpeg und Png, ist ja wohl kein nennenswerter Mehraufwand.
2. Afaik gibt es keine Garantie, dass Raw-Daten die Daten vor einer Sensor-Interpolation sind.
   Ganz egal ob Bayer- oder sonst ein Sensortyp.

--arilou (Diskussion) 10:07, 24. Mai 2017 (CEST)

Das mit dem PNG kannst Du ja gerne den Kameraherstellern vorschlagen. Aber es hat schon seinen Grund, weshalb dieses "Feature" auf dem Markt de facto nicht verfügbar ist. // Martin K. (Diskussion) 11:21, 24. Mai 2017 (CEST)

Kompatibilität

Als "möglichen Ausweg" aus den Unterstützungs-Problemen für Rawdaten anzubieten, ein genormtes Format zu verwenden, ist ja wohl ein Witz in sich. Dann sind's keine "Raw"-Daten mehr. Kann man auch gleich PNG oder sonstwas existierendes nehmen. --arilou (Diskussion) 15:54, 23. Mai 2017 (CEST)

Lies Dir mal den Artikel zum DNG-Format durch. // Martin K. (Diskussion) 16:24, 23. Mai 2017 (CEST)

Ein Format, das (Hersteller-/Modell-übergreifend) irgendwelche Vorgaben macht, wie Daten abzulegen und zu interpretieren sind, enthält entweder keine Rohdaten mehr, oder kann kaum mehr als ein einfaches Containerformat sein.

Ersterer Fall widerspricht der Annahme, dass Rohdaten gespeichert werden sollen; zweiter Fall stellt keine Verbesserung der Situation dar ist somit kein "möglicher Ausweg".

Natürlich kann ein bestimmtes Format besonders gut geeignet sein, Daten üblicher Sensoren nah am Rohdatenzustand aufzunehmen. (Aber: Knapp daneben ist auch vorbei.) Und niemand hindert das Standardisierungsgremium, irgendein "Roh" oder "Raw" in den Namen ihres Formats zu packen.

--arilou (Diskussion) 10:18, 24. Mai 2017 (CEST)

Der Begriff ist nun mal so, wie er ist. Du musst das nicht gutfinden – aber das ist dann eben Deine persönliche Meinung und nicht die belegbare Realität. 🡢 WP:KTF // Martin K. (Diskussion) 11:21, 24. Mai 2017 (CEST)

Nachbearbeitung

Viel JPEG-spezifisches; dass manche Bearbeitungsschritte zu Verlusten führen, gilt (so allgemein) auch für Raw-Daten. --arilou (Diskussion) 15:57, 23. Mai 2017 (CEST)

Siehe Non-destructive editing // Martin K. (Diskussion) 16:27, 23. Mai 2017 (CEST)

Viele Bildbearbeitungsverfahren sind auch verlustbehaftet, wenn sie direkt auf Raw-Daten rechnen.

Welche Verfahren auf welchem Datenformat verlustlos durchführbar sind, ist stark Format-abhängig.

Ich betrachte es daher als Unsinn, bestimmte Verfahren rauszugreifen und gesondert zu erwähnen. (Zumindest, solange (siehe oben) JPEG nicht als "alleinige Alternative" feststeht.)

--arilou (Diskussion) 10:21, 24. Mai 2017 (CEST)

Nachtrag: Man kann natürlich schreiben, dass alle Nicht-Raw-Formate bei der Bildbe-/-verarbeitung bei vielen Bildbearbeitungsverfahren zusätzliche Verluste bedeuten können, da ja nur Raw die maximale Information enthält. --arilou (Diskussion) 10:25, 24. Mai 2017 (CEST)

Es geht darum, ob man bei der Bearbeitung bereits mit verlustbehafteten Daten anfängt oder nicht. Und bei einem RAW fängt man eben nie mit verlustbehaften bearbeiteten Daten an, weil man bearbeitete Version nicht als RAW speichern kann. Die Bilddaten eines RAWs beleiben immer unangetastet. Stattdessen speichert man (XMP-)Meta-Daten zu den Änderungen oder eben ein JPG. // Martin K. (Diskussion) 11:21, 24. Mai 2017 (CEST)