X-E1 JPEG&RAW noch nötig?

[mjh]

Werbung (verschwindet nach Registrierung)

Ich verstehe das so das die RAW Daten ohne Informationsverlust in das universelle DNG Format verwandelt werden. Außerdem sollen die Originaldaten angeblich in den DNGs enthalten sein. Bei den Leica Ms passiert das wohl in der Kamera.

DNG ist im Prinzip bloß ein weiteres Raw-Format neben CR2, NEF, ORF, PEF und so weiter. Allerdings ist es ein Format, das so viele Varianten hat, dass sich die proprietären Formate der Kamerahersteller darin konvertieren lassen. Wenn das aber einmal nicht vollständig möglich ist, kann man auch noch die originalen Raw-Daten dazu packen; dann wird die DNG-Datei zwar ziemlich fett, aber es geht nichts verloren. Da das nicht der Weisheit letzter Schluss sein kann, wird DNG immer wieder mal um zusätzliche Features erweitert, damit auch Innovationen der Kamerahersteller berücksichtigt werden können.

 

Wenn nun ein Kamerahersteller, der noch kein eigenes Raw-Format hat, eines braucht, kann er auch gleich DNG verwenden, statt die Vielzahl der Raw-Formate um ein weiteres zu vergrößern. So hat es beispielsweise Leica gemacht. Das ist aber auch noch keine Garantie dafür, dass die Raw-Konverter mit diesen Dateien umgehen können. Als Leica in diesem Jahr die M Monochrom auf den Markt brachte, die eine reine Schwarzweißkamera ist und deren Sensor daher keine Farbfilter im Bayer-Muster hat, da konnten sie auf eine für genau diesen Zweck im DNG-Standard vorgesehene Variante für die Speicherung monochromer Rohdaten zurückgreifen. Adobes ACR und Lightroom verstanden diese DNG-Dateien auch sofort, also Monate bevor überhaupt jemand außerhalb Leicas (und mir <g>) von der Kamera wusste. Apples Aperture, auf der anderen Seite, kann es noch immer nicht, obwohl es sich sonst auf DNG versteht. Aber Aperture unterstützt halt nicht so viele DNG-Varianten (und es gibt unzählige davon) wie Adobe. Letztendlich löst DNG viel weniger Probleme, als viele glauben. Es ändert jedenfalls nichts daran, dass jeder Kamerahersteller seine speziellen Eigenheiten pflegt, denn nach einer Konversion in das DNG-Format sind die Daten immer noch so eigen, wie sie es vorher waren. Sie liegen nur in einem etwas anderen Format vor.

[kavenzmann]

Danke für die Erklärung.

 

Heisst es doch so gerne, dass DNG angeblich alle Kompatibilitätsprobleme löst...

[Rico Pfirstinger]

Heisst es doch so gerne, dass DNG angeblich alle Kompatibilitätsprobleme löst...

 

Im Gegenteil, es schafft nur zusätzliche Verwirrung, weil dann jeder Benutzer auch noch wissen muss, welcher seiner Konverter welche Version von DNG in welchem Umfang unterstützt – und welche DNG-Version seine Kamera erzeugt. Und: Neue Entwicklungen werden evtl. dadurch aufgehalten, dass Adobe als Mittler erst noch den DNG-Standard für die Neuheit erweitern muss. Diese Erweiterung wiederum muss dann allen RAW-Konverter-Herstellern mitgeteilt werden, sodass diese ihre eigenen Konverter aktualisieren können. Der Aufwand für die Unterstützung der neuen Möglichkeiten wäre dann derselbe, nur mit längeren Wegen und Adobe mittendrin als potenzieller Bremsklotz. Qualitativ besser würde dadurch auch nichts, weil das Demosaicing am Ende stets der jeweilige Konverter leisten muss. Alternativ könnte man auf RAW-Daten verzichten und gleich eine 16-Bit-TIFF-Datei nehmen. Damit kann jedes Programm etwas anfangen, mit RAW hat das dann aber nicht mehr viel zu tun.

[specialbiker]

DNG ist im Prinzip bloß ein weiteres Raw-Format neben CR2, NEF, ORF, PEF und so weiter. Allerdings ist es ein Format, das so viele Varianten hat, . . . .

 

Hallo Michael,

 

 

vielen Dank für diesen konstruktiven Beitrag zum Thema. Eines habe ich allerdings nicht verstanden: Warum ist es so schwer, das Herstellerspezifische vom Standardisierten zu trennen? Meine Vorstellung war die, knapp ausgedrückt: RAW = Sensor-Pixelwerte entsprechend geometrischer Anordnung, DNG = RGB Matrix, also insbesondere eine Darstellung, bei der das herstellerspezifische Demosaicing schon durchgerechnet ist. Ab nun sollten die erzeugten Dateien doch RGB Werte darstellen, mit denen alle Programme zurechtkommen, würde man erwarten. Insbesondere für den hier besprochenen X-Trans Sensor wäre die Erzeugung einer DNG-Datei, also ein Umrechnen der speziellen Farbmaske in RGB Werte, der einfachste Weg, zum Ziel zu kommen.

 

Was ist mein Denkfehler?

 

 

Gruß Hans

[kavenzmann]

Dann wärs ja im Grunde ein 16bit TIFF...

[specialbiker]

Dann wärs ja im Grunde ein 16bit TIFF...

 

 

Genau, was die Bildinformation betrifft schon. Lediglich erwartet man vom DNG noch Zusatzinformation (wie z. B. das eingebettete RAW), aber in Bezug auf eine Weiterverarbeitung würde es sich so verhalten, nach meiner Ansicht. Aber ich stochere hier nur im Nebel, bisher war RAW für mich nie ein Thema (da es immer funktioniert hat), erst jetzt bin ich gezwungen, mich damit auseinanderzusetzen.

 

 

Gruß Hans

[mjh]

Werbung (verschwindet nach Registrierung)

Meine Vorstellung war die, knapp ausgedrückt: RAW = Sensor-Pixelwerte entsprechend geometrischer Anordnung, DNG = RGB Matrix, also insbesondere eine Darstellung, bei der das herstellerspezifische Demosaicing schon durchgerechnet ist. Ab nun sollten die erzeugten Dateien doch RGB Werte darstellen, mit denen alle Programme zurechtkommen, würde man erwarten. Insbesondere für den hier besprochenen X-Trans Sensor wäre die Erzeugung einer DNG-Datei, also ein Umrechnen der speziellen Farbmaske in RGB Werte, der einfachste Weg, zum Ziel zu kommen.

Dann würden aber die wichtigsten Verarbeitungsschritte schon im DNG-Konverter ausgeführt, und dem Raw-Konverter, der mit den konvertierten Daten arbeiten soll, gingen etliche Freiheitsgrade verloren. Mit einem Raw-Workflow will man sich doch gerade möglichst viele Freiheitsgrade erhalten, und das basiert darauf, dass die Daten möglichst roh sind. Eine Vereinheitlichung der Daten würde dem zuwider laufen.

[specialbiker]

Dann würden aber die wichtigsten Verarbeitungsschritte schon im DNG-Konverter ausgeführt, und dem Raw-Konverter, der mit den konvertierten Daten arbeiten soll, gingen etliche Freiheitsgrade verloren. Mit einem Raw-Workflow will man sich doch gerade möglichst viele Freiheitsgrade erhalten, und das basiert darauf, dass die Daten möglichst roh sind. Eine Vereinheitlichung der Daten würde dem zuwider laufen.

 

Hallo Michael,

 

nur dass mit dieser Sichtweise, in einer DNG Datei RAW Daten auf unterster Ebene zu "verpacken", eben doch wieder die Verarbeitung auf Firmen übertragen wird, die mit ihren Anpassungen entweder nicht hinterherkommen oder sie schlicht nicht beherrschen, bzw. denen die Entwicklung zu teuer wird. Wenn der Urheber des Formates dann auch noch der Bremsklotz ist, ist das Ganze ja fast schon peinlich.

 

Ohne mich jetzt zu weit aus dem Fenster zu lehnen: Ein gepacktes RGB-Format (also ähnlich TIFF), und zwar unbearbeitet in Bezug auf Schärfen, Rauschen, Helligkeit, Kontrast etc. hatte alle herstellerspezifischen Hürden ausgeklammert und würde dann von wirklich jedem RAW Konverter verarbeitet werden können (nur Demosaicing ausgeschaltet).

 

Es geht ja bei diesem Format eigentlich nicht um die Maximierung von Freiheitsgraden, sondern um die Aufteilung: Herstellerspezifische Aufbereitung (darunter würde auch die Decodierung des X-Trans fallen) einerseits, allgemeine BV andererseits. Dann kann nämlich jeder einbringen, was er am besten kann. So versucht Fuji ein Lightroom in der Kamera nachzubauen, und Adobe übernimmt sich mit der Aufgabe, einen hochspezifischen Sensor in eine Standardsoftware zu quetschen, im Ergebnis: Keines der beiden ist richtig gelungen. Man hat also vieles doppelt, zahlt auch doppelt, aber das, was es wirklich braucht, fehlt dennoch.

 

 

Schade, wieder Chance verpasst.

 

Gruß Hans

[Rico Pfirstinger]

Ein gepacktes RGB-Format

 

Hm, AdobeRGB, sRGB oder ein ganz anderes RGB? Was wäre daran eigentlich noch RAW, wenn sogar der Farbraum bereits feststeht?

[mjh]

Wenn man den Nutzen eines Raw-Formats haben will, muss man mit den Rohdaten arbeiten, nicht mit bereits teilweise verarbeiteten Daten. Da gibt es keinen Königsweg.

 

nur dass mit dieser Sichtweise, in einer DNG Datei RAW Daten auf unterster Ebene zu "verpacken", eben doch wieder die Verarbeitung auf Firmen übertragen wird, die mit ihren Anpassungen entweder nicht hinterherkommen oder sie schlicht nicht beherrschen, bzw. denen die Entwicklung zu teuer wird. Wenn der Urheber des Formates dann auch noch der Bremsklotz ist, ist das Ganze ja fast schon peinlich.

Fuji ist ja nicht der Bremsklotz. Raw-Konvertierung ist eine anspruchsvolle Aufgabe. Entweder stellt man sich der Aufgabe und bewältigt sie, oder eben nicht. Wenn jemand erst zum Jagen getragen werden muss, lässt er es vielleicht besser gleich.

bearbeitet 8. Dezember 2012 von mjh

[specialbiker]

Hm, AdobeRGB, sRGB oder ein ganz anderes RGB? Was wäre daran eigentlich noch RAW, wenn sogar der Farbraum bereits feststeht?

 

Die Frage ist, ob diese Datei überhaupt einen Farbraum braucht: Da ja in dieser Bearbeitungsphase kein Anspruch auf Gerätekompatibilität erhoben wird sehe ich auch keine Notwendigkeit für einen definierten Farbraum. Den muss das BV-Programm beisteuern (ein Sensor besitzt schließlich auch keinen Farbraum).

 

Und ob das dann noch RAW ist oder nicht ist doch egal: Ich will nur eine vernünftige Basis für die Ausarbeitung eines Fotos mit einem Programm, dass vom X-Trans nichts wissen muss (die z. B. bei Sikypix nicht gegeben ist: Der Versuch, in Silkypix eine "unbearbeitete" TIFF Datei zu erzeugen mißlingt: Geschärft, entrauscht und sonstwas, aber eben nicht unbearbeitet.

 

Gruß Hans

[specialbiker]

Fuji ist ja nicht der Bremsklotz.

 

Ich meinte an dieser Stelle auch Adobe (Urheber des DNG Fomates). Fuji bremst ja nicht, ganz im Gegenteil: Fuji ist in manchen Dingen innovativer als andere, und wenn ein Fehler begangen wurde, dann der, dass man sich vor der Entscheidung X-Trans nicht die Unterstützung der (wichtigen) BV-Software Unternehmen eingeholt hat, wenigstens ein Kandidat der Kategorie C1, DXO oder Adobe hätte ja schon vieles erleichtert. Ob man wirklich zu Ende gedacht hat, was das in der Konsequenz für den Anwender heissen kann?

 

Aber aktuelle Gerüchte besagen ja, dass bei C1 etwas in Vorbereitung ist.

 

Gruß Hans

bearbeitet 8. Dezember 2012 von specialbiker

[Rico Pfirstinger]

Und ob das dann noch RAW ist oder nicht ist doch egal: Ich will nur eine vernünftige Basis für die Ausarbeitung eines Fotos mit einem Programm, dass vom X-Trans nichts wissen muss (die z. B. bei Sikypix nicht gegeben ist: Der Versuch, in Silkypix eine "unbearbeitete" TIFF Datei zu erzeugen mißlingt: Geschärft, entrauscht und sonstwas, aber eben nicht unbearbeitet.

 

Jegliches Demosaicing ist aber eine gravierende Bearbeitung.

[Rico Pfirstinger]

Ich meinte an dieser Stelle auch Adobe (Urheber des DNG Fomates). Fuji bremst ja nicht, ganz im Gegenteil: Fuji ist in manchen Dingen innovativer als andere, und wenn ein Fehler begangen wurde, dann der, dass man sich vor der Entscheidung X-Trans nicht die Unterstützung der (wichtigen) BV-Software Unternehmen eingeholt hat, wenigstens ein Kandidat der Kategorie C1, DXO oder Adobe hätte ja schon vieles erleichtert.

 

Fuji hat Adobe doch schon 2011 ins Boot geholt und die benötigten X-Trans-Spezifikationen übermittelt (und das auch immer wieder in Interviews betont), deshalb unterstützt LR/ACR den X-Trans auch bereits seit Mai, also etwa drei Monate nach Beginn der Auslieferung. Adobe allerdings scheint die Aufgabe etwas unterschätzt zu haben, zumindest hat es diesen Anschein. Ich finde es ehrlich gesagt ziemlich abenteuerlich, dass gefühlte 90% der Adobe-Kunden, die Adobe für eine gute X-Trans-Unterstützung ihr Geld gegeben und die Software gekauft haben, nicht Adobe sondern Fuji dafür verantwortlich zu machen scheinen.

 

Ich denke übrigens, dass Fuji ziemlich sauer war, als Adobe dann mit dem schwachen Demosaicing herauskam, das bei den Details sogar hinter Silkypix zurückbleibt. Nun darf Fuji also Adobe unerwartete Nachhilfe im Demosaicing geben – wenn das nicht irre ist! Adobe ist doch DIE weltweite Kapazität in Sachen RAW-Entwicklung! Eigentlich hätte man erwarten dürfen, dass Adobe mit ihrer geballten Erfahrung, ihrem Know-how, ihren Ressourcen und ihrer Experten-Manpower mit einer viel besseren Methode für den X-Trans aufwarten würden, die Fujis eigene Versuche mit dem eingebauten RAW-Konveter qualitativ in den Schatten stellt. Stattdessen gab es eine halbherzige Umsetzung auf "EXR-Niveau". Womöglich dachte man bei Adobe, dass sich die "dummen Fuji-Kunden" mit dieser zweitklassigen Lösung schon zufrieden geben würden? Bei EXR muckten die Kunden schließlich auch nicht auf! Da haben sie sich allerdings verrechnet, denn der X-Trans-Kunde hat andere Qualitätsansprüche als der typische EXR-Kunde, den Adobe nun bereits seit mindestens drei Jahren immer wieder neu verarscht. Jetzt heißt es für Adobe Nachsitzen und das tun, was man von Anfang an hätte leisten müssen.

[kavenzmann]

Ich glaube nicht, dass hier irgendwer einen anderen absichtlich verarschen will.

 

Das Thema X-Trans Demosaicing wurde einfach unterschätzt. Von Fuji, von Adobe und auch von den meisten Anwendern. Alle schreien SUPER, wenn es um die Vorzüge des Sensordesigns geht, die damit erkauften Nachteile wollte und will kaum einer sehen. Es gibt die "eierlegende Wollmilchsau" im Sensordesign nicht, es gibt nur so'ne und solche mit jeweils spezifischen Vor- wie Nachteilen. Das Bayer Design ist der größte gemeinsame Nenner, der dadurch auch die beste Unterstützung genießt.

 

Wer von diesem Weg abweicht, muss damit rechnen diese Unterstützung zu verlieren. Die Konverter-Hersteller wären ja geradezu bekloppt, wenn sie die Hersteller der non-bayer Sensoren ebenso gut unterstützen. Dann hätten sie nämlich deutlich mehr Arbeit, bisher sind die Anpassungen für neue Kameramodelle durch Herrn Bayer relativ einfach.

 

Ich glaube nicht daran, dass Adobe ohne wirtschaftlichen Nutzen von sich aus den X-Trans besser unterstützen wird. Da muss entweder Fuji oder besser der Kunde durch sein großes Interesse an den Fujikameras in die Pötte kommen.

 

Ich persönlich sehe die Verantwortlichkeit einer perfekten X-Trans Unterstützung per externer Software bei Fuji und nicht bei den Softwareherstellern. Wenn Fuji als Systemhersteller auf dem Markt ernst genommen werden will, muss es auch einen vernünftigen RAW Arbeitsablauf ermöglichen. Dieser mag für manche durch den internen Konverter, für andere durch Silkypix gegeben sein - für mich nicht.

Ich will aber deswegen auch nicht rumheulen, diese Problematik war von Anfang an durch das eigenwillige Sensordesign vorherzusehen. Das kenne ich ja bereits von Foveon...

[Rico Pfirstinger]

 

Ich persönlich sehe die Verantwortlichkeit einer perfekten X-Trans Unterstützung per externer Software bei Fuji und nicht bei den Softwareherstellern. Wenn Fuji als Systemhersteller auf dem Markt ernst genommen werden will, muss es auch einen vernünftigen RAW Arbeitsablauf ermöglichen. Dieser mag für manche durch den internen Konverter, für andere durch Silkypix gegeben sein - für mich nicht.

Ich will aber deswegen auch nicht rumheulen, diese Problematik war von Anfang an durch das eigenwillige Sensordesign vorherzusehen. Das kenne ich ja bereits von Foveon...

 

Du hast das Ganze also vorhergesehen, nimmst Fuji als Systemhersteller nicht ernst und hast nun (wie vorhergesehen) keinen "vernünftigen RAW-Arbeitsablauf" – und trotzdem hat du dir das System gekauft?

 

Mehr wollte Fuji doch gar nicht von dir, insofern: Ziel erreicht.

[D700]

...

Ich persönlich sehe die Verantwortlichkeit einer perfekten X-Trans Unterstützung per externer Software bei Fuji und nicht bei den Softwareherstellern...

 

Das sehe ich genau so!

Und deshalb legt ja Fuji auch einen funktionierenden RAW Konverter dazu - alles andere ist dann doch eher ein Problem der anderen Softwarehersteller....

[specialbiker]

Das sehe ich genau so!

Und deshalb legt ja Fuji auch einen funktionierenden RAW Konverter dazu - alles andere ist dann doch eher ein Problem der anderen Softwarehersteller....

 

Auf einer Skala von 1 = Virus bis 10 = Lightroom kriegt Silky Pix von mir allenfalls eine 3. Will damit sagen: Die Silky Pix Lösung ist allenfalls eine Alibifunktion, die Fuji da seiner Kamera mitliefert.

 

Gruß Hans

[mjh]

Die Frage ist, ob diese Datei überhaupt einen Farbraum braucht: Da ja in dieser Bearbeitungsphase kein Anspruch auf Gerätekompatibilität erhoben wird sehe ich auch keine Notwendigkeit für einen definierten Farbraum. Den muss das BV-Programm beisteuern (ein Sensor besitzt schließlich auch keinen Farbraum).

Oh doch, ein Sensor hat einen Farbraum! Und zwar irgendeinen merkwürdigen, gerätespezifischen Farbraum, den in einen Standardfarbraum wie sRGB oder Adobe RGB zu konvertieren zu den Aufgaben eines Raw-Konverters gehört. Wenn man so, wie Du Dir das vorstellst, von den Eigenheiten spezieller Sensoren abstrahiert, dann muss man auch schon in einen Standardfarbraum konvertieren, denn später ginge es nicht mehr (wenn man sich nicht doch wieder mit den Eigenheiten des Sensors auseinandersetzen will).

[specialbiker]

Oh doch, ein Sensor hat einen Farbraum! Und zwar irgendeinen merkwürdigen, gerätespezifischen Farbraum, den in einen Standardfarbraum wie sRGB oder Adobe RGB zu konvertieren zu den Aufgaben eines Raw-Konverters gehört. Wenn man so, wie Du Dir das vorstellst, von den Eigenheiten spezieller Sensoren abstrahiert, dann muss man auch schon in einen Standardfarbraum konvertieren, denn später ginge es nicht mehr (wenn man sich nicht doch wieder mit den Eigenheiten des Sensors auseinandersetzen will).

 

OK, hab ich nicht gewusst. Naheliegend wäre aber dann doch, einen möglichst großen Farbraum zu nehmen, dan maximal möglichen.

 

Gruß Hans

[Rico Pfirstinger]

Welcher Standard ist denn "maximal möglicher Farbraum" und welche RAW-Konverter untertützen diesen Standard?

[helmus]

OK, hab ich nicht gewusst. Naheliegend wäre aber dann doch, einen möglichst großen Farbraum zu nehmen, dan maximal möglichen.

 

Gruß Hans

 

Das wäre aber auch nur dann sinnvoll wenn unsere Ausgabegeräte, sprich Monitor, Drucker, den auch darstellen könnten. Die meisten von uns arbeiten an Monitoren die noch nicht einmal SRGB komplett darstellen können,

geschweige denn Adobe RGB. Ich suche noch nach einem gescheiten Monitor, mein jetziger schafft gerade mal 70% SRGB

[tabbycat]

Auf einer Skala von 1 = Virus bis 10 = Lightroom kriegt Silky Pix von mir allenfalls eine 3.

LOL

 

Ich geh mich jetzt aufhängen. In einem Universum, indem LR die Spitze aller Softwareentwicklungen darstellt, mag ich nicht leben.

 

mfg tc

[specialbiker]

Welcher Standard ist denn "maximal möglicher Farbraum" und welche RAW-Konverter untertützen diesen Standard?

 

Die Farbraumbeschreibung wird man wohl in der Datei mit ablegen können. Bei einem RAW hat man dieses Problem ja auch und kann es als gelöst betrachten. Einzig und allein das herstellerspezifische Demosaicing ist doch das Problem, daher der Vorschlag, wenigstens diesen einen Schritt in der Kamera abzubilden.

 

Gruß Hans

[specialbiker]

LOL

 

Ich geh mich jetzt aufhängen. In einem Universum, indem LR die Spitze aller Softwareentwicklungen darstellt, mag ich nicht leben.

 

mfg tc

 

Hallo tabbycat,

 

Dir zuliebe kriegt LR von mir eine 8 (und SilkyPix wird proportional auf 2 herab gestuft). Welcher Konverter hat denn Deiner Meinung nach die 10 verdient?

 

Gruß Hans

[Dein Support für das Forum]

Hat dir das Forum geholfen? So kannst du das Forum unterstützen!

Premium Mitglied werden | Spenden | Bei Amazon* oder eBay* kaufen
Software: Topaz* | DxO Nik Collection* | Skylum Luminar* (–10€ mit Gutschein FXF) | * Affiliate Links