Jump to content

Wie wichtig ist RAW in der Zukunft


Empfohlene Beiträge

Werbung (verschwindet nach Registrierung)

 

Übrigens haben die deutschen Rohrleger immer noch Zollgewinde aber die US-Army

und US-Post verlangen metrische Maße für Schrauben.

 

 

Ach, ich bin ja bescheiden, mir würde es schon reichen, wenn alle japanischen Hersteller sich auf ein Format und eine Interpretation einigen würde  ....

Link zum Beitrag
Auf anderen Seiten teilen

Das Problem ist ja nicht die fehlende Norm für das RAW, RAW ist nun mal das Abbild des Sensors.

Solange die Sensoren nicht genormt werden, bleibt es bei dem Zustand wie er eben ist, da das

die Entwicklung hemmen würde.

 

 

Sogar beim Fernsehen, was ein genormtes Verfahren allerbester Güte war, wurden alle

Normen und Abwärtskompatiblitäten über den Haufen geworfen. Und als die Norm fest

stand wurde noch schnell eine Änderung eingebaut um die Asiaten aus dem Geschäft

rauszuhalten.

Übrigens haben die deutschen Rohrleger immer noch Zollgewinde aber die US-Army

und US-Post verlangen metrische Maße für Schrauben.

 

Link zum Beitrag
Auf anderen Seiten teilen

Das Problem ist ja nicht die fehlende Norm für das RAW, RAW ist nun mal das Abbild des Sensors.

Solange die Sensoren nicht genormt werden, bleibt es bei dem Zustand wie er eben ist, da das

die Entwicklung hemmen würde.

Sogar beim Fernsehen, was ein genormtes Verfahren allerbester Güte war, wurden alle

Normen und Abwärtskompatiblitäten über den Haufen geworfen. Und als die Norm fest

stand wurde noch schnell eine Änderung eingebaut um die Asiaten aus dem Geschäft

rauszuhalten.

Übrigens haben die deutschen Rohrleger immer noch Zollgewinde aber die US-Army

und US-Post verlangen metrische Maße für Schrauben.

 

Deine Vorstellung von Normung ist meilenweit ;) von meiner entfernt. Zu weit, um zu stimmen.

 

Beim Fernsehen läuft ohne weitestgehende Normung garnichts. Dass gelegentlich Firmeninteressen mitspielen, sieht man leider beim RAW.

 

Wieso zitierst Du die Rohrleger hier und nicht das Stativgewinde? :P

 

bearbeitet von Kleinkram
Link zum Beitrag
Auf anderen Seiten teilen

Deine Vorstellung von Normung ist meilenweit ;) von meiner entfernt. Zu weit, um zu stimmen.

 

Beim Fernsehen läuft ohne weitestgehende Normung garnichts. Dass gelegentlich Firmeninteressen mitspielen, sieht man leider beim RAW.

 

Wieso zitierst Du die Rohrleger hier und nicht das Stativgewinde? :P

 

 

Beim Fernsehen wurde:

1. Das anloge terrestische abgeschaltet und ein genormtes digitales Verfahren eingeführt.

2. Wenige Jahre danach wurde dann eine neue nicht kompatible Norm angekündigt, als denn die

ersten TV-Geräte mit passenden Tunern kamen, wurde ein kleiner Zusatz eingefügt, die Leute

mußten sich denn doch Vorschaltbüchsen kaufen.

 

Warum den Rohrleger?

 

Ich bin Klempner von Beruf:

 

 

bearbeitet von Berlin
Link zum Beitrag
Auf anderen Seiten teilen

Die Schlussfolgerungen zu RAW-Dateiformaten bezüglich Normung, Firmeninteressen usw. gehen doch weit an der Realität vorbei. Hier werden vorrangig Privatinteressen,  egoistische Forderungen usw. vertreten, die m.M.n. völlig daneben liegen. Einige wollen eine Sichtweise der Dinge erzwingen, die so nicht stimmen kann.

 

Begründung:

In der Fotoindustrie hat es seit Einführung der ersten Digitlakamera bis heute eine rasende Entwicklung der Kameraprozessoren gegeben. Die unvermindert anhält und ein Ende ist nicht abzusehen. Das ist gut so! Wir alle profitieren davon.

 

Ich spreche absichtlich von Kameraprozessoren, weil nicht der lichtempfindliche Sensor der Maßstab aller Dinge ist, wie uns hier einige (technikferne?) einreden wollen. Das Gespann aus Sensor, Bildprozessor, Signalwandler mit Verstärker, Speicher, BIOS, Software und vieles mehr muss als Gesamtheit und vor allem als Einheit gesehen werden. Und dieses Gespann ändert sich von einem Kameramodell zum nächsten.

 

Jeder Kamerahersteller bemüht sich, dem Fotografen mit fertig entwickelten JPEG-, TIFF-, avchd- und etlichen weiteren -dateiformaten entgegenzukommen. Wem das nicht reicht, bekommt jeweils auch mind. ein RAW-Bildformat, abgestimmt auf die jeweils verbaute Kameratechnik. So haben manche Hersteller haben inzwischen mehrere nicht zueinander kompatible RAW-Formate (Canon, Sony usw.) herausgebracht, die sich beim besten Willen nicht so ohne weiteres normen lassen. Wenn es schon bei einem Hersteller schwer wird, wie wollte man z.B. die völlig verschiedenen Techniken von Sony und Fuji unter einen Hut bringen. Dass die Hersteller bemüht sind, dem Kunden auch hier entgegenzukommen, sieht man bereits an der Tatsache, dass die Opensource-Programmierer von CDraw immer die neuesten RAW-Infos erhalten. Dadurch sind diese RAW-Daten auch allen anderen Bildbearbeitungssoftware-Herstellern zugänglich.

 

Ich denke, man sollte mal wieder die Sau in den Stall bringen und nicht weiter durchs Dorf treiben. :)

 

bearbeitet von Rudolino
Link zum Beitrag
Auf anderen Seiten teilen

Normung als Treibjagd? Ich vermute, Du bist in einem geisteswissenschaftlichen Gebiet tätig, wo Normung keine Rolle spielt. Und hast keine weiteren technischen Geräte.

 

Zitat: Hier werden vorrangig Privatinteressen,egoistische Forderungen usw. vertreten, die m.M.n. völlig daneben liegen.

 

Danach dachte ich schon, es erfolgt ein berechtigter Angriff auf die Industrie. Pustekuchen!

 

Was Dein Hinweis auf die komplizierte Kameratechnik betrifft: Ich arbeite mit komplizierten Händies, PC und aufwändigen Audioanlagen. Überall laufen die gleichen Programme, passt dieselbe Hardware, trotz unterschiedlicher Hersteller. Es geht! Wenn man nur will!

 

Bitte erst erst die Problematik umfassend durchdenken, bevor man auf andere schießt und mit großen Tönen seine Unkenntnis beweist.

 

 

Link zum Beitrag
Auf anderen Seiten teilen

Werbung (verschwindet nach Registrierung)

Den Abschnitt fand ich auch etwas weit hergegriffen, denn die Bildprozessoren sind im Endeffekt zwar ASICs, besitzen aber meist auch nur einen ARM-Kern oder ähnliches. Und wie ich vorher schon geschrieben habe: Software lässt sich auf jeden Prozessor übersetzen, wenn es dafür einen Compiler gibt. In der Hardware- und Software-Entwicklung ist es übrigens das Ziel eben nicht ein Gerät als Einheit zu betrachten, sondern als Sammlung verschiedener miteinander kompatibler Komponenten. Und, wenn diese nicht kompatibel sind, dann macht man sie eben kompatibel. Spätestens beim Desktop-PC sollte das ersichtlich werden. Und im embedded-Bereich ist das nicht anders. Schon wirtschaftlich gesehen wäre es sehr unsinnig immer ein Modell komplett als Einheit zu verabschieden. Gerade hier spielen Dinge wie Wiederverwendung, einfache Austauschbarkeit immer eine Rolle.

Es wäre dennoch interessant zu wissen, worin sich die Raws nun so gravierend unterscheiden und ob das eine Berechtigung hat. Das sollte eigentlich das Hauptargument sein und klar ist das irgendwie niemandem hier. Stattdessen schlagen wir uns mit Hypothesen herum :D

 

Vllt. weil das nicht unerheblich ist: In der Software macht man inkompatible Software-Teile gerne dadurch miteinander kompatibel, in dem man "Wrapper" drumherum schreibt. Aber hier kommt schon genau das Problem: Daten, die entweder vorhanden sind und nicht gebraucht werden, werden verworfen oder Daten, die gebraucht werden, sind leider nicht vorhanden und müssen herausinterpretiert werden. Schätzungsweise ist auch genau das der Punkt, warum man Raw nicht einfach so normen kann.

bearbeitet von Neto-Zeme
Link zum Beitrag
Auf anderen Seiten teilen

Es wäre dennoch interessant zu wissen, worin sich die Raws nun so gravierend unterscheiden und ob das eine Berechtigung hat. Das sollte eigentlich das Hauptargument sein und klar ist das irgendwie niemandem hier. Stattdessen schlagen wir uns mit Hypothesen herum :D

Ich schätze, diese Unterschiede sind großenteils nicht wirklich gravierend und bestehen zum Teil wohl nur aus trickreich angebrachten Markern, die eine Identifikation des Kameramodells und/oder Sensors ermöglichen. Ich kann mir nicht vorstellen, wie es DCRaw sonst möglich wäre, die RAWs von 600 verschiedenen Kameras zu konvertieren. Die Berücksichtigung der unterschiedlichen Sensorformate nach Spalten und Zeilen ist wohl eine relativ einfache Transformationsaufgabe, die mit PC-Mitteln keine Probleme bereiten dürfte.

Link zum Beitrag
Auf anderen Seiten teilen

Hmmm,

 

Normen entstehen nicht wie Gesetze und werden nicht von irgendjemandem aus dem Nichts geschaffen. Ich durfte meine Firma mal zwei Jahre lang in einem Normenausschuss beim DIN vertreten und weiß seitdem, wie es überhaupt zu Normen kommt.

 

Version 0: Irgendeine Firma ist als erste mit einem Produkt auf dem Markt, wird Marktführer und irgendwas des Produkts erweist sich als extrem praktisch. Mitbewerber werden dann sehr schnell mit kompatiblen Anschlüssen, Funktionen, ... (=Schnittstellen) auf den Markt kommen, um überhaupt eine Chance zu haben, ihre eigenen Produkte verkaufen zu können. Beispiele sind zahllos:

 

0a: Fast alle höheren Programmiersprachen FORTRAN, C, C++, C#, JAVA, ... starteten als proprietäre Entwicklung einer Firma, andere wollten nicht abseits stehen und boten nur kurze Zeit später passende Compiler an. Und erst dann, insbesondere durch Interpretationsunterschiede der Compiler taten sich Kunden zusammen und entwickelten, durchaus unter Beteiligung der Erzeuger, Normen, die alles im Detail und fest vorschreiben

 

0b: Die Definitionen eines Herstellers werden veröffentlicht, und alle anderen richten sich automatisch danach. Beispiele: DXF von Autocad, Postscript und PDF von Adobe, CSV-Format von Spreadsheets (MS Excel, LibreOffice Calc, u. a.). Auch DNG von Adobe fällt in diese Kategorie, der Versuch, eine Schnittstelle (=Datenformat) bis ins kleinste zu definieren, um den PrePrint-Bereich, den Adobe beherrscht, noch weiter nach vorne, in die Kameras auszudehnen.

 

Version 1: potente Kunden, und das sind i. d. R. keine Endverbraucher, setzen sich zusammen und bringen Ordnung in das Herstellerchaos, um von proprietären inkompatiblen zu allgemein gültigen Lösungen zu kommen. Beispiele dafür sind zahllos, eines ist sicher die Normung der Lampensockel in Automobil. Ebenso die Größen von Standardbatterien.

 

Version 2: Arbeitskreise erkennen die Notwendigkeit einer allgemeinen Standardisierung und fangen an zu tüfteln. Das kommt häufig aus dem universitären Bereich, in dem aber später auch Industrievertreter mitmischen. Daraus können Normen entstehen. So ist sicher die JPEG-Norm entstanden (Joint Photographic Experts Group) und hat sich durchgesetzt, ähnlich die MPEG Normen (Motion Phot...). Aber es gibt auch viele scheiternde Normungsversuche, wie z. B. IGES, der Versuch, ein CAD-Daten-Austauschformat zu normen.

 

Eine Norm entsteht also nur auf Druck einer Gruppe von mächtigen Verbrauchern. Mächtig heißt: Umsatzbestimmend! Und gegen die Verabschiedung einer Norm können auch Widersprüche erhoben werden, z. B. von Herstellern. Was auch passiert, um z. B. Marktpositionen zu schützen.

 

Von selbst kommt kein Hersteller auf die Idee, mit anderen Herstellern Normen auszuhandeln, siehe das Chaos mit den Lithium-Akkus, wo nun nichts herstellerübergreifend passt und selbst in eigenen Kamerareihen immer wieder neue Formen erfunden werden.

 

Warum sollte sich also irgendjemand auf ein gemeinsames RAW-Format einigen? Wer drückt da? Wir Endverbraucher sind da machtlos, denn ein gemeinsames Format wäre mit Sicherheit nicht kaufentscheidend, weil es ja immer einen Weg in die Nachverarbeitung gibt. Was viel seltsamer ist: Kein Hersteller dokumentiert sein RAW-Format, Version 0b oben kann also nicht greifen. Verkaufen die Hersteller diese Informationen an Adobe und andere Software-Hersteller gegen teuer Geld? Die Freeware-Gemeinde muss sich glücklich schätzen, dass es offenbar genug Nerds gibt, die das Datenformat knacken und damit Programme wie dcraw, RawTherapee u. A. ermöglichen.

 

Für meinen Teil steht die Kamera auf JPG + RAW. Die RAWs werden in einem Unterverzeichnis des JPG-Verzeichnisses gehalten, das JPG-Verzeichnis dient zum Prüfen und Navigieren. Nur in Ausnahmefällen wird das RAW-Bild zum aufpimpen geladen, aufbereitet und geht dann per TIFF zu Bearbeitung in die Bildbearbeitung. Je nach Thema fliegt das ganze Verzeichnis mit den RAW-Files auch weg, weil nicht gebraucht.

Link zum Beitrag
Auf anderen Seiten teilen

Ich glaube sagen zu dürfen das jede Kamera, erst einmal in RAW fotografiert. 

 

Die Basis von allem. 

 

Im zweiten Schritt gibt es die Möglichkeit, das die Kamera das RAW Format -, nach vorgegebenen Algoritmen in ein Jpg verwandelt - oder bei einigen Modellen hat man die Möglichkeit es auch als RAW zu speichern. 

 

Wenn wir in RAW speichern, dann haben wir später die Möglichkeit das RAW Foto nach unseren vorstellungen des Algorithmus zu verarbeiten. 

 

Nun habe ich eine Panasonic.  Und nur hier kann ich aus meiner Erfahrung sprechen. 

 

Wenn ich meine Kamera nach meinen Aufnahme Bedürfnissen individuel Programiere - was man machen kann, in den Menü's der Kamera, so erhalte ich ein Jpg das beinahe dem Entspricht, was ich später in einem Fotoprogramm aus einer RAW Datei heraus bekommen kann. 

 

Vielleicht sollten wir uns einmal den softwäre Möglichkeiten der Kamera widmen, und diese nicht mehr betrachen als die, nicht vorhandenen Möglichkeiten , einer Analogen Kamera. 

 

 

 

Aber da ich nur ein Knipser bin, hat diese Ausage keinerlei Wert. 

 

presents.gif

 

 

 

 

 

 

 

 

 

 

 

bearbeitet von 2wheeler
Link zum Beitrag
Auf anderen Seiten teilen

Exkurs:

 

in der Kamera gehen keine lokalen Bearbeitungen .. das ist das Problem ... auch die Tonwertbearbeitung hält sich in engen Grenzen (gerade mal drei Punkte bearbeitbar) Wer seine Files individuell konvertiert und auch mal an bestimmten Stellen lokal nacharbeitet, wird mit jpg nicht mehr glücklich (was nicht heisst, dass nicht viele Bilder auch als JPG problemlos gehen ... aber will ich wirklich zwei Workflows nutzen, statt die Bilder einfach alle in DxO zu werfen und dann mehr oder weniger nachgearbeitet in einem Konvertierungslauf abarbeiten zu lassen?)

bearbeitet von nightstalker
Link zum Beitrag
Auf anderen Seiten teilen

Sehe es genau gleich. Es gibt bei mir zwei gegensätzliche Faulheitsschwellen, eine würde gerne den Aufwand bei der raw Entwicklung minimieren. Die andere möchte einen durchgehenden Arbeitsfluss ohne viele Ausnahmen, Plugins, Spezialfälle etcpp haben. Im Moment gewinnt bei mir erstere als default. Jpg macht die Kamera nur noch weil ich so viel Speicherplatz in der Kamera habe und manchmal direkt an der Kamera via iPad Fotos anschaue oder verschicke.

 

Schon nur in LR alles mögliche als plugin zu benutzen widerstrebt mir immer mehr. Deswegen benutze ich NIKs, DxO und PanoramaStudio immer seltener. Helicon ist das einzige das ich immer noch regelmässig benutzen muss...

Link zum Beitrag
Auf anderen Seiten teilen

Sehe es genau gleich. Es gibt bei mir zwei gegensätzliche Faulheitsschwellen, eine würde gerne den Aufwand bei der raw Entwicklung minimieren. Die andere möchte einen durchgehenden Arbeitsfluss ohne viele Ausnahmen, Plugins, Spezialfälle etcpp haben. Im Moment gewinnt bei mir erstere als default. Jpg macht die Kamera nur noch weil ich so viel Speicherplatz in der Kamera habe und manchmal direkt an der Kamera via iPad Fotos anschaue oder verschicke.

 

Schon nur in LR alles mögliche als plugin zu benutzen widerstrebt mir immer mehr. Deswegen benutze ich NIKs, DxO und PanoramaStudio immer seltener. Helicon ist das einzige das ich immer noch regelmässig benutzen muss...

Da gibt es für mich ein neues Rezept: Beim Import in LR die RAWs durch die neue Autokorrektur jagen. Die Resultate sind mindestens genauso gut verwendbar, wie das fertige JPEG.

Link zum Beitrag
Auf anderen Seiten teilen

0a: Fast alle höheren Programmiersprachen FORTRAN, C, C++, C#, JAVA, ... starteten als proprietäre Entwicklung einer Firma, andere wollten nicht abseits stehen und boten nur kurze Zeit später passende Compiler an. Und erst dann, insbesondere durch Interpretationsunterschiede der Compiler taten sich Kunden zusammen und entwickelten, durchaus unter Beteiligung der Erzeuger, Normen, die alles im Detail und fest vorschreiben

 

Das ist ein sehr guter Punkt. Wo C und C++ inzwischen immer weiter Aktualisierungen führ ihren Standard erhalten, gibt es dennoch genug Firmen, die von dem Standard immer wieder abweichen und ihre eigenen Schnitze einführen. Ich sag nur #pragma.

 

Und der Knackpunkt der jetzt kommt: Nutzt man bspweise einen Intel-Compiler läuft der gleiche Code auf einem Intel-Prozessor besser, als würde man bspweise den GNU-Compiler nutzen. Ganz zu schweigen davon, dass jeder Prozessor-Hersteller seinen eigenen Maschinen-Code nutzt, den man nicht einfach auf andere Prozessoren ändern kann und dort ist er zurecht nicht genormt, ansonsten könnten alle genau die gleichen Prozessoren bauen und Innovation wäre hinfällig. Man kann mit einer allumfassenden Norm nunmal nie alles abbilden, vor allem nicht in einem sehr atomaren Bereich. In diesen Fällen wäre das, als würde ich Kupfer-Atomen eine Norm aufzwingen, dass sie Eisen sind. Das geht nunmal einfach nicht.

 

Allerdings - ja -, das ist bei Bildsensoren sicher etwas anderes.

 

Das Compiler-Beispiel oben verdeutlicht das vllt. etwas. Der GNU-Compiler kann schon sicherlich Code erzeugen für den Intel-Prozessor, der auch gut läuft. Aber Intel kennt eben seine Schnitze (und vor allem seine Befehlssätze) und kann seinen Prozessor viel besser ausnutzen. Setzt man das auf die Sensoren um ist das allerdings etwas merkwürdig. Welches ist hier denn der Haus-Entwickler? Wäre das bei Sony Capture One? Also praktisch der Compiler, der das RAW am besten nutzt? und ist Lightroom praktisch der GNU-Compiler unter den Entwicklungs-Programmen? 

Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...