X3F -> DNG - Konverter (auch für Merrill und Quattro)

[oz75]

Dafür, dass es nicht geeignet sein soll, funktioniert es aber schon erstaunlich gut, und dies erst noch ohne technische Unterstützung durch Sigma.

Man kann es nie allen recht machen. Und glücklicherweise muss man das auch nicht.

Hat mal jemand einen Schärfevergleich zwischen beiden Entwicklungsmethoden?

Ja.

Hier ein 100%-Ausschnitt aus SPP6


Hier das x3f_extract DNG (denoised) -> Import per ACR in PSE11. (Unscharf maskiert 85% mit Radius 0,3Px)


Die Unterschiede sind m.E. marginal.

In einer Angelegenheit macht die DNG-Konversion in Kombination mit ACR eine sehr gute Figur: Bei der Spitzlichterrekonstruktion.

SPP:


x3f_extract DNG via ACR in PSE11

Die Umwandlung von X3F der Merrills zu DNG dauert bei mir genauso lange wie das direkte Erzeugen von TIFF's aus SPP in bester Bildqualität. Die DNG's hingegen müssen erst noch entwickelt werden.

Auch TIFFs wollen erst einmal unter SPP optimiert werden und kommen bei der weiteren Bearbeitung m.E. nicht an die DNGs heran.

Weiterhin kann man ganze Verzeichnisse mit einem Kommandozeilenbefehl bzw. mit dem GUI-Tool von motionride umwandeln. Bequem und nebenbei.

Um Mißverständnisse zu vermeiden: SPP läuft bei mir seit Version 6 sehr gut und gutmütig. Dafür allerdings bei anderen Nutzern zum brechen schlecht. Das Forum ist voll mit dem Wehklagen jener, bei denen das Programm nicht sauber läuft. So war es übrigens wiederum bei mir mit SPP5. Ein Absturzgarant mit absonderlichen Ergebnissen bei Langzeitbelichtungen. Typisch Sigma halt.

Dass SPP das einzige X3F-RAW-Tool für Merrill und Quattro sein soll, ist unerträglich. Sich gerade Sigma ausliefern zu müssen ist -nachweislich- überaus unangenehm.
Es sollte immer eine gute Alternative geben, damit sich Tools ggf. ergänzen. Insofern ist die aktuelle Entwicklung mehr als zu begrüßen. Egal wer nun welches Werkzeug präferiert.

Durch diese Diversifizierung verfügbarer RAW-Werkzeuge könnte Sigma natürlich Gefahr laufen, mit seinen Kameras attraktiver für potenzielle Interessenten zu werden. Aber das darf offenbar nicht sein. ^^

Die einzige Schwäche, die bei x3f_extract bleibt, ist das Fehlen von Linsenprofilen. In diesem Punkt scheint Sigma nicht mit anderen zu kooperieren. Typisch.

Egal. Diese Profile kann man sich, DNG sei dank (z.B. für Alt-Optiken) nun mit geringem Aufwand via CornerFix selber erstellen.

http://www.bilderforum.de/t18426-p2...tz-manueller-linsen-entfernen.html#post255009

Falls man den Umweg über CornerFix nicht gehen möchte, kann man auch das Adobe Flatfield Plugin für Lightroom (ab V4.0 aufwärts) verwenden.

http://labs.adobe.com/technologies/lightroomplugins/

Scheint lt. dpreview-Forum auch ganz gut zu funktionieren. Ich selbst habe es noch nicht getestet, da ich LR 3.6 besitze.

Gruß,
Oz

 

[Try]

Danke. :daumen:

 

[AB-AndreasBeck]

Ob SPP wirklich so langsam ist wie oft behauptet, wird sich zeigen, wenn die 50MP Canon von Vielen in Benutzung sein wird.

Das zugrunde liegende Problem ist nicht die Rechengeschwindigkeit des Programms.

Der Kasus Knaktus liegt einfach in der Tatsache, dass das fertige Bild aus den Daten, das der Sensor liefert, beim Foveon wesentlich schwieriger zu berechnen ist als bei einem Bayer-Sensor.

Bei letzterem stammt das Signal, das z.B. ein "grünes Pixel" liefert, auch tatsächlich von grünem Licht.

Beim Foveon ist das anders. Grünes Licht wird zwar mit der größten Wahrscheinlichkeit in der "grünen" Schicht absorbiert, aber zu einem nicht unwesentlichen Teil auch in der roten und der blauen. Für die anderen Farben gilt das entsprechend.

Der Bildprozessor bzw. die Konverter-Software muss diese Mischsignale nun auf die reinen Farbinformationen zurückrechnen - der Statistiker sagt dazu "entfalten". Entfaltungen gehören zu den rechenintensivsten statistischen Prozessen überhaupt.

Das ist ungefähr (nicht allzusehr übertrieben) so, als wenn man versehentlich einen Esslöffel Salz ins Kuchenmehl gerührt hat und dann versucht, das wieder auseinanderzupfrimeln.

Für den Bildprozessor in den Kameras gilt prinzipiell dasselbe. Denn der muss ja mindestens ein ordentliches Vorschaubild liefern. Und aus demselben Grund sollte man JPEGs aus der Kamera nur unter Vorbehalt verwenden.

Andreas

 

[oz75]

Bei letzterem stammt das Signal, das z.B. ein "grünes Pixel" liefert, auch tatsächlich von grünem Licht.

Nun, ganz so einfach ist es nicht, da das Filter für das "grüne Pixel" natürlich auch ein Stück weit andere Spektralbereiche durchlässt, hier schön dargestellt.

Aber ja: Das "grüne Pixel" ist nunmal für das "Grünsignal" zuständig.

Beim Foveon ist das anders. Grünes Licht wird zwar mit der größten Wahrscheinlichkeit in der "grünen" Schicht absorbiert, aber zu einem nicht unwesentlichen Teil auch in der roten und der blauen. Für die anderen Farben gilt das entsprechend.

Der Bildprozessor bzw. die Konverter-Software muss diese Mischsignale nun auf die reinen Farbinformationen zurückrechnen - der Statistiker sagt dazu "entfalten". Entfaltungen gehören zu den rechenintensivsten statistischen Prozessen überhaupt.

Ich vermute, dass es aufwendig, aber nicht ganz so dramatisch ist. Es ist richtig, dass aufgrund der untereinanderliegenden Detektionsebenen, jede auf den Foveon-Sensor treffende Wellenlänge durch ein idealerweise unverwechselbares, spezifisches Quantenausbeute-Tripel charakterisiert ist. So etwas lässt sich gut tabellieren.

Dem Sensor bringt man das Farbensehen also per Monochromator bei, indem man die Wellenlängen den Readout-Tripeln zuordnet und daraus Lookup-Tabellen erstellt. Auf diese greift der Kameraprozessor bzw die jeweilige RAW-Entwicklungssoftware im ersten Schritt zurück.

Gruß,
Oz

 

[Klaus-R]

Diese oder jene Sensortechnologie .... es ist für mich unvorstellbar und faszinierend, welch ungeheure Datenmengen da in Bruchteilen von Sekunden allein schon aufgezeichnet werden können .... geschweige denn "verarbeitet".

Grüße

Klaus

 

[AB-AndreasBeck]

dass aufgrund der untereinanderliegenden Detektionsebenen, jede auf den Foveon-Sensor treffende Wellenlänge durch ein idealerweise unverwechselbares, spezifisches Quantenausbeute-Tripel charakterisiert ist.

So weit richtig. Nur: Es trifft nicht nur eine Wellenlänge auf das Pixel-Tripel, sondern je nach Mischfarbe eine große Zahl unterschiedlicher Zusammensetzung. Die Signale jeder Wellenlänge addieren sich, bevor der Sensor die Information über die Zusammensetzung auslesen kann.

Das wieder auseinanderzupfrimeln ist eine ungeheure Aufgabe für die Software. Mit einer Tabelle allein ist das nicht zu stemmen. Eine solche müsste (bei einer angenommenen Tiefenauflösung von 14 bit) einen Umfang von 16 Gigabyte haben, wie eine Überschlagsrechnung zeigt.

Ich vermute, es wird eine Kombination aus Tabelle und Entfaltungsalgorithmen verwendet. Nur so lassen sich meiner Einschätzung nach Umfang der Software und die Rechenzeit im Rahmen halten.

Hier berühren wir aber sicher schon Betriebsgeheimnisse von Sigma/Foveon.

Vielleicht ist hier auch der Grund zu suchen, warum Sigma sich so schwer tut, die Struktur der X3F-Dateien publik zu machen: Sie könnte Hinwiese auf die interne Architektur des Sensors geben - ein Wissen, auf das die Konkurrenz schärfer als scharf ist.

Andreas

 

[Eule]

Was macht ACR hier eigtl. genau?



Grüße,
Eule

 

[Klaus-R]

Hmmm,

das habe ich jetzt nicht verstanden.

grüße

Klaus

 

[Eule]

Die Frage wäre gewesen:

Was nutzt ACR hier, um SIGMA RAW anzuzeigen bzw. zu bearbeiten?
Dieses hier angepriesene Tool?
Etwas direkt von SIGMA?
Die .jpeg aus der RAW?


Grüße,
Eule

 

[oz75]

Was nutzt ACR hier, um SIGMA RAW anzuzeigen bzw. zu bearbeiten?
Dieses hier angepriesene Tool?

Nein. Der Ausstieg Adobes aus dem X3F-Geschäft ist älter als dieses Tool hier.

Etwas direkt von SIGMA?

Das weiss wohl nur Adobe.

Die .jpeg aus der RAW?

Nein.

Gruß,
Oz

 

[oz75]

Roland Karlsson hat sein Kalpanika auf SD-Quattro-Dateien erweitert :daumen::

https://github.com/Kalpanika/x3f/releases/tag/0.55

Grüße,
Oz

 

[oz75]

Ein kommerzieller Grafikkonverter für Mac scheint Kalpanika zu nutzen.

Für jene, die's interessiert...

https://www.dpreview.com/forums/post/58558669

Ich kann das Tool nicht testen, da ich keinen Mac habe...

 

[Stoneage]

Ein kommerzieller Grafikkonverter für Mac scheint Kalpanika zu nutzen.

Für jene, die's interessiert...

https://www.dpreview.com/forums/post/58558669

Ich kann das Tool nicht testen, da ich keinen Mac habe...

Danke, ich könnte, aber da ich keinen Quattro mehr hab.....

 

[oz75]

Danke, ich könnte, aber da ich keinen Quattro mehr hab.....

Ist das Ding für die Merrills nicht auch interessant?

 

[Stoneage]

Ist das Ding für die Merrills nicht auch interessant?

Interessant schon, aber Kalpanika korrigiert ja die Farbverschiebungen (Vignette) der Merrills nicht raus.

 

[oz75]

Interessant schon, aber Kalpanika korrigiert ja die Farbverschiebungen (Vignette) der Merrills nicht raus.

Ok, wenn die da nichts in Richung Kalibrierung gemacht haben, kann man das Tool für die Merrils wohl vergessen.

Gruß,
Oz

 

[geni1105]

Hallo,
der Vollständigkeit halber folgender Hinweis, auch wenn sich in diesem Thread schon lange nichts getan hat:
es gibt mit dem „X3F Wrapper“ seit einigen Jahren ein Tool für Windows und MacOS, das x3f_extract / Kalpanika in eine brauchbare GUI verpackt, womit man bequem einen Ordner von X3F Raws in DNG Files umwandeln kann.

Ich habe den Wrapper später um eine Option erweitert, die für DNGs von DP Merrill’s die berüchtigten Farbstiche in den Ecken beseitigt, also das umsetzt, was hier als „Linsenprofile“ bezeichnet wird — zumindest wenn man die DNGs mit Adobe RAW Konvertern bearbeitet (ACR, Lightroom).
Die aktuelle Version hier Kalpanika/x3f_wrapper

Es gibt auch einen Trick für nicht-Adobe Konverter: einfach die DNGs mit dem gratis Adobe DNG Converter nochmals konvertieren, wobei für die Kompatibilität „4.6 and higher“ eingestellt wird.

Vielleicht hilft das jemanden von SPP loszukommen, ich bearbeite meine X3Fs eigentlich nur mehr mit ACR. Voraussetzung sind gut belichtete Aufnahmen, sonst bekommen die Schatten leicht grünliche Stiche (leider clippen die Vorschaubilder der Merrill’s lange bevor der Sensor wirklich gesättigt ist, man kann deutlich stärker belichten - FastRawViewer ist hier mein Freund und zeigt den Spielraum gut auf).

Grüsse, Georg

 

[geni1105]

Zusatzinformation: die aktuelle offizielle Version 0.57 Beta des X3F Wrappers braucht eine ältere Version des exiftool, nämlich <= 11.70. Verfügbar hier Index of /authors/id/E/EX/EXIFTOOL

 

[Robert]

Vielen Dank fürs Update des Threads

 

[geni1105]

Noch eine wichtige Info: die Version 0.57 hat zumindest am Mac ein Problem mit Merrills - grünliche Schatten. Die Version 0.56 Beta 3 funktioniert hingegen gut, sie ist unter Kalpanika/x3f_wrapper zu finden. Dieser fehlt jedoch ein Opcode für F/5.0 für die DP3M, den man sich aber leicht von der 0.57 kopieren kann.