Diskussion:Rohdatenformat/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Rohdatenformat/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Rohdatenformat/Archiv/1#Thema_1

Artikel relativ unvollständig

Raw-Daten sind IMHO grundsätzlich Rohdaten allgemein!!

Ich hab z.B. eine uralte Version des Cool-Edit-Audioeditors, der schluckt auch RAW. Das sind in dem Fall Wavedateien ohne Header. D.h. man muß Samplingrate und Kanäle und Auflösung beim Laden vorgeben, damit er was brauchbares mit anstellen kann.

Wenn man z.b. mit Pascal eine Text-Datei voll chr(255) schreibt und sie im Cooledit als 8Bit Mono RAW lädt, bekommst man eine Darstellung wo ganz oben im Waveeditor eine Linie durchgeht. Logisch. Ist halt permanent Maximalpegel.

Ein Spiel, welches RAW-Audiodaten verwendet, ist beispielsweise das schon ältere Interplay Atomic Bomberman. Allerdings enden die Dateien auf .RSS, es sind aber RAW-Daten die sich wie oben beschrieben ins alte CoolEdit laden lassen.

Ergo sind RAW-Daten einfach eine vorhandene Menge an Daten, die einem einfach vorgesetzt werden. Meistens sind es Informationen, die von einem Sensor A/D-Wandler etc. direkt in eine Datei geschrieben wurden. Allerdings erklären sie sich kein bißchen selber und verraten nichts über ihre Struktur und Organisation. Da muß der Empfänger schon selbst wissen wie er damit umgeht.

Bei Digicams wird es dasselbe sein. Einfach die Daten vom CCD in ne Datei reingehauen... Wenn Windows auf einer Festplatte Daten findet, aber kein Dateisystem, zeigt es als Dateisystem übrigends auch "RAW" an.

Das ist korrekt, ich werde den Artike nach Rohdatenformat (Fotografie) verschieben (bzw. die Seite neu anlegen), und hier einen allgemeineren, kurzen Text einfügen. Die Links ZU dieser Seite müssen dann halt nach und nach geändert werden. Rasterzeileninterrupt 21:29, 18. Mai 2007 (CEST)

Kompatibilität

Es mag ja sein, dass die Bildsensoren der verschiedenen Hersteller sich nicht groß unterscheiden, aber trotzdem geschieht ja auch bei RAW eine gewisse Bearbeitung durch die Digitalcamera selbst, und diese Bearbeitungen sind natürlich von Hersteller zu Hersteller unterschiedlich, daher ist es eigentlich nicht groß verwunderlich, dass die RAW-Dateien nicht kompatibel sind. −−85.181.250.67 23:50, 11. Apr. 2009 (CEST)

Qualitätsverlust bei TIFF?

Im Abschnitt "Vorläufer-Format TIFF" heißt es: "Eine nachträgliche Korrektur geht wie auch bei JPEG-komprimierten Bildern mit einem Qualitätsverlust einher." Wirklich? TIFF ist im Unterschied zu JPEG verlustfrei komprimiert, daher zieht eine Bearbeitung zumindest keine verlustbehaftete Neukomprimierung nach sich, wie bei JPEG. Eine Bearbeitung von Daten führt zwar immer zu einem Verlust der ursprünglichen Information; aber das gilt für TIFF genauso wie für RAW. Gegenüber TIFF hat RAW lediglich den Vorteil, dass erstens die Daten unverändert ab Sensor gespeichert (d.h. ohne verfälschende optische Aufbesserung) werden und zweitens mehr Daten vorhanden sind (höhere Farbtiefe). Oder habe ich die Aussage dieses Satzes falsch verstanden? Kann das mal jemand korrigieren? Cmoder 13:59, 19. Aug 2005 (CEST)

Kameragenerierte TIFFs und JPEGs durchlaufen beide die kamerainterne Bildverarbeitungs-Pipeline, somit unterlaufen sie unter anderem einer Reduktion der Farbtiefe, sie werden geschärft usw. RAW-Files dagegen werden an der Imaging-Pipeline vorbeigelassen und weitgehend unverändert gespeichert. Die WB-parameter z.B. werden 'tagged' und können auch nachträglich bei der Konvertierung verlustfrei verändert werden. Sämtliche andere Einstellungen bei der Konvertierung von RAW sind ebenso verlustfrei. Ich hoffe damit sieht die Sache für Sie klarer aus. Cheers, --dragra 00:44, 8. Dez 2005 (CET)

RAW-Unterstützung im Amateurbereich

Die Experten die das geschrieben haben stellen RAW als Nachteil vor. Gerade im Amateurbereich ist RAW mit vielen (völlig falschen) Vorurteilen belastet. Ich habe versucht dieses Kapitel etwas neutraler anzugehen. Salut, --dragra 16:20, 30. Aug 2005 (CEST)

---

Wäre auch noch gut zu wissen was ccd-daten sind. Ich hab gegooglelt usw. und nix dazu gefunden vllt. wird es ja noch erweitert. danke

RAW mit Vorurteilen

RAW hat Nachteile, RAW hat Vorteile. Je nach Einsatzbereich, Motivation und Speicherkapazität wird man sich für/gegen RAW entscheiden. Würde man RAW hier "positiver" darstellen, würden das zwar viele Leser als Ansporn betrachten, RAW auch zu verwenden. Wikipedia soll/will aber neutral bleiben, keine Werbung machen, stattdessen alle Standpunkte und Aspekte einfangen. -- Das emm 14:36, 31. Aug 2005 (CEST)

Hallo Dass emm, will man RAW als nachteilig darstellen so hat man die Funktionsweise sowie vor allem den Nutzen für den Fotografen nicht verstanden. Die einzigen Nachteile von RAW die ich mir vorstellen kann sind die Speicherbelegung/verzögertes Buffering, sowie die nötige Zeit um RAW-Files nachträglich zu konvertieren.

Die deutsche Fotografencommunity ist leider noch sehr stark von den Vorurteilen gegenüber RAW belastet, wie ich in vielen Internet-Foren bemerke. Entweder haben es die meisten User noch nicht verstanden, oder sie sind einfach faul und wollen nach dem Druck auf den Auslöser nichts mehr mit dem Bild machen, ich weiß es nicht.

Was Sie sonst von Neutralität und Werbung geschrieben haben ist im bezug auf RAW völlig daneben, weil der Artikel überhaupt nicht neutral und objektiv gewesen ist. Die Vorteile von RAW wurden nämlich nirgends in einer verständlichen Sprache ausformuliert. Warum zählen Sie nicht die negativen Aspekte von RAW auf, die Ihrerseits relevant sind? Machen Sie ein eigenes Kapitel daraus, wenn sie wollen! Zwecks Neutralität, versteht sich. Ich bin wirklich gespannt drauf! --dragra 01:01, 8. Dez 2005 (CET)

Ich verstehe die Kritik nicht ganz. Es gibt Einsatzfälle, für die RAW nicht geeignet ist und sich nachteilig auswirkt, sie wurden bereits von Dir/Ihnen aufgezählt (Speicherplatz, Zeitaufwand für nachträgliche Bearbeitung). Ich selbst bin leidenschaftlicher RAW-Fotograf und muss mit den genannten Vorurteilen anderer Leute genauso kämpfen. Genauso muss ich aber akzeptieren, dass die Leute mit der automatischen RAW-Konvertierung der Kamera (i.e., Abspeichern als JPEG) oftmals zufrieden sind. Das sind einerseits die "Anfänger", die im Stadion oder der Oper mit Blitzlicht fotografieren oder voll Stolz sagen, dass sie standardmäßig (auch im Sommer) auf ISO 400 oder 800 (was die Kamera als Maximum hergibt) fotografieren, weil damit die Fotos weniger verwackelt werden. Andererseits sind das auch die Profis, die mit sündteuren Kameras mit Spitzenobjektiven auf Hochzeiten, Messen und Tanzbällen herumlaufen und sagen, dass sie einerseits den Speicherplatz für die RAW-Daten nicht haben, mehr aber noch keine Zeit haben, aus den hunderten Bildern, die innerhalb weniger Stunden entstehen, die besten mit RAW-Postprocessing zu vergolden.

Ich bin, was die Neutralität des Artikels betraf und betrifft, auch nicht glücklich. Aber dafür ist ein/dieses Wiki ja da: Jede Änderung ist ein Schritt zum Besseren. --Das emm 14:24, 8. Dez 2005 (CET)

Hallo! Die Kritik mußte kommen, weil ja die 'Nachteile' die Sie aufstellen in keinem Verhältnis zum Qualitätsverlust sowie dem verlorenem kreativem Spielraum stehen. Der folgende Satz Ausserdem steht der Zeitaufwand, den der Kameraprozessor zur Konvertierung in das JPEG-Format braucht, in keinem Verhältnis zu dem erheblich höheren Zeitaufwand bei dem Schreiben der Rohdaten auf das Speichermedium beweist die etwas eindimensionale Wahrnehmung, ich weiß nicht ob er von Ihnen stammt. Diese Nachteile waren vielleicht für die ersten Generationen von dSLRs gültig, bei der aktuellen Generation sind diese auch in der Einsteigerklasse nicht mehr haltbar. Der Pufferspeicher wurde sogar bei den billigsten Modellen aufgestockt und die Schreibgeschwindigkeit ist bereits bei Speicherkarten der mittleren Preisklasse ausgesprochen gut. Außerdem bieten die aktuellen dSLRs die sehr komfortable RAW + JPEG Option an.

RAW bringt in jedem fotografischem Bereich einen Qualitäts- und Flexibilitätsvorteil, natürlich wenn sie als Fotograf bereit sind den Mehraufwand der Konvertierung zu akzeptieren. Wenn sie ein Profi sind, dann muß am Ende auch die Rechnung stimmen. Ansonsten gebe ich Ihnen Recht, das viele Eventfotografen ausschließlich im JPEG fotografieren, einerseits weil keiner von ihnen ein Budget für den Mehraufwand der RAW-Nachbearbeitung hat, anderseits weil für den Verwendungszweck der Bilder die Qualität der JPEGs ohnehin ausreicht. Aber auch unter den 'rasenden Reportern' erkennen immer mehr die Bedeutung und Vorteile von RAW, es wird vermehrt eingesetzt. Studio- & Hochzeitsfotografen die früher mit Mittelformatkameras gearbeitet haben schwören auf RAW bereits seit der ersten Stunde.

Sie schreiben selbst ein begeisterter RAW-Benutzer zu sein, nutzen wir doch die Gelegenheit und plaudern hier ein bischen über Ihren spezifischen Workflow. Bis dann, --dragra 16:37, 8. Dez 2005 (CET)

zu dem Thema Nachteile viele Fotografen mögen Raw nicht weil sie einen Teil des Workflows abgeben müssen wenn sie nicht selbst bereit sind sich damit zu beschäftigen... Die Raw Entwicklung ist ein komplexer Vorgang mit vielen Möglichkeiten, und somit auch mit viel Mühe und technischem Wissen verbunden welches vorher in diesem Umfang nicht nötig war. Ich will niemanden in einen Topf werfen aber manche Scheuen diesen Schritt und haben Sorge einen Teil Ihrer Macht über das Bild abgeben zu müssen.--Geckosilver 03:26, 3. Feb. 2009 (CET)

Powershot S-Serie???

Laut dpreview.com hat KEINE der Sx-Kameras von Canon RAW-Unterstützung, auch die S1 nicht. Vielleicht sollte die entsprechende Bemerkung nochmal geändert oder präzisiert werden, falls sie sich auf eine SD-x bezieht. Rasterzeileninterrupt 21:11, 18. Mai 2007 (CEST)

"Weißabgleich"

Die gesamte Weißabgleichsdiskussion ist Mist, wie sie da steht. Man kann Weißabgleich nachträglich vornehmen, ja, aber das ist nicht Zweck dieses Artikels.

Was sollen beispielsweise Bilderklärungen wie "kommt dem Kameravorschlag recht nahe"? Tatsächlich hat ja wohl eher die besagte Kamera im linken Bild ihre Empfindlichkeitskurven für die JPEG-Entwicklung nahe einer Schwarzkörperstrahlung von 6000 K eingestellt, nicht andersherum. Und was sagt das aus? Überhaupt nichts. Was hat das mit RAW zu tun? Wiederum nichts. Fazit: Entsorgen. (nicht signierter Beitrag von 85.177.189.139 (Diskussion) )

Ganz im Gegenteil. Das RAW-Format erlaubt einen Weißabgleich in einem Umfang, der bei anderen gängigen Formaten (JPG) nicht machbar ist. Im Gegensatz zu dem Sonnenuntergang, dessen Korrekturen höchstwahrscheinlich auch bei JPG machbar wären, zeigen gerade die Unterwasseraufnahmen, was mit RAW möglich ist. Und dies ist in der Tat ein Wissensbeitrag. --Plenz 12:37, 7. Jan. 2009 (CET)

Andere Formate als RAW erlauben überhaupt keinen Weißabgleich, schon per Definition nicht. Allenfalls eine Reparatur verunglückter Aufnahmen oder bewußte Farbveränderungen. Der Weißabgleich findet entweder kameraintern statt, mittels optischer Filterung oder bei der RAW-Entwicklung. Das kann im Artikel Weißabgleich prima behandelt werden und gehört hier wirklich nicht ausführlicher als mit einem kurzen Hinweis rein. -- Smial 19:12, 8. Jan. 2009 (CET)

Qualität des Artikels/Überarbeiten

Der Artikel verfehlt an einigen Stellen seinen Zweck/Titel.

"Funktionsweise" beginnt mit der unbelegten Behauptung, es wäre oft ein proprietäres Format?!? Was soll das? Tatsächlich müsste hier stehen, wie die Rohdaten zustande kommen: Kamera belichtet Sensor, der wird ausgelesen => wie werden die Daten dann abgelegt. Dateiformate sind uninteressante Details für den weiteren Verlauf des Artikels und haben so früh nichts verloren. Erstmal klären, was es ist, dann das wie.

Der Vergleich zu JPEG und dessen Beschreibung als "Vorteil" ist unmotiviert und deplaziert, und sollte zumindest in einen Abschnitt "praktische Bedeutung in digitaler Photographie" oder sowas verschoben werden. Tatsächlich ist das Rohdatenformat ja die Referenz, und alle anderen Formate müssen sich am Rohformat messen hinsichtlich der Informationseinbußen und der Bedeutung dieser Einbußen.

Der Abschnitt kameraseitig bearbeitete Rohdaten ist nicht belegt.

TIFF ist nicht hinreichend abgegrenzt; beispielsweise schreiben einige Kameras (Minolta, Sony) ihre Rohdaten mit proprietärer Kompression in TIFF-Container.

Anspielungen, digitale Spiegelreflex =^= professionell sind deplaziert. Diese Wertungen, und das Werkzeug, haben weder mit beruflicher Ausrichtung noch Anspruch der Fotografie zu tun. Es gibt auch SLR-Kameras, die auf Einsteiger zielen, die oft genug - Achtung Polemik: von Tuten und Blasen keine Ahnung haben und Canon kaufen, weil das alle kaufen - und dann denken, dass sie mit der tollen Kamera direkt tolle Ergebnisse bekommen.

Zu einer vollständigen fachlichen Begutachtung fehlen mir Zeit und Neigung. Mögen andere Leute den Artikel zu dem machen, was er verspricht zu sein. (nicht signierter Beitrag von 85.177.189.139 (Diskussion) )

1. YMMD. 2. Schade, solch eine Umstrukturierung sollte von Leuten gemacht werden, die sich auskennen. -- Smial 19:17, 8. Jan. 2009 (CET)

Was den Stein ins Rollen brachte und wo die "neigungslosen" Auskenner sind, kann man hier nachlesen. --Plenz 20:41, 8. Jan. 2009 (CET)

Ich benutze das richtige XP :-) -- Smial 22:00, 8. Jan. 2009 (CET)

Schreibweise

Raw ist keine Abkürzung, sondern ein ausgeschriebener Begriff. Bei der Schreibweise "RAW" wird suggeriert, dass jeder dieser Buchstaben für einen eigenen abgekürzten Begriff stünde (wie bei "CD-ROM"). Deshalb sollten der Artikel in Raw umbenannt und alle Vorkommnisse von "RAW" korrigiert werden, da sich die Großschreibweise lediglich als schlechte Angewohnheit durchgesetzt hat. -- 88.71.56.16 15:55, 4. Mär. 2009 (CET)

Der Artikel heißt "Rohdatenformat (Fotografie)" nicht "RAW-Format", was soll man da ändern? Außerdem ist RAW gebräuchlich und im ersten Satz steht bereits "RAW (engl. raw „roh“)". Wie sollte man auf die Idee einer Abkürzung kommen? Wenn es sich durchsetzt, dass man zum Hund nun Kuh sagt, dann wird der Artikel Kuh auch über Hunde handeln. Wikipedia sollte hier nicht neues erfinden. --Euku:^⇄ 16:07, 4. Mär. 2009 (CET)

Wie man darauf kommt? Habe ich doch gerade geschrieben: Ein aus Großbuchstaben bestehendes Wort ist ein Kunstwort, das sich aus den Anfangsbuchstaben anderer Wörter zusammensetzt. Wie du selbst wiederholt hast, besteht "Raw" aber nicht aus anderen Wörtern. Wenn sich ein Fehler eingebürgert hat, übernimmt ihn die Wikipedia generell nicht, sondern weist höchstens in dem Artikel über den geläufigen Fehler hin. Sonst könnte man gleich noch über die Artikel "Standart", "Selbstständigkeit", "Walfisch" und "Fotographie" nachdenken, weil viele Leute diese Wörter auch nicht auf die Reihe kriegen. Richtig: Wikipedia sollte nicht Neues erfinden, aber genau dies geschieht mit dem nichtexistierenden Wort "RAW". --92.76.113.129 14:15, 5. Mär. 2009 (CET)

Da du nicht darauf eingehst, was ich geschrieben habe, hier nochmal:

Der Artikel heißt "Rohdatenformat (Fotografie)" nicht "RAW-Format", was soll man da ändern? Außerdem ist RAW gebräuchlich und im ersten Satz steht bereits "RAW (engl. raw „roh“)". Wie sollte man auf die Idee einer Abkürzung kommen?

Anders gesagt: RAW ist kein Fehler. Du schreibst: "Ein aus Großbuchstaben bestehendes Wort ist ein Kunstwort, das sich aus den Anfangsbuchstaben anderer Wörter zusammensetzt." Das ist sehr häufig so, aber generell: nein, siehe JPEG (im Sinne von J... P... E... G...), MMIX, AND-Gatter, (EL*KE) oder dieser Artikel. Warum soll also RAW falsch und Raw richtig sein? --Euku:^⇄ 15:30, 5. Mär. 2009 (CET)

Es ist doch ganz einfach: JPEG steht ausgeschrieben für Joint Photographics Expert Group und ist damit eine Abkürzung, MMIX steht für die römische Zahl 2009, wobei MIX die römische Zahl 1009 ist - eine kleine Spielerei den Computer "MIX 1009" und den nächsten "MMIX 2009" zu nennen - und selbst MIXAL steht für "MIX Assembler Language" (soweit konnte ich im englischen Wiki recherchieren), das AND-Gatter heißt so weil es um die logischen Operator AND geht und man nicht überall das korrespondierende math. Sonderzeichen schreiben kann, (EL*KE) ist die eigene, wilde mit Sonderzeichen verschönerte Schreibweise einer Band und damit ganz außen vor. Deine Beispiele sind alles tatsächliche Abkürzungen oder treffen aus anderen Gründen nicht zu. Raw ist aber keine Abkürzung (R.A.W. = ??), kein Eigenname, sondern einfach das englische, bereits voll ausgeschriebene Wort für roh. Und weil es hier überall so geschrieben wird als sei es eine Abkürzung, sollte Jemand dieses Missverständnis beheben. Vielleicht kann es Jemand noch besser erklären? --Saski 16:26, 5. Mär. 2009 (CET)

Ok, die Beispiele taugen nicht, sind aber davon unabhängig, was ich eigentlich sagen will: Wenn beide Schreibweisen im Umlauf sind (was hier der Fall ist), dann sollte nichts von "irrtümlicherweiser Schreibweise" geschrieben werden. Man sagt auch nicht, dass iPhone, iMac, eBay etc. falsch geschrieben sei. Das ist WP:TF. Du hast sogar einen Domainnamen (http://openraw.org/) korrigiert. Wenn du die Seite besuchst, findest du überwiegend die Schreibweise RAW, aber nur dreimal Raw. Deine Änderung von http://www.fotocommunity.de/info/RAW-Konverter -> http://www.fotocommunity.de/info/Raw-Konverter bewirkte sogar, dass der Link ungültig wurde. Ebenso bei [1]! Spätestens da sollte doch einem auffallen, dass (man nicht per "Suchen & Alle Vorkommen ersetzen"-Änderungen durchführt und) beide Schreibweisen "korrekt" sind! Der Duden hilft hier nicht weiter. Siehe auch Wortschatzlexikon der Universität Leipzig der auf Vorlage:Falschschreibung (auch wenn es kein Fall von Falschschreibung ist) empfohlen wird. Weitere Links zu beiden Schreibweisen kann ich mir wohl sparen? --Euku:^⇄ 18:32, 5. Mär. 2009 (CET)

Einmal zur Abwechslung ein wirklich zutreffender Vergleich: Raw verhält sich zu RAW wie iPod zu iPOD (auch verbreitet, leider). Aber ich denke mit dem jetzigen Artikel sind wir uns einig, danke :) Sorry dass beim Bearbeiten etwas kaputt ging. Bitte reparieren falls du noch weitere Fehler findest... --Saski 19:14, 5. Mär. 2009 (CET)

Wäre es nicht angebrachter, Raw in raw umzuändern ? Das ist ja ein Format ähnlich doc (gerne auch DOC, aber Doc ist unsinn da MS->DOS), noch dazu ein Adjektiv, daher finde ich Raw extrem denglisch. Sowas kann man wahrscheinlich nur in der deutschen wiki finden. [2] Btw. Cannon nennt es auch RAW. --Andy386 16:59, 22. Nov. 2009 (CET)

Hab mal etwas drauf geachtet, es scheint nur Adobe "Raw" zu schreiben, die meisten anderen nennen es RAW. Was war da wohl zu erst da ? --Andy386 19:09, 8. Dez. 2009 (CET)

Das Gebilde "RAW/Raw" ist irreführend, weil es durch die Schreibweise suggeriert, es wäre ein einziger Begriffsname aus zwei Bruchstücken. Erst bei weiterem Lesen kommen vage Hinweise darauf, dass es sich um zwei Namen handelt, die zusammengekletscht wurden. Macht vor und hinter den Schrägstrich einen Leerraum, oder besser statt seiner ein "oder" (da die Beziehung der beiden "raws" nicht unmittelbar geklärt wird), damit dieser Schandfleck verschwindet. 149.225.76.84 19:33, 19. Apr. 2010 (CEST)

so besser? --Andy386 12:44, 10. Mai 2010 (CEST)

äpfel mit birnen

...der mit sicherheit wichtigste aspekt bei einem vergleich "RAW vs. JPEG" ist doch die webfähigkeit des ersteren bildformats: ein .jpg-bild kann ohne zwischenschritte jederzeit vom pc, notebook oder handy aus ins internet hochgeladen werden. ausser bei .gif und .png bei keinem anderen format derzeit möglich. erklärt auch sonnenklar die bis heute andauernde dominanz des .jp(e)g in den modellreihen der hardware - der marktanteil professioneller fotografie ist dagegen winzig. bei der ausführlichkeit des artikels und der tatsache, daß der/die hauptautoren selbst aus den aufgezählten "nachteilen" am ende dann meist "vorteile" machten ;)) gehe ich mal von einer art WP:IK aus... wollte man vielleicht der bevorzugung des TIFF-formates durch die wiki-developer etwas entgegenstellen? das könnte ich zwar einerseits verstehen, aber andererseits kann man solch ein lemma nicht enzyklopädisch anbieten, ohne auch nur ein einziges mal begriffe wie 'html', 'internet' o.ä. zu erwähnen. gruß, --ulli purwin _fragen? 16:32, 16. Apr. 2010 (CEST)

Ich glaub nicht an die Verschwörungstheorie mit wiki*, aber kannst du das schön forumulieren und einbauen? Dann könnte man gleich die ganzen "zerredeten" Nachteile in eine Kategorie wie Historie packen... --Andy386 10:17, 19. Apr. 2010 (CEST)

Raw und jpg sind zwei völlig verschiedene Paar Schuhe. Weshalb der "wichtigste Aspekt" die Webtauglichkeit sein soll, ist mir völlig unklar. Das einzige, was "sonnenklar" ist, ist die Tatsache, das jpg verlustbehaftet komprimiert, auf Speichermedien und beim Datentransfer deshalb weniger Resourcen frißt. Wie man auf die Idee kommen kann, von einer Bevorzugung von TIFF gegenüber Raw zu sprechen, ist ebenfalls völlig unklar. Raw ist kein Bildformat, das in irgendeiner Weise dafür gedacht oder auch nur geeignet wäre, Bilder zur direkten Darstellung zu erstellen. Einklich ist es überhaupt kein "Bildformat", sondern gewissermaßen ein verschlüsselter Datensatz, der erst durch geeignete Bearbeitung, gemeinhin und analog zur Silberfotografie gerne auch "Raw-Entwicklung" genannt, zu einem Bild wird. Von daher ist die ganze Vergleicherei, die über rein technische Aspekte und Möglichkeiten hinausgeht, sowieso Quark. "Nachteil: Raw kann man nicht im Webbrowser ansehen." - ja und? Eine Excel-Tabelle kann ich auch nicht direkt im Webbrowser ansehen. -- smial 13:48, 19. Apr. 2010 (CEST)

Äh, smial, hast du den Artikel, besonders bzgl. Vor & Nachteile mal gelesen? Ulli p. hat doch tiff nicht mit RAW verglichen... (welche Kamera spuckt schon RAWs aus?) - Die Webtauglichkeit von jpeg ist das einzige, was man als RAW-Nachteil anführen kann. Und das hat nix mit den tiff-Bildern in der wiki zu tun - der Artikel ist schon viel älter als solche Vorhaben--178.24.153.145 14:39, 19. Apr. 2010 (CEST)

Ja, leider. Soviel Redundanz, POV und weiteres Herumgerede findet man vermutlich nur in sehr wenigen anderen technisch orientierten Artikeln. -- smial 15:29, 19. Apr. 2010 (CEST)

oben müsste stehen: "welche Kamera spuckt schon TIFFs aus?" :::: Meine Änderung (war nicht angemeldet) mit Nachteilen in der Vergangenheit war ja auch nicht genehm... Das ist so krass Herumgeredet, weil keiner sich traut, die "Nachteile", die keine mehr sind, rauszunehmen. Stattdessen wird dass im Laufe der Jahre kleingeredet. --Andy386 12:04, 20. Apr. 2010 (CEST)

...sorry, tut mir echt leid, mit dem beitrag jemandem zu nahe getreten zu sein:

• ich hatte mit dem TIFF-format immer wieder im zusammenhang mit kunstdrucken zu tun: in den 90ern verlangten das die druckereien fast alle. heute wird immer häufiger nach dem RAW-format verlangt - und TIFF gilt vielen bereits als veraltet. naheliegender wäre daher für mich eher ein vergleich zwischen diesen beiden formaten, statt zwischen JPEG und RAW.
• btw: welche kamera spuckt schon TIFF aus? die testberichterstatter finden hier Digitalkamera im Preisvergleich - insgesamt 26 preiswerte Digitalkameras mit Dateiformat TIFF , davon 12 mit Tests (Stand 15.04.2010).
• dagegen RAW: Digitalkamera im Preisvergleich - insgesamt 418 preiswerte Digitalkameras mit Dateiformat RAW , davon 139 mit Tests (Stand 20.04.2010).
• ...und genau deshalb möge man es mir verzeihen, daß mir angesichts dieses verhältnisses der nach draussen gegebene auftrag im wiki-projekt ein wenig gegen den zeitgeist läuft. gehört jedoch zugegeben nich hierhin...
• den umstand der webfähigkeit von JPEGs halte ich nach wie vor für entwicklungs-maßgeblich. habe das beispiel mit excel allerdings nich ganz verstanden - da wären wir nun schon bei "äpfel mit frikadellen" ;) ! wobei zumindest der IE kein problem mit der darstellung im browser hat - auf ein TIFF-plugin bin ich allerdings noch nie gestossen...

lg, --ulli purwin _fragen? 23:23, 20. Apr. 2010 (CEST)

Neuordnung

Ich hab mal wieder was zu meckern...

• Nachbearbeitung

"Besonders an den Rändern kommt es dabei zu Problemen" Ist das irgendwie belegbar? Du meinst nur einen 1-pixel-breiten Rand, oder? Vielleicht könnte man dass noch hinzufügen... "in 16 Bit oder Fließkomma" das passt nicht. Es gibt Integer und Fließkomma, genau so wie es 12, 16, ... breite Verarbeitung/Speicherung gibt.

• Dateigrösse

das liest sich so, als wäre ein RAW-Bild 50MB gross "Selbst auf sehr großen Speichermedien können [..] oft nur wenige hundert Bilder" (=> 16GB, 300 Bilder) Meine 350D braucht ca. 8MB für ein RAW und 4 für ein JPEG in bester Auflösung... bei ner 16GB-Karte zeigt der Zähler 999 an :D --Andy386 00:32, 9. Mai 2010 (CEST)

Die 16bit sind natürlich Integer gemeint, ich ändere das noch. Die Erklärung zu den Rändern findet sich auf Dave Coffins Seite. Bei meiner 500D sind die Rohbilder 4770x3178 und die JPEGs 4752x3168 groß. Bei anderen Kameras können die Unterschiede kleiner oder größer sein. Die Dateigröße der RAWs ist im Durchschnitt ca. 24MB und geht bis zu 30MB (ist stark ISO- und Motiv-abhängig), auf der D3x sind es über 40MB. Die JPEGs hingegen sind ca. 4 bis 6MB — ist ein großer Unterschied. Selbst auf einer 32GB Karte bekomme ich also durchaus weniger als 1000 Bilder unter… --nachbarnebenan 02:42, 9. Mai 2010 (CEST)

JPG mit 4-6MB bei einer 15 MPixelkamera zeugen aber von einer deftigen Datenkompression. Für welche Kompressions/Qualitätseinstellung gilt das? Meine olle *istDs hat schon Dateien mit 3-5 MB produziert bei "bester" JPG-Qualität. Pentax scheint sich bei der k-x mit 12 MPixeln auch für RAW (PEF-Format) ein (verlustfreies) Kompressionsverfahren ausgedacht zu haben - die Dateien sind meist um die 11-14 MB groß, selten mal unter 10. Im DNG-Format sind die drastisch größer. Knuffigerweise hatte auch die *istDs schon RAW-Dateigrößen um die 10 MB - bei nur 6 MPixeln Auflösung. Und ebenso knuffigerweise kommt es in seltenen Fällen vor, daß sehr detailreiche JPG der k-x etwa genauso groß wie die zugrundeliegenden PEF sind. Bei der *istDs sind entwickelte RAW übrigens 3008x2000 pxel groß, JPG direkt aus der Kamera 3000x2000px. Da gibt es die "probleme" nur in einer Richtung? -- smial 04:50, 9. Mai 2010 (CEST)

Der Unterschied der Bildgröße hängt von der Kamera ab, das JPEG kann sogar größer sein, wenn z.B. die Objektivkorrektur aktiviert ist. Das JPEG war nur ein Testbild, das ich mal gemacht hatte — ich fotografiere nicht in JPEG. Einzustellen ist da nicht viel, es ist mit "Large Fine" (15MPx) entstanden. Wenn ich JPEGs brauche, z.B. um eine schnelle Übersicht eines Verzeichnisses zu bekommen und dann mit Gwenview darin zu löschen, benutze ich die mit dcraw -e extrahierten Thumbnails. Die sind nur ca. 1 bis 1.5MB groß (bei voller Auflösung) und auch ok. Alles andere mache ich nur vom RAW mit PNG als Endformat. Die DNG sind ca. ⅙ kleiner als die CR2, im Durchschnitt 19MB, konvertiert mit dem dngconverter von KDE, der originale von Adobe bekommt sie angeblich noch kleiner. Es hängt aber von den Einstellungen ab, z.B. ob und welches Vorschaubild und ob man linearisieren (Bayer-interpolieren) und komprimieren lässt. Mit den Standardeinstellungen werden sie größer.-- nachbarnebenan 13:44, 9. Mai 2010 (CEST)

Irgendwie komisch, dass die JPEGs deiner 500D und D3x so gross sind wie die meiner 350D - da wird wohl sehr viel glattgebügelt... Dass die RAWs bei doppelter Auflösung ca. drei mal so groß werden, verwundert mich auch... Hat Canon da am Kompressionsalgorithmus eingespart?

Dave Coffin spricht nur von Einsparungen am Rand, er meint hier bestimmt, da es ja um Bayer geht, nur 1..3 Pixel. --Andy386 12:31, 10. Mai 2010 (CEST)

Die JPEG sind ganz schön begradigt, stimmt. Sehr manchmal aus wie aus einer P&S. Und Canon hat wohl die Kompression der CR2 geändert — aber wie genau weiß wohl nur Dave Coffin. Die RAWs meiner 450D früher waren z.B. schon nahezu genauso groß, trotz niedrigerer Auflösung. Aber wenn ich die Histogramme in UFraw ansehe, schneidet die 500D in den Schatten und Spitzen etwas besser ab, kann sein, dass da weniger geclippt wird.
Der Randverlust hängt von der kamerainternen Interpolation ab. Manche Verfahren wie VNG oder AHD benutzen einen Macroblock von 16x16 Pixeln für die Interpolation, d.h. an jedem Rand können bis zu 15 Pixel fehlen. Theoretisch sogar noch mehr. --nachbarnebenan 17:29, 18. Mai 2010 (CEST)

Okay, durch die höhere Dynamik muss auch mehr gespeichert werden... haben die 450- und 500D-Wandler dieselbe Bitbreite?
wenn die Sache mit dem "dicken" Rand mit Verfahren belegt werden kann, ist ja alles okay. --Andy386 14:47, 24. Mai 2010 (CEST)

Zur Dateigröße: Das sollte man wohl unter Berücksichtigung der zeitgenössischen Speichermöglichkeiten einer Kamera sehen. Als die 350D aktuell war, gab es meines Wissens noch keine 16-GB-Karten. Andererseits sind die Speicherkarten in den letzten Jahren schneller gewachsen als die üblichen RAW-Dateigrößen, und man ist dank verlustfreier Komprimierung teilweise auch nicht mehr auf unkomprimierte RAWs angewiesen. Dieser Punkt ist also, wenn auch nicht völlig hinfällig geworden, so doch in seiner Bedeutung erheblich abgewertet worden. MBxd1 17:39, 9. Mai 2010 (CEST)

Das stimmt natürlich, andererseits sind die großen Speicherkarten noch immer extrem teuer, eine 32GB SDHC kostet beinahe das 5-fache einer schnellen 16GB. Und die 350D benutzt die robusteren CF, da sind die Preise noch höher, eine 32GB kostet fast 400€.-- nachbarnebenan 18:00, 9. Mai 2010 (CEST)

Wo kaufst Du denn? Ich finde Preise um 150 Euro. Für eine 350D wäre das aber in aller Regel krass überdimensioniert. MBxd1 18:26, 9. Mai 2010 (CEST)

Ok, ist schon einige Zeit her, als ich nach CF Preisen geschaut habe. Im Moment liegen 32GB Sandisk aber immer noch bei knapp 300€, die SDHC kosten nur die Hälfte.-- nachbarnebenan 19:34, 9. Mai 2010 (CEST)

Meine o.g. CF-Karte hat 30 Euro gekostet... und bei obiger Rechnung mit 300 komme ich auf eine Dateigrösse von 50MB - das 350D-Beispiel diente nur der Illustration... --Andy386 12:31, 10. Mai 2010 (CEST)

Der Preis hängt sehr stark von der Qualität und Geschwindigkeit ab, besonders bei den größeren Karten. Ich habe hier eine 32GB CF Sandisk 90MB zum Vergleich angesetzt, also nicht gerade Spitze aber gute Qualität. Die übersteht auch mal "unsachgemäßes" Handling… --17:29, 18. Mai 2010 (CEST)nachbarnebenan

Low-End

Warum gefiel meine Anmerkung "Die Interpolationen und Rauschunterdrückungsalgorithmen, die in der Kamera ablaufen sind jedoch auch auf selbigen ausreichend schnell." nicht? Es liest sich so, als wäre ein Low-End-System nicht zur RAW-Bearbeitung in der Lage. MMn weckt es einen falschen Eindruck. Ich bearbeite meine Fotos u.a. auf einem 1,5GHz/1GB-Laptop - und abgesehen von extremen Entrauschungen läuft alles glatt - wenn auch langsamer wie beim DIGIC, aber das steht ja schon oben drin. --Andy386 14:39, 24. Mai 2010 (CEST)

Das ist kein LowEnd-System in diesem Sinne. Gemeint sind z.b. Kamera-Handys, die interne Nachbearbeitung anbieten, zum Teil sogar mit Curves. Bei JPEG ist das durchaus vernünftig machbar, aber um auf einem vergleichbar nur 200MHz schnellen und mit 64 oder vielleicht 128MB ausgestatteten Embedded-System die 3 oder 4 Megapixel großen Bilder als RAW zügig nachbearbeiten zu können, reicht es nicht.-- nachbarnebenan 21:19, 24. Mai 2010 (CEST)

Tut mir leid, aber ich habe mit LowEnd Rechner um 1Ghz gemeint. Siehe hier: http://de.wikipedia.org/w/index.php?title=Rohdatenformat_%28Fotografie%29&action=historysubmit&diff=68710720&oldid=68707675 --Andy386 22:12, 27. Mai 2010 (CEST)

siehe weiter hier: http://de.wikipedia.org/wiki/AMD_Athlon_II_(Mobil)

gibts auch für GraKas: http://de.wikipedia.org/wiki/Nvidia-Geforce-8-Serie

oder etwas älter hier: http://de.wikipedia.org/wiki/NE2000 --Andy386 22:12, 27. Mai 2010 (CEST)

Dateierweiterungen

Nikon Raw: *.nef verlinkt auf NEF = Notarztfahrzeug Olympus Raw: *.orf verlinkt auf ORF = Österreichischer Rundfunk

Das ist ja wohl nicht im Sinn des Erfinders oder? Ich kenn mich mit der Wikifizierung nicht so gut aus, aber irgendjemand sollte das vielleicht ändern... (nicht signierter Beitrag von 81.223.103.21 (Diskussion | Beiträge) 23:54, 15. Okt. 2004 (CEST))

Ganz meine Meinung.

Auch in der Druckersprache werden RAW-Dateien (z.B. PCL oder PS) auch verwendet. Der Begriff betrifft KEINESFALLS nur Digitalfotografie! (nicht signierter Beitrag von 62.2.203.219 (Diskussion | Beiträge) 14:48, 28. Mär. 2007 (CEST))

Korrigierbarkeit bei TIFF

Gemeint sind, wie im Beitrag unmittelbar davor steht, "Bayer-Sensor-Interpolation, Tonwertkorrektur, Schärfung, Rauschfilterung und Weißabgleich". Ist man etwa mit der Bayer-Interpolation der Kamera, mit der Rauschfilterung oder dem Weißabgleich nicht zufrieden, kann man bei TIFF zwar nachbearbeiten, es stehen aber nicht mehr die originalen Rohdaten zur Verfügung. Kann man bei einer Tonwertkorrektur, vom Roh-material (RAW) ausgehend, die Kurve neu bestimmen, erhält man deutlich bessere Ergebnisse, als wenn man die bereits gerundeten Werte des TIFF-Bildes nachträglich umrechnet.

Gemeint war nicht der bei JPEG auftretende Qualitätsverlust durch erneutes komprimieren sondern einfach die Farbraumbeschränkung von 8 Bit (256 Stufen) pro Farbkanal gegenüber 10/12/14/16 Bit bei Raw. Das emm 13:10, 22. Aug 2005 (CEST)

Einleitung

Ich habe mal die Einleitung etwas neutraler Formuliert. Denn zunächst sind Rohdaten eben Rohdaten, und das viele Hersteller sich noch Sperren, DNG oder ein anderes, offenes Format zu nutzenn ist zwar richtig, aber betrifft eben nicht alle. Zumal ich glaube, Hasselblad hat Modelle, die nur im DNG Format speichern, sagt zumindest diese Seite: http://www.barrypearson.co.uk/articles/dng/products.htm#converters Gruß Linum 15:16, 8. Jan. 2011 (CET)

Link zum Sigma Unternehmen führt zum Sigma Zeichen

Link zum Sigma Unternehmen führt zum Sigma Zeichen (nicht signierter Beitrag von 92.77.99.15 (Diskussion) 22:19, 23. Jan. 2012 (CET))

Danke für den Hinweis. Ich habe es korrigiert. --Fomafix 09:12, 24. Jan. 2012 (CET)

Softwaresammlung entfernen?

Bei der Einführung des Formats war Software, die das Rohdatenformat unterstützt selten und daher eine Linkliste gerechtfertigt, heute darf das wohl als Standard gelten. Die Übeinstimmung mit Grafiksoftware zeigt das auch. --Meinungsfreiheit (Diskussion) 10:42, 26. Mär. 2012 (CEST)

Das ist nicht überflüssig, könnte sich aber für eine Auslagerung und detailliertere Aufarbeitung eignen. Es ist jedenfalls nicht zweckmäßig, dass Capture NX (das ausschließlich Nikon-Formate verarbeiten kann) kommentarlos zwischen den kamerasystemunabhängigen Programmen steht. Weglassen kann man es auch nicht, weil es zum Umgang mit NEF-Dateien Standard ist und die anderen Programme größtenteils faktisch völlig unbedeutend hierfür sind. Das sollte aber dargestellt werden, und die anderen systemspezifischen Programme sollten ergänzt werden. Ich stelle mir da sowas wie eine Tabelle vor, die einerseits die Programme und andererseits die RAW-Formate nennt und die Kompatibilitäten mit Kreuzchen markiert. Ich habe es jetzt nicht geprüft, es würde mich aber wundern, wenn alle Programme mit Exoten-RAW-Formaten wie z. B. denen von Contax oder Epson klarkämen. Ein Problem dabei ist aber, dass viele Programme zwar RAW-Formate lesen können, aber in bestimmten Fällen Ergebnisse liefern, die in Anbetracht der im Prinzip erreichbaren Qualität nicht akzeptabel sind. Das trifft z. B. auf das Fuji-Format zu, wenn R- und S-Pixel verwendet werden. MBxd1 (Diskussion) 20:49, 26. Mär. 2012 (CEST)

Ich stimme prinzipiell der Idee mit der Tabelle zu, eine Differenzierung würde das Problem lösen und insbesondere für die exotischen Formate wäre das auch äußerst nützlich. Allerdings ist das schwer zu recherchieren und zu pflegen, da die Angaben der Hersteller manchmal nicht vollständig/korrekt sind, z.B. weil die Formate in unterschiedlichen Versionsnummern vorliegen.--Meinungsfreiheit (Diskussion) 11:06, 28. Mär. 2012 (CEST)

Abschnitt 3.3 -"TIFF", Bittiefe

Ich halte es für wünschenswert, bei dem Vergleich von JPEG- und TIFF-Bildern mit einheitlichen Maßeinheiten zu arbeiten: soweit in der Beschreibung ( Stand 15.6.2012 ) von 8 bis maximal 16 Bit geschrieben wird, ist damit der Wert eines einzelnen Farbkanals gemeint ( und dies ist - gerade auch im Vergleich mit s/w- oder CMYK-Bildern - die einzig sinnvolle Maßeinheit ). Bei der Erwähnung von 24- und 48-Bit-TIFFs hat der Autor aber leider die Werte aller drei Farbkanäle eines RGB-Bilds addiert - und das ist unschön, weil für den Laien verwirrend. Es sollte besser auch hier von 8- bzw. 16-Bit-TIFFs die Rede sein. -- Wolfgang Leese-- (nicht signierter Beitrag von 217.186.105.176 (Diskussion) 19:17, 15. Jun. 2012 (CEST))

Ich habe den Versuch unternommen den Absatz verständlicher zu schreiben.--Meinungsfreiheit (Diskussion) 22:40, 15. Jun. 2012 (CEST)

JPEG ist nicht unbedingt "verlustbehaftet"

Viele Kameras sind durchaus in der Lage, mit Kompression und ohne Verlust durch diese zu speichern.

Durch den Artikel wird der Eindruck erweckt, dass Problem wäre die JPEG-Kompression und nicht das "XRAY" der Bildkanäle; grade in der Gegenüberstellung "gutes Raw" vs. "böses JPEG"...

JPEG bedeutet nicht gleich Verlust; das ist so einfach nicht richtig: Die Kompressionslevel sind einstellbar - bis hin zur "verlustfreien Komprimierung"...

!! Das Zusammenmischen der Bildkanäle zu einer Ebene ist das "Problem". !!

Im gleichen Atemzug sollte aber einmal auf das "24-Bit-Problem" Auge hingewiesen werden: Was hilft das schönste Zerlegen von Bildkanälen, wenn das Auge nur eine bestimmte Tiefe von Farben wahrnehmen kann - und auch nur eine begrenzte Anzahl gleichzeitig...? Wo ohnehin die Anzahl der Pixel immer höher wird und somit eine Aneinanderreihung der ggf. aus einem verlustfreien 1-Ebenen-JPEG extrahierten Bildkanäle möglich wird - wenn auch vielleicht dabei ein paar Pixel beim "zusammenstauchen" des Urbildes verloren gehen...

Wer seine Bilder im RAW noch groß nacharbeiten muss, sollte vielleicht überlegen, ob er im Highend-Kamera-Zoo dem Affen hinter der Scheibe die Kamera für das Selbstportrait geben sollte, anstatt mit "Dauerauslöser" selbst weiter zu photographieren...: Ein gutes Bild benötigt einfach Zeit - und garnicht so viel Technik, Megapixel, RAW-Format und Bildbearbeitungssoftware. Das scheint derweil vergessen zu werden.... (nicht signierter Beitrag von 139.7.19.1 (Diskussion) 16:16, 14. Nov. 2014 (CET))

Ich verstehe nicht so recht, was genau du im Artikel geändert sehen möchtest. In der Gegenüberstellung sehe ich kein "gutes Raw" vs. "böses JPEG" sondern lediglich die jeweiligen Vor- und Nachteile beispielhaft dargestellt. Beide Formate haben ihre Berechtigung, ich bin froh, dass ich bei Bedarf das Passende auswählen kann und finde das hier angemessen dargestellt. Grüße --losch (Diskussion) 19:47, 14. Nov. 2014 (CET)

Hallo Losch. Das Problem was ich sehe ist derweil das Gejammer auf dem sehr hohem Niveau - und das die meisten Anwender der Meinung sind, sie brauchen nun unbedingt Kameras mit "RAW"-Format, weil sie sonst keine Photos nachbearbeiten könn(t)en - und auf dem heimischen PC könne man das gespeicherte Bildformat nicht mehr ändern... JPEG wird derweil - grade auf Grund solcher Artikel - als "böse" und als "grundsätzlich qualititativ untragbar verlustig" angesehen. Gleiches gilt für die Pixel- und Farbmanie... Das Zusammenspiel von Sensor, Anordnung der Zellen, Lichtempfindlichkeit, Verschlusszeit vs. Belichtungszeit, etc. pp. wird aktuell nicht mehr wirklich wahrgenommen, wie man auch am Folgekommentar gut entnehmen kann. Wer sich z.B. mal die Zeit nimmt einigen Mythen mal selbst nachzugehen wird sehen, dass bei den meisten Bildern in JPEG100% vs. PNG bei der Dekodierung in 1:1:3/x:y:3 tatsächlich keine wirklichen erkennbaren Unterschiede mehr zu finden sind - sogar bei recht "alten" Kameras mit <&eq; 4 MPixeln, wo es wirklich drauf ankäme.... Es sei klargestellt, dass es hier grundsätzlich um die Übertragung des Ursprungbildes von der Kamera auf das Bearbeitunsgerät ankommt - ich rede hier nicht über das 1000-fache der Bildmutter in einem Format wie JPEG auf dem PC beim Nachbearbeiten - schon traurig genug, wenn man das muss.... Ich mag ganz audrücklich und nachhaltig bezweifeln, das ein "normaler Mensch" - und selbst die meisten Profis - einen Unterschied in der Bildqualität bei der Übertragung des Mutterbildes von der Kamera auf den PC bemerken können. Viele Grüße --139.7.19.1 10:27, 17. Nov. 2014 (CET)

Ich sehe im Artikel weder Gejammer noch Anwendermeinungen. Ich sehe auch nicht, daß die meisten Anwender glauben, ohne Raw-Format keine Fotos bearbeiten oder Bildformate ändern zu können. JPG ist nicht böse, prinzipiell aber stets verlustig. Trotzdem mache ich meine geringfügigen Nachbearbeitungen im JPG-Format, weil man die Unterschiede zwischen 8-Bit-TIFF und 8-Bit-JPG tatsächlich kaum herausfinden kann, sofern man stets mit der höchstmöglichen JPG-Qualitätseinstellung (zwischen-)speichert.
Tatsächlich spricht die IP offensichtlich und ausschließlich Probleme und Unterschiede an, die mit der JPG-Kompression zusammenhängen. Das ist aber nicht das eigentliche Problem mit JPG, das liegt in der geringen Farbtiefe. Das Auge ist nämlich durchaus in der Lage, mehr als 256 Helligkeitsstufen zu unterscheiden. Schon geringfügige Änderungen/Nachbearbeitungen im Bereich Helligkeit/Kontrast/Farbsättigung führen bei 8-Bit-JPGs sehr schnell zu häßlichem Banding. Und genau deshalb erledigt man das bei kritischen Motiven bei voller Farbtiefe im Raw-Entwickler oder aber in 16-bittigen Formaten, z.B. Tiff, wo man noch sämtliche Informationen aus dem Bildsensor hat, der auch bei älteren und einfacheren Kameras meist mehr als 10 Bit liefert, bei besseren Modellen sogar 14. Die IP hat latürnich insofern recht, als die meisten JPGs, die aus einer halbwegs aktuellen Kamera herauspurzeln, problemlos so wie sie sind benutzbar sind. Der Artikel behauptet aber auch gar nichts anderes, wenn ich nicht etwas übersehen habe. Von daher wiederhole ich die Frage meiner Vorredner: Was soll im Artikel anders dargestellt werden? -- Smial (Diskussion) 12:12, 17. Nov. 2014 (CET)

Hallo Smial. Persönlich würde ich mich sehr freuen, wenn man die Unterschiede der Speicherformate in ihrer Entstehung (also beim durch die Kamera fallen) mehr erläutert und neben einander stellen würde. Ein sehr schöner Artikel aus dem Jahr 2009 ist z.B. hier zu finden: http://kwerfeldein.de/2009/07/02/ueber-die-farbtiefe/ . Vielleicht sollte man zumindest einen internen Link auf http://de.wikipedia.org/wiki/Farbtiefe_%28Computergrafik%29 setzen und z.B. das Bild daraus entsprechend erweitert als Gegenüberstellung erweitern. Dann wird vielleicht in der Relation etwas deutlicher, was dem Anwender nun 8, 10, 12 - oder gar 16 .. n Bit pro Farbkanal beim Sensor, beim Verarbeiten und beim Speichern bzw. als Farbraum wo und wie für sein teuer bezahltes Knips-Vergnügen wirklich bringen. ...z.B. beim Print... So schön ja RAW auch ist - aber da genau da ist er dann wieder - der Verlust, den man doch vorher unter allen Umständen für teuer Geld doch vermeiden wollte. Persönlich empfinde ich das wie mit einem Rennwagen im Stau zur Arbeit fahren... Klar kann man das - das Auto sieht sicher toll aus, ist sicherlich recht komfortabel und man wird viele Bewunderer haben - aber sicherlich auch eine Menge Menschen, die in Ihrem 2CV oder Ihrem Käfer an einem vorbei rollen und auch pünktlich zur Arbeit kommen - Mit einer komfortablen Standheizung, einem guten Tuner und einem Lächeln... Mir geht es darum den Kunden im Autohaus doch vielleicht fair darauf hinzuweisen, dass er z.B. an der A3 wohnt und seinen Tacho nie über die 100 km/h sehen wird - wenn überhaupt... Viele Grüße. --139.7.19.1 16:05, 17. Nov. 2014 (CET)

Alles schön und gut, aber genau das würde erfordern, eine Menge Wertungen einzubauen - und genau das möchte zumindest ich auf keinen Fall befürworten. Gegen den Einbau zusätzlicher Aspekte und Informationen wird sicher niemand etwas haben, gegen eine "Neutralisierung" vorhandener, wertender Formulierungen wohl auch nicht. Muß nur jemand machen, nach Möglichkeit nach Absprache hier auf der Diskussionsseite. -- Smial (Diskussion) 16:52, 17. Nov. 2014 (CET)

Hallo IP, einerseits stimme ich nach nochmals kritischer Betrachtung zu, dass hier, wo das Raw-Format Inhalt des Artikels sein soll, in zu großem Umfang negative Aspekte des JPEG betont werden. Andererseits bestätigen auch die Ausführungen des von dir verlinkten Blogs die Überlegenheit des Raw-Formates bei erforderlichen Bearbeitungen. Ansonsten bin ich ganz der Meinung von Smial, dass hier ganz vorsichtig eher Wertungen abzubauen sind, als weitere zu installieren. Grüße --losch (Diskussion) 20:26, 17. Nov. 2014 (CET)

Vielleicht sollten wir klarer herausarbeiten, dass es nicht in erster Linie um JPG als Dateiformat geht, sondern um den Unterschied zwischen den Originaldaten (dem Negativ) und einem bereits von einer Bildbearbeitungssoftware (ob nun in oder außerhalb der Kamera) entwickeltes Bild (den Abzug) geht. // Martin K. (Diskussion) 20:42, 17. Nov. 2014 (CET)

(mehrfacher BK) @139.7.19.1: Aus Deinen Beiträgen lese ich heraus, dass Du JPEG scheinbar für das natürlichere (weil ältere?) Format für digitale Photos hälst und RAWs genauso wie die digitale Nachbearbeitung eher als überflüssigen Schnickschnack ansiehst, der nur vom wesentlichen der Photographie ablenkt?! Deshalb möchte ich Dir folgendes zu bedenken geben:

• Eigentlich sind RAW und JPG überhaupt nicht vergleichbar. Während ein RAW das Orginal der vom Sensor aufgezeichneten Daten enthält und damit am ehsten mit einem analogen Negativ zu vergleichen ist, zeigt ein JPG nur eine der möglichen Entwicklungen dieser Daten und damit das, was in der analogen Zeit ein Papierabzug war. Logisch dass sich in der weiteren Bearbeitung aus ersterem mehr rausholen lässt als aus letzterem.
• Das erklärt auch, warum viele digitale Konsumerkameras die RAW-Daten (die bei einer digitalen Aufnahmen zumindest temporär immer entstehen) direkt intern entwickelten und nur JPGs speichern. Genauso wenig wie zu analog Zeiten jeder ein komplettes Photolabor zuhause hatte, will sich heute jeder mit den Feinhaiten der RAW-Entwicklung auseinandersetzen oder besitzt auch nur die dafür nötige Software.
• Wenn man mit dem Bild 1:1 so zufrieden ist, wie es von der Bildbearbeitungssoftware der Kamera als JPG aufbereitet wurde, spricht mMn auch überhaupt nichts dagegen, das JPG zu verwenden. Sobald man das Photo aber irgendwie nachbearbeiten will – und dunnerweise zeigt sich die Notwendigkeit dafür meistens erst, wenn es zu spät ist – bietet einem das RAW einfach deutlich mehr Möglichkeiten, wie z.B.:
  • Die höheren Farbtiefe, die sich vorallem beim Aufhellen oder Abwedeln unter- bzw. überbelichter Bereiche bemerkbar macht, weil es dank der zusätzlichen Bildinformationen das Entstehen unerwünschter Effekte wie Posterisation, Bildrauschen und das Sichtbarwerden von JPG-Fragmenten minimiert.
  • Die unkomprimierten Originalfarbinformationen, die auch nachträglich eine saubere Korrektur des Weißabgleichs ermöglichen. Wer hingegen mal versucht hat ein JPG von Kunst- auf Tageslicht (oder andersherum) zu korrigieren, weiß dass da nur ziemlich farbverfälschte Ergebnisse rauskommen.
  • Kontrast und Gradation lassen sich passgenau für das einzelne Motiv einstellen ohne dabei in Gefahr zu laufen entweder zeimlich flaue Bilder zu produzieren oder ständig zu helle und zu dunkle Bereiche abzuschneiden.
• Auch wenn es mit einem RAW grundsätzlich einfacher ist, fehlerhafte Einstellungen nachträglich zu korrigieren, ist es doch nicht nur ein Ersatz für die nötige Sorgfald bei der Erstellung der Aufnahme selbst – und erst recht kein Grund zu schludern. Vieles lässt sich zum Zeitpunkt der Aufnahmen nämlich überhaupt nicht so kontrollieren, wie es später bei der RAW-Entwicklung möglich ist:
  • Nicht nur bei Konzerten sondern auch im normalen Alltag sind wir (dank aufziehender Wolken, Schatten und wechselnder Leuchtmittel) mit einem ständigen Wechsel der Farbtemperatur konfrontiert, den bisher kein automatischer Weißabgleich zufriedenstellend kompensieren kann. Auf Basis von RAW-Daten kann man das im Nachhinein ohne irgendeinen Verlust korrigieren, bei einem JPG ist das nur mit deutlichen Qualitätseinbußen bei der Farbdarstellung möglich.
  • Auch wenn man bei höherwertigen Kameras verschieden Kontrast und Schärfeprofile einstellen kann, lässt sich kaum sicher stellen, dass z.B. bei Aufnahmen in der harten Mittagssonne und solchem im Schatten immer die jeweils passende Gradation gewählt wird.
  • Und Abbildungsfehler (wie z.B. Chromatische Aberrationen oder Verzeichnungen), die insbesondere bei günstigeren Objektiven häuffig auftreten, lassen sich natürlich auf Basis der Originaldaten auch wesentlich besser korrigieren.

Ja, ein RAW ist ein Profiwerkzeug – aber eines von dem auch der interessierter Amateur profitieren kann.

Nein, eine Kamera, die nur JPGs speichert ist deshalb nicht automatisch Mist – sie bietet einem nur deutlich weniger Korrekturmöglichkeiten.

Und ja, in Zukunft werden immer mehr Kameras RAWs abspeichern können – es gibt ja bereits erste Smartphones die das anbieten. // Martin K. (Diskussion) 20:37, 17. Nov. 2014 (CET)

(BK) Solche Vorteil/Nachteil-Darstellungen entsprechen eigentlich nicht ganz dem Standard. Solche tabellarischen Darstellungen arten ganz gern in einen Schlagabtausch 1:1 - auch wenn die Realität nicht unbedingt 1:1 ist. Es wäre eigentlich wichtiger, die unterschiedliche Eignung für verschiedene Zwecke darzustellen.

Es stimmt schon, dass dieser Artikel nicht dazu sein soll, auf JPEG rumzuhacken. Allerdings ist das nun mal in der Regel die einzige Alternative zum Rohformat. Kameras, die direkt TIFF speichern können, kann man inzwischen mit der Lupe suchen (ja, es gibt sie wirklich noch). Sachlich korrekt wäre es, Rohformate gegen JPEG und TIFF zu stellen. Es wäre nur inzwischen nicht mehr so wirklich praxisbezogen.

Der Artikel enthält auch überzogene Kritik am Rohdatenformat. Das liegt ganz offensichtlich an der in der Wikipedia weit verbreiteten generellen Ablehnung proprietärer Dateiformate. Neutral ist es allerdings nicht, Panik wegen vielleicht irgendwann mal nicht lesbar sein könnenden Rohformaten zu verbreiten. Sachlicher wäre es, das reale Ausmaß darzustellen. Es gibt nämlich durchaus exotische Formate, die von vielen Programmen nicht mehr unterstützt werden. Aber in diesem Punkt ist zuviel Ideologie im Artikel.

Das Thema der kamerainternen Rohdatenbearbeitung vor Speicherung ist von derart vielen Verschwörungstheorien geprägt, dass die hier anzutreffende Beleglage den Abschnitt nicht rechtfertigt. Das ist geeignet, den Eindruck entstehen zu lassen, dass Rohformate auch nur leicht bessere JPEGs wären, und das stimmt nun mal nicht. MBxd1 (Diskussion) 20:50, 17. Nov. 2014 (CET)

---

@139.7.19.1: Abgesehen davon, dass ich wie Losch nicht verstehe, welche Informationen Du konkret an diesem Artikel ändern willst (wir stellen hier ja keine Meinungen dar, sondern Sachinformationen), scheinen bei Dir einige Missverständnisse bzw. Fehleinschätzungen vorzuliegen, die ich natürlich gernw aufkläre:

• Das Abspeichern eines Bildes im JPEG-Format ist tatsächlich immer verlustbehaft - auch dann, wenn man die Qualität auf 100% stellt. Das liegt an verschiedenen Komprimierungsalgorithmen die unweigerlich immer zu einer Veränderung und damit einem Verlust an Bildinformationen führen. Im JPEG Standard auch definierte verlustfreie Kompressionsarten wurden nie im heute etablierten Format umgestetzt. Stattdessen hat man irgendwann das PNG-Format ins Leben gerufen.

• Bitte Vorsicht mit einer Prozentangabe bei der JPEG-Qualität - erstens ist es keine, zweitens handhaben das unterschiedliche Programme unterschiedlich. --Michael Schumacher (Diskussion) 15:19, 17. Nov. 2014 (CET)

• Du wirfst offensichtlich Farbkanäle und Ebenen durcheinander. Während es ersteres aber sowohl bei RAWs (RGB-Daten der Orginalaufnahme) als auch bei JPEGs (intern YCbCr) gibt, ist letzteres so bei keinem der Formate sondern nur bei Bildbearbeitungs Formaten (wie z.B. psd) vorhanden.
• Die Farbwahrnehmung des Menschlichen Auges ist dann doch etwas komplizierter und nicht allein mit den drei 8Bit-Kanälen eines JPGs zu vergleichen. Insbesondere was Kontraste angeht, kann unser Auge viel mehr Hellligkeitsdifferenz wahrnehmen als dort abspeicherbar ist. Und da ist es schon hilfreich, wenn die Farbtiefe und der Dynamikumfang eines RAWs so hoch ist, dass ein heller Himmel nicht einfach weiß erscheint, sondern in der Enrwicklung wieder seine in der Realität vorhanden blaue Farbe zurückgeholt werden kann.
• Und Deine Schmähkritik gegen jegliche Art der digitalen Nachbearbeitung ist eigentlich schon allein deshalb albern, weil diese beim Abspeichern im JPG-Format ja nicht entfällt, sondern bereits in der Kamera durchgeführt wird. Ein JPG ist keinesfalls das orginalere oder unverfälschter Bild (im Gegenteil) sondern nur eines, was von der autoamtischen Bildverarbeitung in der Kamera aus genau denselben RAW-Daten errechnet wurde. Wie gut das Ergebnis ist, hängt von den dort verwendeten Algorithmen und Einstellungen ab, ist aber in keinster Weise so bewusst vom Photographen steuerbar wie eine vernünftige RAW-Entwicklung außerhalb der Kamera.

// Martin K. (Diskussion) 09:15, 15. Nov. 2014 (CET)

Vorschlag zur Verbesserung

Nach Lektüre der obigen Diskussion überlege ich,wie man den Artikel verbessern kann. Das Themas „RAW vs. JPEG“ ist ja ausgiebig erörtert worden und m. E. sind die Datenformate hinreichend in der Tabelle im Abschnitt Rohdatenformat (Fotografie)#Gegenüberstellung gewürdigt. Es fehlt aber dem Artikel an einer pragmatischen Darstellung, die dem Fotografen verdeutlicht, welche Auswirkungen die Kamera-Einstellungen zum Datenformat zur Folge haben. Ich habe Zweifel, ob alle Benutzerhandbücher der Kameras das hinreichend darstellen. Ohne auf POVs und Wertungen zu verfallen, sollte es möglich sein, die Vor- und Nachteile der zwei oder drei verschiedenen Kamera-Einstellungen sachlich darzustellen. Das könnte ungefähr so aussehen:

Einstellung	Vorteile	Nachteile
RAW	* das Höchstmaß an Bildinformationen bleibt erhalten * vielfältige Nachbearbeitungen sind in einem Raw-Konverter möglich und können Unzulänglichkeiten bei der Aufnahme kompensieren (z. B. Belichtung, Weißabgleich) * zukünftige Raw-Konverter können ggf. durch optimierte Algorithmen bessere Ergebnisse liefern	* größerer Speicherbedarf als JPEG * unmittelbare Verwendung (z. B. Drucken) ggf. eingeschränkt * der Umgang mit einem Raw-Konverter muss bekannt sein * ggf. muss in einen Raw-Konverter investiert werden
JPEG	* geringster Speicherbedarf * Motivprogramme erleichtern dem Einsteiger den Umgang mit der Kamera * unmittelbare Verwendung möglich	* Bildinformationen gehen durch die eingeschränkte Farbtiefe und die Kompression verloren * daher Einschränkungen bei der Nachbearbeitung
RAW & JPEG	* Vorteile von RAW * unmittelbare Verwendung möglich * „Backup“: bei technischen Problemen der Speicherung eines Formats kann die Datei im anderen Format noch verwendbar sein	* größter Speicherbedarf

Man kann über die Inhalte der Tabelle noch streiten, ich habe sie nur adhoc befüllt. Wichtiger ist mir im Moment ein Meinungsbild: Macht eine solche Tabelle im Artikel Sinn? --Hasenläufer (Diskussion) 20:51, 17. Nov. 2014 (CET)

Sowas würde mMn eher unter Digitalkamera#Dateiformat passen. // Martin K. (Diskussion) 20:57, 17. Nov. 2014 (CET)

Könnte Sinn machen. --Hasenläufer (Diskussion) 21:12, 17. Nov. 2014 (CET)

(BK) Mal abgesehen davon, dass man zum Nutzen von Motivprogrammen sehr unterschiedlicher Meinung sein kann (man lernt mit ihnen nichts dazu), ist das keine Frage des Datenformats, sondern in erster Linie der Steuerung von Belichtung und Autofokus. MBxd1 (Diskussion) 20:57, 17. Nov. 2014 (CET)

Der Nutzen von Motivprogrammen sollte hier nicht Gegenstand sein. Es wird seine Gründe haben, dass die Kamera-Hersteller im Marktsegment der Einsteiger-DSLRS Motivprogramme anbieten. Mir persönlich sind Anwender solcher Kameras bekannt, die sich weigern, den Unterschied zwischen Zeit- und Blendenautomatik zu verstehen. Mit Raw kann ich solchen Leuten erst gar nicht um die Ecke kommen. Nebenbei: Was heißt „(BK)“? --Hasenläufer (Diskussion) 21:08, 17. Nov. 2014 (CET)

(BK) == Bearbeitungskonflikt // Martin K. (Diskussion) 21:32, 17. Nov. 2014 (CET)

(BK) Ja, die Motivprogramme gibt es. Sie sind aber auf alle verfügbaren Dateiformate anwendbar. Bei JPEG fehlen lediglich die JPEG-spezfischen Einstellungen. Die sind aber nicht das entscheidende.

"BK" heißt "Bearbeitungskonflikt" und zeigt an, dass in einer Diskussion die Beiträge verschiedener Benutzer gleichzeitig erstellt wurden und deshalb nicht unbedingt auf den unmittelbar darüberstehenden Beitrag Bezug genommen wird. MBxd1 (Diskussion) 21:35, 17. Nov. 2014 (CET)

@MBxd1: Danke für die Aufklärung! („Bearbeitungskonflikt“ ist mir geläufig, „BK“ war mir neu.) Zum Thema: Verstehe ich Dich richtig, dass man das Thema „Motivprogramme“ aus der Tabelle herausnehmen sollte? Wie gesagt, es war ein Adhoc-Entwurf und bei etwas Nachdenken meine ich auch, dass das Thema „Motivprogramme“ in der Tabelle wohl deplatziert ist. --Hasenläufer (Diskussion) 21:44, 17. Nov. 2014 (CET)

„Nebenkriegsschauplatz BK“: Welchen Sinn macht es, „BK“ einem Beitrag voranzustellen? Bearbeitungskonflikte kommen vor, sind zu lösen und können gelöst werden. Der semantische Gehalt des Vermerks „BK“ erschließt sich mir bislang nicht. --Hasenläufer (Diskussion) 07:06, 18. Nov. 2014 (CET)

Wenn wir nun doch über den Inhalt der Tabelle diskutieren: Bei der Formulierung „unmittelbare Verwendung (z. B. Drucken) ggf. eingeschränkt“ bin ich mir unsicher, denn damit habe ich keine Erfahrungen. Mir ist es bislang selten in den Sinn gekommen, direkt aus der Kamera zu drucken, E-Mails zu versenden oder Fotos in eine Community hochzuladen. Es mag aber Benutzer geben, die so etwas schätzen. Daher wäre ich für sachdienliche Hinweise dankbar. Insbesondere bin ich mir unsicher, ob ein Nutzer, der in der Kamera Raw als Speicherformat festgelegt hat, auf diese Features verzichten muss. Auch ist mir unklar, ob man das allgemein formulieren kann. --Hasenläufer (Diskussion) 21:56, 17. Nov. 2014 (CET)

Wir haben nun schon eine ausführliche Tabelle im Artikel, und nun soll noch eine Kurzfassung hinzukommen? Eigentlich soll es Tabellen dieser Art generell in Artikeln überhaupt nicht geben. Das würde ich nun nicht ganz so verkniffen sehen, aber noch weiter ausdehnen muss man es nicht.

Die separate Aufführung der Kombination von Rohformat und JEPG bringt wenig, denn mit Ausnahme des weiter vergrößerten Speicherbedarfs vereinigt man ja nur die Nachteile Vorteile korr. MBxd1 (Diskussion) 08:08, 18. Nov. 2014 (CET). In diesem Zusammenhang sollte aber erwähnt werden, dass es Kameras gibt, die zwar sowohl Rohformat als auch JPEG haben, aber beides zusammen nur eingeschränkt. So kann z. B. bei der Nikon D40 bei der Kombination nur die einfachste JPEG-Qualität ausgewählt werden. Wer JPEGs vollwertiger Qualität aus der Kamera haben will, muss auf Rohdaten verzichten. Das ist wohl auch nicht durch die Datenverarbeitung bedingt, sondern eine gewollte Funktionsbeschneidung. MBxd1 (Diskussion) 22:58, 17. Nov. 2014 (CET)

Funktionsbeschränkungen per Software machen die Premium-Hersteller ja gern, um bei den meist langsamer drehenden teureren Modellen noch Kaufanreize zu haben. -- Smial (Diskussion) 23:04, 17. Nov. 2014 (CET)

Ich habe gerade mal nachgesehen, beim aktuellen Nachnachnachfolger (D3300) ist es nicht mehr so, da ist bei Kombination zwangsläufig die beste JPEG-Qualität enthalten, und die stärkeren Kompressionen sind nicht verfügbar. Das ist dann keine echte Funktionsbeschneidung mehr. Ich weiß jetzt aber auch nicht im einzelnen, welche Kamera nun was genau ermöglicht. MBxd1 (Diskussion) 23:16, 17. Nov. 2014 (CET)

@MBxd1: Wir haben nun schon eine ausführliche Tabelle im Artikel, und nun soll noch eine Kurzfassung hinzukommen? – Nein, das war nicht die Idee. Die vorgeschlagene Tabelle soll keine Kurzfassung der bestehenden Tabelle sein, weder semantisch noch formal. Die bestehende Tabelle stellt die Formate Raw und JPEG gegenüber, das ist gut und richtig so; sie ist hilfreich für diejenigen, die sich tiefer mit der Materie befassen. Meine Idee ist, das Thema aus einer anderen Sichtweise zu betrachten: Eine pragmatische Hilfestellung für den Anwender, der sich unsicher ist, welche Einstellungen er zum Thema in der Kamera vornimmt – ohne, dass er sich zu sehr mit den Details des Pro & Kontras bzgl. Raw vs. JPEG befassen möchte oder die Beschäftigung mit dem Thema bzw. die Entscheidung dazu vertagt. Ich denke, Martin K.s Bemerkung macht Sinn: Die „neue“ Tabelle könnte eher in Digitalkamera#Dateiformat sinnvoll sein. (Persönliche Erfahrung: Ich erinnere mich noch gut an das Jahr 2002: Seinerzeit hatte ich mir erstmals eine Kamera zugelegt, die Raw unterstützt. Ich war damals unsicher, ob ich dieses Feature nutzen sollte oder nicht. Es gab damals gute Gründe dafür und dagegen. Ähnlich mag es heute noch anderen Anwendern gehen, die mit dem Thema Raw noch nicht hinreichend vertraut sind.) Mein Grundgedanke ist, das ein Artikel wie Digitalkamera eher Einsteiger adressiert, hingegen ein Artikel wie dieser (Rohdatenformat (Fotografie)) eher diejenigen adressiert, die sich tiefer mit einem Aspekt der Materie Digitalfotografie beschäftigen.

Eigentlich soll es Tabellen dieser Art generell in Artikeln überhaupt nicht geben. Das verstehe ich nicht. @MBxd1: Kannst Du bitte etwas illustrieren, was Du damit meinst? Ich bin weder Erkenntnistheoretiker, noch Didakt. Aber nach meinem Verständnis ist ein Bild, eine Grafik oder eine Tabelle in vielen Fällen kognitiv besser zu erfassen als ein Fließtext.

Die separate Aufführung der Kombination von Rohformat und JEPG bringt wenig, .... Hier mag ein Missverständnis vorliegen. Ich habe mich daran orientiert, was die Kamera-Hersteller an Optionen anbieten. Es macht keinen Sinn, das zu werten, denn es ist Fakt. Es gibt Kameras mit 1, 2 oder 3 Optionen: (1) nur JPEG, (2) JPEG oder Raw und (3) JPEG, Raw oder JPEG+Raw. Alle 3 Optionen haben eine „Daseinsberechtigung“ – jedoch erschließt sich das nicht für jeden Anwender. Daher mein Vorschlag, diese 3 Optionen mit ihren Vor- und Nachteilen darzustellen. Ich vermute, dass insbesondere die 3. Option (JPEG, Raw oder JPEG+Raw) Anlass für Irritationen geben mag. „JPEG+Raw“ mag z. B. in folgenden Szenarien Sinn machen: Ich fotografiere eine Party oder einen entlegenen Volksstamm. Als Equipment habe ich eine Kamera und einen dieser Kompaktdrucker dabei, die Abzüge im Postkartenformat erlauben – jedoch keinen PC. Vor Ort kann ich anhand der von der Kamera produzierten JPEGs unmittelbar kleine Prints erstellen und an Anwesende verschenken. Im Nachgang habe ich aber die Möglichkeit, die Bilder anhand der Raw-Dateien am PC weiter aufzubereiten. Möglicherweise gibt es weitere Szenarien, welche die Option „JPEG+Raw“ rechtfertigen. Wie auch immer – die Kamera-Hersteller werden gute Gründe haben, warum sie die Option „JPEG+Raw“ anbieten. Die von mir geschilderten Szenarien sind eine Art der Interpretation, vielleicht gibt es weitere Aspekte?

Auf konkrete Details der vorherigen Diskussion (Eigenheiten bestimmter Kamera-Modelle) würde ich verzichten wollen oder ggf. in Fußnoten erwähnen.

... denn mit Ausnahme des weiter vergrößerten Speicherbedarfs vereinigt man ja nur die Nachteile. Das kann ich nicht nachvollziehen. Ich sehe in „JPEG+Raw“ eher eine Kombination beider Vorteile.

Gruß, --Hasenläufer (Diskussion) 06:21, 18. Nov. 2014 (CET)

Das war ein Schreibfehler. Ich habe es korrigiert. MBxd1 (Diskussion) 08:08, 18. Nov. 2014 (CET)

Zur Darstellung: In der Wikipedia gilt eine generelle Präferenz für Fließtext. Stichpunktlisten von textartigen Inhalten sind nicht gewollt. Diese Regel muss man nicht mögen, sie erscheint mir auch nicht durchgängig sinnvoll, man sollte sie aber zumindest als grobe Leitlinie akzeptieren.

Der Artikel sollte schon benennen, wozu das Rohformat gut ist. Eigentlich kann das hier aber nur eine Darstellung von Vorteilen und der Vorbedingungen und Anwendungsbereiche (ich will es nicht unbedingt "Nachteile" nennen) sein. Einige vermeintliche Probleme werden hier etwas zu heftig ausgewalzt, aber das erwähnte ich weiter oben schon. Insofern kann eine Unterbringung in einem allgemeineren Artikel sinnvoll sein. Das muss nicht unbedingt Digitalkamera sein, ich würde da eher an Digitalfotografie denken. Die beiden Artikel haben eh ein (latentes) Redundanzproblem. Ich habe jetzt aber nicht noch mal nachgesehen, was da eh schon drinsteht.

Zu RAW und JPG: Das ist eine Speicheroption, kein eigenständiges Format. Man erzeugt bei jedem Bild zwei Dateien, die dann jeweils die Eigenschaften ihres Formats haben. Der Speicherplatzbedarf ergibt sich aus der Summe der beiden Dateigrößen, und man hat sowohl ein fertiges Bild zur Verfügung als auch die Option späterer umfangreicher Nachbearbeitung. Als Tatsache ist das erwähnenswert, aber einen eigenen Punkt in einer Gegenüberstellung braucht man dafür nicht. Genaugenommen ist sowieso in jeder Rohdatei ein JPEG mit drin, weil das zur Vorschau gebraucht wird. Kameras und mobile Zwischenspeicher greifen immer nur auf dieses JPEG zurück und verarbeiten nicht die tatsächliche Rohdatei zur Anzeige. Einzige Ausnahme dürfte das .raw-Format von Contax sein, bei dem es auch keine Vorschau gibt. Die Option der Speicherung in beiden Formaten endet natürlich auch bei den wenigen Kameras, die kein JPEG erzeugen können. Das trifft auf die älteren Sigmas zu, und bei Kodak war da auch mal was. MBxd1 (Diskussion) 08:39, 18. Nov. 2014 (CET)

TIFF

@MBxd1: Du schreibst, „Kameras, die direkt TIFF speichern können, kann man inzwischen mit der Lupe suchen (ja, es gibt sie wirklich noch).“ Rein interessehalber: Welche Modelle sind Dir bekannt, die in TIFF speichern? Ich vermute, es sind Raritäten, die heute nicht mehr am Markt sind. Dennoch interessiert es mich, welche Kameras bzw. Hersteller auf dieses Format setzten. Gruß, --Hasenläufer (Diskussion) 07:22, 18. Nov. 2014 (CET)

Nein, so exotisch sind sie dann auch wieder nicht. Die einstellige Reihe von Nikon kann es bis heute, und die Reihe darunter (D800, Df) auch. Bei Canon gibts kein TIFF mehr. Es mag noch ein paar weitere Exoten im Mittelformat geben. MBxd1 (Diskussion) 08:15, 18. Nov. 2014 (CET)

Die Ricoh Caplio GX bot wahlweise TIFF an. War damit aber eigentlich nur langsamer und speicherplatzfressender als bei JPGs. -- Smial (Diskussion) 12:37, 19. Nov. 2014 (CET)

Beschriftung der Tabelle

@Meyer-Konstanz: Du hast gerade meinen Vorschlag für die Umbenennung des Tabellenkopfes mit dem Kommentar „Gemeint ist eben nicht ein aus einer Rohdatei entwickeltes Bild, sondern ein von der Kamera erzeugtes.“ rückgängig gemacht. Dem möchte ich widersprechen:

• Zum Einen liegt jedes in einer Kamera (= auf dem Sensor) entstandene Bild (zumindest temporär) immer erst als Rohdaten vor. Der Unterschied ist nun, dass dies Rohdaten einmal bereits in der Kamera in ein JPG umgewandelt werden, während das bei einem RAW erst nachträglich auserhalb der Kamera und mit erweiterten Einflussmöglichkeiten geschiet. Ein JPG ist daher immer einen „Entwickeltes Bild“.

• Zum Anderen sollte es (wie oben schon besprochen) in dieser Tabelle nicht um die Besonderheiten des JPEG-Formats gehen – damit würde man nämlich (wie oben schon dargestellt Äpfel mit Birnen vergleichen und etliche Missverständnisse provozieren. Wichtig ist stattdessen der Unterschied zwischen vorentwickelten 8bit-Daten und Kamera-Rohdaten mit der vollen Auflösung und Farbtiefe des Sensors. Und dafür ist es weitgehend irrelevant ob die vorentwickelten Daten als JPG oder TIFF oder sonst wie gespeichert wird.

Wenn Dir ein anderer Spaltentitel einfällt, der diese Aufgabe erfüllt, kannst Du ihn gerne vorschlagen. Ansonsten würde ich dort wieder Entwickeltes Bild (z.B. JPEG) bzw. Vorentwickeltes Bild (z.B. JPG) hinschreiben wollen... // Martin K. (Diskussion) 10:42, 19. Nov. 2014 (CET)

Vielleicht sollte man dann in der Überschrift des Abschnitts deutlicher machen, WAS da gegenübergestellt wird. Ich fände es sinnvoll, wenn die Tabelle den Anwendern bei der Entscheidung helfen würde, die Kamera nun Rohdaten oder JPEG-Bilder erzeugen zu lassen. Und m.E. leistet die Tabelle das derzeit auch, nur sollte die Überschrift dann auch deutlich machen, was da vergleichen wird. --Karsten Meyer-Konstanz (D) 11:10, 19. Nov. 2014 (CET)

Nachtrag: Vorher sah es so aus, als behandle die rechte Spalte JPEG-Bilder, die ich auf dem PC aus Rohdaten entwickle. Das fand ich nicht ideal. --Karsten Meyer-Konstanz (D) 11:22, 19. Nov. 2014 (CET)

@Martin Kraft:: Danke für deine Änderung, jetzt ist es eindeutig. --Karsten Meyer-Konstanz (D) 12:28, 19. Nov. 2014 (CET)

Danke, so gefällt mir das auch viel besser! --losch (Diskussion) 13:07, 19. Nov. 2014 (CET)

Tabelle "Gegenüberstellung", Zeile "Nachbearbeitung" bei JPEG

Da steht u.a.:
Bedingt durch den Kompromiss, den die Hersteller eingehen müssen, um die Interpolation schnell genug und doch mit akzeptabler Qualität durchzuführen, kommt es an den Rändern zu Problemen bzw. Abschneideeffekten, weswegen nachträglich konvertierte Rohbilder unter Umständen größere Bilddimensionen aufweisen.

Ich ahne, was damit gemeint sein könnte, finde den Text aber wenig aufschlussreich. Die Fußnote führt zur FAQ von dcraw, was auch nicht weiter hilft. Evtl. ist ja folgendes damit gemeint:
Vor allem bei modernen (Super-) Weitwinkelobjektiven finden für die JPEG-Ausgabe starke Korrekturen der Verzeichnung in der Kamera statt. Wenn man nun eine Rohdatei eines solchen Fotos in einen Konverter lädt, der dies nicht auch (evtl. automatisch) tut, dann erhält man ein teils erheblich größeres, wenn auch stark verzeichnetes Bild.
Die Frage wäre, ob man dieses doch recht spezielle "Problem" an dieser Stelle darstellen muss. Es gehört eigentlich nicht zu "Nachbearbeitung" und wäre eigentlich auch eher eine (positive) Eigenschaft der Rohdaten, weil man u.U. tatsächlich mehr an Größe aus diesen herausholen kann. Ich habe dies in Foren an Hand des 7-14-mm-Objektivs von Panasonic gesehen.

Nebenbei: Der im Text angegebene Kompromiss existiert natürlich. Ich meine aber, er ist bei der heutigen Kameratechnik nahezu vernachlässgibar. (Moderne Kameras können heute Panoramen stitchen und HDRs errechnen.)--Karsten Meyer-Konstanz (D) 12:43, 19. Nov. 2014 (CET)

Kritik an der derzeitigen Fassung vom 14.12.14

ich geh mal von oben nach unten durch...

♦ "Folgende Gründe kommen in Betracht:" für Nichtoffenlegungen von Firmen - das klingt irgendwie nach POV.

zudem, welche (Nichtspiegellosen) System nutzt Phasen-AF auf dem Sensor und speichert das mit im Bild ab?

♦ "so dass auch Nikon-unabhängige Software in der Lage ist, die Daten zu entschlüsseln." D.h. Adobe ist Canonabhängig? Pixmantech war Canonabhängig? aha.

♦ mir kommt es so vor, als würde STÄNDIG wird darauf rumgeritten, dass man mit neuerer Software in die Lage versetzt werden könnte, alte Formate nicht mehr lesen zu können. Vielleicht kann man dass in einem einzigen Punkt zusammenfassen? (s. auch meine Korrekturen) Mal als Denkanstoß: Wer hat schon versucht, eine FAT(16)-formatierte 3,5"-DD mit Win7 zu lesen? Wer hat noch FAT16-formatierte Datenträger?

♦ "Somit bleiben auch durch Verwendung von CHDK Gewährleistung und Garantie des Gerätes erhalten." Dafür hätte ich zu gern mal eine Quelle. --Andy386 (Diskussion) 20:04, 14. Dez. 2014 (CET)

zu 1.: Der ganze Abschnitt ist ziemlich dürftig belegt.

zu 2.: Nikon-unabhängig heißt unabhängig von Nikon, mehr nicht. Nikon hat seinen hauseigenen RAW-Konverter deutlich ernster genommen als die meisten anderen Firmen, indem sie das kostenpflichtige Nikon Capture angeboten haben. Dem stand Software von anderen Firmen gegenüber, eben den Nikon-unabhängigen. Zeitweise hat Nikon den Weißabgleich verschlüsselt und damit der Software anderer Hersteller unzugänglich gemacht. All das passierte zu einer Zeit, als es zum guten Ton gehörte, auf Nikon rumzuhacken. Eigentlich ist es kaum mehr als eine (eh nur noch historische) Randbemerkung. Mit Canon hat das alles nichts zu tun.

zu 3.: Die Kritik an proprietären Formaten wird maßlos übertrieben. Das muss wohl was mit ideologischer Einseitigkeit der Wikipedia zu tun haben. Tatsächlich kritisch sind Rohdaten von Kameras, deren Hersteller den Kamerabau eingestellt haben (Contax, Epson und Kodak) oder die einen scharfen Einschnitt mit Software-Wechsel gemacht haben (Fuji). Deren Rohformate werden nur noch von herstellerunabhängiger Software unterstützt, und auch das nicht mehr von allen. Inwieweit Konica Minolta rohdatentechnisch von Sony adoptiert wurde, weiß ich nicht. Ansonsten hat es mal einen Versuch von Canon gegeben, die D30 nicht mehr zu unterstützen. Das haben sie dann aber aufgegeben. Komplett unter die Räder gekommen sein könnten die Dateien Canon D2000 und D6000, die das Rohdatenformat von Kodak verwenden, aber von deren Program nicht unterstützt werden, weil Canon keine Lizenzgebühren zahlen wollte. Ich weiß jetzt aber nicht, was Canon für dieses Kameras angeboten hat.

zu 4.: Es wird übereinstimmend so berichtet. Wirklich wichtig finde ich es aber nicht. MBxd1 (Diskussion) 20:50, 14. Dez. 2014 (CET)

Der Artikel ist generell etwas in die Jahre gekommen und sollte auch mal grundsätzlich überarbeitet werden. Dabei kann man dann auch auf einige ältere Informationen verzichten, die heute kaum noch eine Rolle spielen und das ganze etwas generischer aufbauen (schließlich geht es hier um die Rohdatenformate im allgemeinen und nicht um die konkreten Implementierungen der verschiedenen Herrsteller). Ergänzen könnte man dann das, wass im englischen Artikel unter File contents steht... // Martin K. (Diskussion) 22:27, 14. Dez. 2014 (CET)

Gimp nur unter Mac und Linux Rawkompatibel

Ich meine, eine kleine Unstimmigkeit entdeckt zu haben, es ist aber auch gut möglich, dass ich mich irre. Das Bildbearbeitungsprogramm Gimp wird als Raw-Fähiges Programm gelistet, was aber für Microsoft nicht zu stimmen scheint. Früher war es möglich UFRaw in Gimp als Plugin zu implementieren, seit der Version 0.18 ist das aber nur noch für Linux und Mac-OS möglich (siehe Wikipediaartikel zu UFRaw). Gimp selbst kann kein Raw, zumindest nicht unter Windows und die Formulierung lässt auf einen gegenteiligen Sachverhalt schließen, oder ist zumindest irreführend. Laut Gimp war geplant ab Version 2.8 Raw zu unterstützen, aber da wurde scheinbar nichts daraus, mit 2.9 soll sich das wohl ändern (aktuelle Version 2.8.14). Mit freundlichen Grüßen --2A02:8070:4180:4B00:C43B:248F:7805:130 20:00, 6. Jan. 2015 (CET)

Unterschiede

"Obwohl sich die grundlegenden Funktionsweisen der digitalen Bildsensoren verschiedener Hersteller und Modelle nicht wesentlich voneinander unterscheiden"

Das ist so nicht korrekt. Es gibt CMOS- und CCD-Sensoren, aber auch vollkommen, also grundlegend anders konstruierte Chips, wie etwa Foveon. Dazu kommt dann noch, dass die Metadaten nun wirklich komplett verschieden sind, sogar innerhalb des selben Herstellers, teilweise innerhalb einer Modellreihe. Außerdem versuchen alle Hersteller, die Kunden in ihren eigenen Workflow einzuschließen (Customer Lock-In).134.247.251.246 17:20, 25. Nov. 2015 (CET)

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)

Hexdump

Der Hexdump einer Raw-Datei – hier Canon 60D – zeigt, dass am Dateibeginn Metadaten zu den Bilddaten zugefügt sind.

Das Bild im Abschnitt „Verwendung“ illustriert weder die Verwendung noch das Lemma „Rohdatenformat“. Es illustriert allenfalls, dass im Header einer RAW-Datei Metadaten vorhanden sind. Erkennbar sind jedoch nur Kamera-Hersteller, -Modell, ein Datum und eine Uhrzeit – unstrukturiert. Dieser Hexdump hilft nicht zum Verständnis des Lemmas sondern führt allenfalls zu der Frage, was ein Hexdump ist. Daher sollte es ersatzlos entfernt werden. Oder habe ich einen Aspekt übersehen? --Hasenläufer 19:21, 24. Mai 2017 (CEST)

Kann weg. Besser wäre eine Infografik über die Verarbeitungsabläufe in einer Digitalkamera, aus der entnehmbar ist, an welcher Stelle das Raw-Format abgegriffen wird. --Smial (Diskussion)

Ist nun weg. Eine „Infografik über die Verarbeitungsabläufe in einer Digitalkamera, aus der entnehmbar ist, an welcher Stelle das Raw-Format abgegriffen wird“ ist bereits im Artikel: c:File:20141121 Rohdatenverarbeitung in Kamera sowie PC.jpg. --Hasenläufer 21:04, 24. Mai 2017 (CEST)

Das ist nicht das, was ich mir unter einer omatauglichen Infografik vorstelle, die benötigt ja mehr Text zur Erklärung, als wir im Artikel haben. Im Netz fand ich sowas. --Smial (Diskussion) 21:59, 24. Mai 2017 (CEST)

Verstehe, was Du meinst. Etwas in dieser Art würde ich auch begrüßen. --Hasenläufer 00:13, 25. 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)

Nachdem ich mir die beiden fraglichen Versionen einmal vergleichend zu Gemüte nahm, muß ich sagen, daß Arilous Bearbeitungen im Sinne einer Entschwurbelung in Teilen durchaus schon in die richtige Richtung gingen und diskussionswürdg sind. Freilich unterstütze ich die vorläufige Rücksetzung auf den vorherigen Zustand, da solche umfangreichen Kürzungen/Änderungen sicherlich zuvor besprochen werden sollten. Findet inzwischen ja unten statt. --Smial (Diskussion) 17:57, 24. Mai 2017 (CEST)

Auch ich habe grundsätzlich nichts gegen eine "Entschwurbelung". Aber bitte nicht im Sinne einer Umdeutung bestehender Begrifflichkeiten. // Martin K. (Diskussion) 18:22, 24. 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)

Der Begriff "entwickeln" ist hier wirklich nicht angebracht, obwohl er hier und dort für das Erzeugen eines Fotos aus Rohdaten verwendet wird. Das Entwickeln eines Films war ein unumkehrbarer Prozess, und hier geht es darum ein Bild aus den Rohdaten zu bekommen, die dabei aber (hoffentlich) nicht verändert werden. Und nebenbei: "RAW" ist keine Abkürzung. --Karsten Meyer-Konstanz (D) 11:38, 24. Mai 2017 (CEST)

Wobei der Unterschied doch lediglich in der Kopierbarkeit des Ausgangsmaterials liegt. Beim analogen Entwickeln wird das Ausgangsmaterial (also der belichtete aber nicht entwickelte Film) direkt bearbeitet und damit letztlich vernichtet. Beim digitalen Entwickeln werden nur die Informationen ausgelesen (aka "kopiert") und weiterbearbeitet, womit das Ursprungsmaterial erhalten bleibt.

Ich finde schon, dass es hier eine Analogie gibt - auch wenn die (wie alle anderen anderen Digital-Analog-Analogien auch) nicht 100% deckungsgleich ist. Der eigentliche Entwicklungsprozess ist jedenfalls wieder sehr ähnlich: Schließlich wird auch bei der Entwicklung eines Diafilms dessen Gradation und Farbigkeit endgültig festgelegt. // Martin K. (Diskussion) 12:07, 24. Mai 2017 (CEST)

Wie auch immer: In der aktuellen Literatur (Zeitschriften, Fachbücher, Software) werden diese Skeumorphistischen Begriffe "Rohdaten", "Digitales Negativ" und "Entwickeln" genauso verwendet wie im umseitigen Artikel. So ist nun mal die Beleglage. Und wir stellen die Realität in diesem Projekt so dar, wie sie ist, und nicht so, wie wir persönlich sie für stringent halten. // Martin K. (Diskussion) 12:14, 24. Mai 2017 (CEST)

+1 Außerdem spielt PNG in der Praxis keine Rolle. --M@rcela 14:23, 24. Mai 2017 (CEST)

TIFF, PNG, "keine Vorteile"

"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"

1. TIFF kann verlustfrei komprimieren und sogar 32 bit pro Farbkanal. Also (C+M+Y+K+Transparenz) = 5* 32bit pro Pixel.
2. Dass das "kaum Vorteile" brächte, ist mindestens genauso POV wie dass JPEGs kaum mehr nachbearbeitbar seien. Und der Vorwurf der "erheblich größeren Dateien" ist ja wohl ein Scherz! Wenn man verlustlose Kompression und hohe Bittiefe fordert, dann sind große Dateien eben die Folge. Wasch mich, aber mach mich nicht nass!

--arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

Raw-Vorteile und das liebe Geld

"Und abgesehen von wenigen teuren Profikameras"

Ja ja, die Kamera soll alles haben und können, aber kosten darf's natürlich nichts.

Und deswegen muss man natürlich Profi-Kritikpunkte (z.B. Nachberechnung chromatischer Aberration) den Fähigkeiten einer bestenfalls mittelpreisigen Consumer-Kamera ("können fast immer nur JPEG") gegenüberstellen.

Ehrlich wäre, bei komplexen Nachbearbeitungsansprüchen, dann auch von den besten, und ja, teuren, Profi-Kameras auszugehen.

--arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

Schritte zum "Entwickeln"

Schon der Artikel selbst sagt aus, dass all die Schritte zum "Entwickeln" eines Bildes mitunter bereits in die Raw-Daten eingerechnet werden, je nach Kameramodell. Dann kann man in einer allgemeinen Gegenüberstellung aber nicht mehr davon ausgehen, dass die Raw-Daten gänzlich unbehandelt sind. Damit werden viele Kritikpunkte zu "möglicherweise"/"in manchen Fällen", und liegen mitnichten immer vor.

Oder, siehe oben, wenn als Basis eine echte Profi-Kamera vorausgesetzt wird, bei der von unbehandelten Raw-Daten ausgegangen werden darf, dann muss man aber als Vergleich das verlustlos komprimierende TIFF heranziehen, mit 32 bit Farbtiefe pro Farbkanal. Und mit diesen Daten lässt sich noch hervorragend nachbearbeiten.

--arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

1. Welche Kamera speichert 32-bittige TIFFs, so daß man die Ergebnisse vergleichen könnte?
2. Mir ist nur von Nikon bekannt, daß die bei einigen Modellen anscheinend eine verlustbehaftete Kompression der Raw-Dateien (wahlweise) anbieten.
3. Die "eingerechneten" Entwicklungsschritte sind zumindest bei Pentax, und ich vermute, daß das bei allen anderen Anbietern exakt gleich gehandhabt wird, keineswegs in die Rawdateien "eingerechnet", sondern werden als "Vorschläge" an die Dateien angehängt, so daß die von geeigneten Rawentwicklern ausgewertet werden können. In "meinem" Pentax-Rawentwickler werden die Bilder dementsprechend zunächst mit den Vorgaben aus der Kamera, z.B. Einstellungen für Weißabgleich, Rauschunterdrückung, Linsenkorrekturen, Kontrast, Bildstile ("Landschaft", "Portrait", ...) angezeigt. Die kann man stumpf übernehmen oder mit den Reglern des Rawentwicklers feintunen, die kann man aber auch vollständig ignorieren. Ich gehe folglich davon aus, daß die eigentlichen Rawdaten abgesehen von verlustfreier Kompression (Ausnahme Nikon, siehe oben) sehr wohl gänzlich unbehandelt sind. Es ist klar, daß bei der Empfindlichkeitseinstellung in der Kamera /auch/ ein Ausleseverstärker aktiv ist und umgeschaltet wird, so daß der A/D-Wandler etwas Sinnvolles zu wandeln vorgesetzt bekommt, die Rawdaten also sicherlich nicht 1:1 die Zahl der vom Sensor eingefangenen Photonen repräsentieren. Aber das ist akademisch, denn auch jede kamerainterne Bildgebung und jedes beliebige Speicherformat hat dieselben Voraussetzungen. --Smial (Diskussion) 12:16, 20. Jun. 2017 (CEST)

"Entwickeln" belegen

Es genügt 1 Artikel mit dem Begriff, um belegen zu können, dass "er (auch) verwendet wird". Was eine extrem seltene Verwendung wäre.

Sieht man sich bei Google Scholar mal die Treffer zu "Bild entwickeln" an, ist es fast immer à la "aus den Nachrichten kann sich der Leser dann ein Bild entwickeln, was tatsächlich geschehen ist" o.ä.

Zu "Foto entwickeln" kommt fast nichts, und die wenigen hochwertigen Treffer sind prä-1980 aus Analogfotografie-Zeiten.

Bei Google direkt wird unter "Digitalfoto entwickeln" wohl weit überwiegend die Ausgabe auf Papier gemeint, und nicht die Raw-Konvertierung.

Mein Fazit: Abgesehen von der einen oder anderen Profi-Zeitschrift meint "Digitalbild entwickeln" in der Umgangssprache "drucken auf Fotopapier", und hat gar nichts mit "Konvertierung Raw- zu Standardformat" zu tun; allenfalls eingeschränkt mit "automatische Nachbearbeitung und -aufbereitung (direkt) vor dem Druck".

--arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

Nachbearbeitungsmöglichkeiten

"[..] Weißabgleich [..] bei einem RAW problemlos korrigieren; bei einem RGB-JPG führt das zu erheblichen Farbverfälschungen.", Helligkeitsdynamik, Rauschen, Chromatische Aberration

Wer auf solche Nachbearbeitungsfähigkeiten Wert legt, soll sich eine hochwertige Kamera zulegen. Die kann dann Tiff, und damit geht das alles problemlos.

Wer kein Geld für eine hochwertige Kamera auszugeben bereit ist, darf auch nicht darüber jammern, dass ihm keine hochwertigen Nachbearbeitungsmöglichkeiten bleiben.

Aber "Komplexe, hochwertige Nachbearbeitung" mit "Fähigkeiten einer billigen Consumer-Kamera" zu vergleichen, ist schlicht unseriös.

--arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

Welche Kamera kann denn TIF erzeugen, aber keine Rohdaten? Das kann es allenfalls in der Anfangszeit der Digitalfotografie gegeben haben, als die Rohdaten noch nicht zugänglich gemacht wurden. MBxd1 (Diskussion) 20:47, 20. Jun. 2017 (CEST)

Hochwertiges Standardformat '=' Raw

"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"

Tiff ist kein Raw. Somit ist deine Aussage einfach falsch. --arilou (Diskussion) 10:12, 20. Jun. 2017 (CEST)

TIF bietet ja auch nicht die Bearbeitungsmöglichkeiten eines Rohformats, weil die Interpolation der einfarbigen Pixel zu mehrfarbigen Pixeln dort bereits durchgeführt wurde. MBxd1 (Diskussion) 20:49, 20. Jun. 2017 (CEST)

Entwickeln wie zu Analogzeiten

Imo war zu Analogzeiten das "Entwickeln" etwas ganz anderes, als heute die "Raw- zu Standard-Format"-Wandlung. Wie du selbst sagst: "Schließlich wird auch bei der Entwicklung eines Diafilms dessen Gradation und Farbigkeit endgültig festgelegt." Und an dieser "endgültigen Festlegung" fehlt es eben gewaltig bei "Raw- zu Standardformat". Denn bei hochwertigem Zielformat bleibt sehr viel Spielraum für spätere umfangreiche Nachbearbeitungen. Natürlich nicht, wenn das einzige Zielformat, dass man sich denken kann, JPEG ist, stark in der Bittiefe beschränkt und verlustbehaftet komprimierend...

--arilou (Diskussion) 10:12, 20. Jun. 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)

Unabhängig davon existiert eine Möglichkeit, Bilder verlustfrei im JPG-Format zu speichern, nur wäre mir kein einziger Kamerahersteller bekannt, der die verwenden würde. --Smial (Diskussion) 12:41, 24. Mai 2017 (CEST)

Die "diskrete Kosinustransformation" macht allenfalls Rundungsfehler - vernachlässigbar.

Wie große Verluste die "Farbmodellumrechnung" ausmacht, weis ich nicht - müsst' ich mich erst schlau machen darüber.

"Unterabtastung Cb und Cr" kann JPEG auch mit 4:4:4, ohne Verlust (in diesem Schritt). Es ist aber unüblich, 4:4:4 zu verwenden - schließlich will man mit JPEG ja kleine Dateigrößen und dazu verlustbehaftete Kompression.

"Erheblicher" Verlust-Schritt ist die Quantisierung, die auch nur zu diesem Zweck durchgeführt wird. Es kann die Quantisierungsmatrix { 1 } gewählt werden, dann ist dieser Schritt absolut verlustlos.

Von den "4 verlustbehafteten Schritten" kann man die 2 wesentlichen ganz abschalten, 1 bewirkt fast keinen Verlust, 1 weis ich nicht.

--arilou (Diskussion) 11:18, 20. Jun. 2017 (CEST)

Welcher Kamerahersteller bietet eine solche Option an? Btw: Gerade die Umrechnung von Farbräumen beinhaltet grandiose Stolperfallen. Frag mal einen Drucker. --Smial (Diskussion) 12:26, 20. Jun. 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)

Ja, einige neuere Kameras scheinen nicht mehr die ganz "rohen" Daten des Sensors abzuspeichern. Das ist aber leider nirgends dokumentiert, weil die Hersteller das geheim halten wollen. Das sollte aber nicht verwechselt werden mit dem Speichern von Einstellungen der Kamera in diesen Daten. Wir müssen hier unbedingt unterscheiden zwischen einer berechneten Veränderung der Rohdaten und Werten, die neben den Rohdaten in der Datei gespeichert werden. Vermutlich jede Kamera speichert in den Rohdaten die Einstellungen ab, die für ein in der Kamera erzeugtes JPEG gelten würden - ob nun ein solches abgespeichert wird oder nicht (also vor allem der eingestellte Weißabgleich, neuerdings aber auch Daten zur Korrektur von Objektivfehlern). Das hat den Zweck, möglichst auf "Knopfdruck" in der mitgelieferten Software ein Bild zu bekommen, das dem JEPG möglichst gleich ist. (Und nebenbei enthalten die Rohdaten vermutlich immer auch ein kleines Vorschaubild im JPEG-Format, wie das ja selbst bei JPEG-Bildern aus der Kamera der Fall ist) --Karsten Meyer-Konstanz (D) 11:48, 24. Mai 2017 (CEST)

Die Beleglage zu "manipulierten" Rohdateien ist ziemlich dünn, da wird ganz gern mal was rumprobiert und aus Indizien ein Urteil abgeleitet. Das entspricht letztlich nicht immer wissenschaftlichen Ansprüchen. Zu den Vorschau-JPG: Die sind Standard. Was man auf dem Kameramonitor sieht, ist immer das Vorschau-JPG und nie aus den Rohdaten frisch erzeugt. Einzige mir bekannte Ausnahme war die Contax N Digital, die keine Vorschau-JPGs erzeugen konnte, womit man beim Fotografieren im Rohformat praktisch im Blindflug unterwegs war. MBxd1 (Diskussion) 20:56, 20. Jun. 2017 (CEST)

"oder eines aus einem RAW exportiert (was praktisch 0 Vorteile bringt)."

Im Artikel wird behauptet, jedes Standard-Format brächte erhebliche Nachteile gegenüber Raw.

Daraus, dass ein Standardformat "0 Vorteile" bringt, folgt aber mitnichten, dass es Nachteile brächte. Es kann zugleich auch "0 Nachteile" bedeuten.

--arilou (Diskussion) 10:22, 20. Jun. 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)

Man bearbeitet keine RAW-Dateien. Sie dienen nur als Ausgangsbasis. --M@rcela 13:21, 24. Mai 2017 (CEST)

1. Auch die Raw-Daten können bereits nachbearbeitet sein.
2. Dass ein Raw-Konverter die Bearbeitungsschritte speichert und erst am Ende alles rechnet, ist nicht gleichbedeutend mit "verlustfrei". Es mindert die Informationsverluste von Zwischenberechnungen, aber für das Endergebnis gilt genauso "jede Bildbearbeitung bedeutet einen Verlust an Information" (des Ergebnisses im Vgl. zum Urzustand).

--arilou (Diskussion) 10:28, 20. Jun. 2017 (CEST)

Nein. RAW bleibt immer im Original erhalten. --M@rcela 10:46, 20. Jun. 2017 (CEST)

Es geht auch nicht um das Raw-Bild (= Ausgangsbild), sondern um das Ergebnisbild nach den Berechnungen, abgespeichert als (?) Tiff oder sonstwas. Vielleicht wird's auch gar nicht abgespeichert, sondern erst aus (raw+Berechnungsanweisungen) im Farbdrucker berechnet. Aber das Ergebnis hat Informationsverlust zum Ursprung. --arilou (Diskussion) 11:23, 20. Jun. 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)

Tiff tut's auch, und ist verfügbar.

Zu den Gründen, warum Hersteller manches anbieten und anderes nicht, enthalte ich micht. Die Gründe haben aber auch nichts damit zu tun, welche theoretischen Vor- oder Nachteile Raw vs. Standardformat hat.

--arilou (Diskussion) 10:37, 20. Jun. 2017 (CEST)

Wir beschreiben hier in der Wikipedia Fakten möglichst nahe an der Realität. Sicherlich ist manche Formulierung auf der Vorderseite verbesserungsfähig, aber wir beschreiben halt das, was die Anbieter anbieten, nicht das, was die Anbieter eventuell anbieten könnten. Sobald im Kameramarkt Modelle mit anderen Formaten als 8-bittige-JPGs Eingang und Verbreitung gefunden haben, werden wir das sicherlich vorn wiederfinden können. Unsere Kunden (aka Leser) fotografieren mit allem möglichen, was irgendwie vorne eine Linse und hinten einen Sensor hat (manche gar ohne Linse...), und bei der gänzlich überwältigenden Mehrzahl der Geräte fallen hinten JPGs raus. Mit 8 Bit Farbtiefe. Und mehr oder weniger stark komprimiert. Und diese Kunden schnappen irgendwo etwas auf im Sinne von "Mit raw kann man $Problem1 und $Problem2 umgehen und hochwertigere Bilder erzeugen". Und nu tippen sie "raw format" in gurgel ein und landen hier. Und du meinst, genau dieser Vergleich zwischen Raw und JPG müsse also hier raus, weil er POV sei, weil es auch andere (theoretisch denk- und verwendbare) Bildformate gibt? --Smial (Diskussion) 12:40, 20. Jun. 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)

Das hat nichts mit TF zu tun, sondern ist einfache Logik.

Ein "Standard" bedingt, dass ein Hersteller seine davon abweichenden Daten anpassen muss. Wenn es dabei um wesentliche Inhalte und Bedeutung der Daten geht, dann sind sie nicht mehr (komplett) "roh".

Wenn es jedoch nur ein Container-Format ist, dass praktisch beliebige Daten enthalten kann, dann ist das kein "möglicher Ausweg", da es die Verarbeitung nicht nennenswert erleichtert.

Adobe DNG kann versuchen, einen Mittelweg dazwischen zu gehen, ok. Es kann versuchen, dass Hersteller nur unwesentliche "inhaltliche/Bedeutungs-" Anpassungen vornehmen müssen, so dass die Daten weiterhin als "weitgehend roh" angesehen werden können, und zugleich einen Container darstellen, der einen gleichbleibenden Rahmen darstellt.

Aber das sollte im Artikel dann auch so dargestellt sein, dass jeder "Ausweg" immer ein Kompromiss sein muss.

Nein, das ist keine TF. --arilou (Diskussion) 10:47, 20. Jun. 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)

Rohdaten sind kein Bild, weshalb diese in aller Regel beim Erzeugen eines Bildes unverändert bleiben. Wenn ich dagegen mit irgendeiner Software ein Bild bearbeite, liegt es an mir, ob ich beim Speichern das Originalbild überschreibe oder ob ich das Erzeugnis daneben abspeichere. Das ist es für mich, was ich bei der Ver- (nicht Be-) -arbeitung von Rohdaten als verlustfrei bezeichnen würde. --Karsten Meyer-Konstanz (D) 12:15, 24. Mai 2017 (CEST)

Man kann seine Raw-Entwicklung latürnich nicht nur als JPG, sondern auch z.B. als TIFF mit 16 Bit/Farbkanal oder noch höherer Farbtiefe (z.B. für "echtes" HDR) zwecks Weiterverarbeitung speichern, um die Verluste zu minimieren. Mit JPGs aus der Kamera geht das eher, naja, suboptimal. --Smial (Diskussion) 12:58, 24. Mai 2017 (CEST)

RAW-Bearbeitung ist immer verlustfrei, da man die Datei ja nicht ändert. --M@rcela 13:19, 24. Mai 2017 (CEST)

Quatsch, da falsche Annahme.

Das Ergebnis-Bild der Bearbeitung hat immer Informationsverluste im Vergleich zum Ausgangsbild. Egal ob Raw oder sonstwas.

Einige wenige "bearbeitende" Schritte können bestenfalls verlustlos sein; oft geht das z.B. bei einer 90°-Drehung.

Das Speichern der Schritte mitsamt dem Ausgangsbild bewirkt nur "ohne Verluste bei Zwischenbildberechnung", verhindert aber nicht einen Informationsverlust des Endergebnisses gegenüber dem Ausgangsbild.

--arilou (Diskussion) 10:55, 20. Jun. 2017 (CEST)

Du willst es offenbar nicht begreifen. --M@rcela 10:58, 20. Jun. 2017 (CEST)

Die Rohdatei ist gar keine Bilddatei. Sie kann nur mit entsprechenden Bearbeitungsschritten überhaupt sichtbar gemacht werden. Die macht das anzeigende Programm aber automatisch. MBxd1 (Diskussion) 21:00, 20. Jun. 2017 (CEST)

Canon

Wäre es nicht sinnvoll, die Dateiendungen in Großbuchstaben zu setzen? Das ist zwar eine Unsitte, doch ist die bei Canon weder den Kameragehäusen noch dem eigenen Konverterprogramm DPP auszutreiben. Bei anderen Herstellern, die es ebenso handhaben, würde ich es ebenso machen, nur habe ich da keine Übersicht. Nach Exakta, Praktica B, M42 und Canon EOS habe ich so gar keine Lust zu noch einem persönlichen Objektivanschlusssystemwechsel. –Falk2 (Diskussion) 18:10, 6. Feb. 2023 (CET)