K-3 II Praxisthread - Erfahrungen aus erster Hand

Habe gestern ein Mohnblumenfeld Fotografiert,da wollte ich mal schauen,ob auch Pixel Shifting-ohne Stativ geht.Ob mit Stativ,oder ohne-kein Untrschied.Genauso,bei beweglichen Objekten,(ZB fahrender Zug).Also ich weiß das sich das Objekt,bewegen kann,-Beim Pixel Shifting herscht meiner Meinung nach noch viel Aufklärungsbedarf

Hola

Euch ist aber klar, dass lediglich das JPG aus der CAM oder eines mittels (der K-3 II beigefügtem) DCU 5 erzeugtes JPG aus der grossen DNG/PEF-Datei das Pixel Shift Resultat zeigt. ALLES Andere ist lediglich die Ansicht eines einzigen Bildes (wohl das Erste) aus der grossen DNG/PEF-Datei!

Bewegungen sind sehr wohl problematisch, siehe Beispiel (es ist nur 1 Faden, der sich während der Aufnahme (Stativ, 2 Sek. Selbstauslöser) jedoch bewegte es sind NICHT mehrere Fäden )

100%-Crop aus DNG der Cam, mittels ACDSee erstellt (also nur ein Bild, Pixel Shift ging verloren)


100%-Crop aus JPG der Cam, mittels ACDSee erstellt (Resultat mit Pixel Shift)

m@rmor hat geschrieben:Hola

Euch ist aber klar, dass lediglich das JPG aus der CAM oder eines mittels (der K-3 II beigefügtem) DCU 5 erzeugtes JPG aus der grossen DNG/PEF-Datei das Pixel Shift Resultat zeigt. ALLES Andere ist lediglich die Ansicht eines einzigen Bildes (wohl das Erste) aus der grossen DNG/PEF-Datei!
...

Genau so wie m@rmor es schreibt, verstehe ich das bisher auch.

Mit Pixel-Shift habe ich auch erstmals in meinem Leben die Digital-Camera-Utility installiert, um aus dem Pixel-Shift-DNG ein Pixel-Shift-JPG exportieren zu können. Einen anderen Raw-Konverter dafür kenne ich noch nicht, LR kann es definitiv nicht. Bei meinem Vergleich oben habe ich LR nur genutzt, um die erste eingebettete Ebene im DNG exportieren zu können, also als Vergleichsbild ohne Pixel-Shift-Verrechnerei.

Wobei ich noch vergessen habe zu erwähnen, dass man beim Programm DCU 5 bei "Datei->Speichern unter mit Bildverarbeitung" wählen muss, sonst wird ebenfalls nur ein Bild aus der grossen DNG/PEF-Datei verwendet!

Ich persönlich finde, dass das JPG mit Pixel Shift, welches in der Cam erzeugt wird, das bessere Resultat liefert, als das mittels DCU 5 erstellte JPG, dafür hat man bei DCU 5 die Möglichkeit, ein TIFF (16 bit) zu erstellen.

Wobei der Unterschied mit oder ohne Pixel Shift nur sehr marginal ist. Vielleicht habe ich aber auch nur ein ungünstiges Motiv gewählt und bei Studio- Landschafts- und/oder Architektur-Aufnahmen würden die Unterschiede deutlicher zu sehen sein.

Saludos
Marcel

m@rmor hat geschrieben:Wobei der Unterschied mit oder ohne Pixel Shift nur sehr marginal ist. Vielleicht habe ich aber auch nur ein ungünstiges Motiv gewählt und bei Studio- Landschafts- und/oder Architektur-Aufnahmen würden die Unterschiede deutlicher zu sehen sein.

Deckt sich 100% mit meinen, bisher natürlich spärlichen, Erfahrungen. Das von der Kamera produzierte JPG ist zusätzlich nachgeschärft und ich mag nicht beurteilen, welchen Einfluß dies auf das erzeugte JPG hat. (vielleicht sollte ich mal versuchen, das Schärfen abzuschalten...hmmm)

Meiner unmaßgeblichen Meinung nach ist im Moment das Beste an der Pixelshifttechnologie, dass Pentax präsenter in den Medien auftaucht. Das mag sich ändern, sobald das RAW nutzbar wird... Wäre halt nett gewesen, wenn Ricoh sich vor K3-II-Produktankündigung zumindest mit Adobe zusammengesetzt hätte...

Dirk hat geschrieben:... Einen anderen Raw-Konverter dafür kenne ich noch nicht, LR kann es definitiv nicht. Bei meinem Vergleich oben habe ich LR nur genutzt, um die erste eingebettete Ebene im DNG exportieren zu können, also als Vergleichsbild ohne Pixel-Shift-Verrechnerei.

Die dcraw Spezialversion geht nicht? Damit lässt doch ein 16-bit TIF erstellen und dieses bearbeiten.

Zum Fertigwerden mit Bewegung: Wenn die Software auch nur einigermaßen vernünftig geschrieben ist, erkennt sie Stellen des Bildes, die Bewegung beinhalten (durch Vergleich der Einzelbilder) und verwendet an den Stellen nur ein Einzelbild, während an statischen Stellen alle Einzelbilder verwendet werden. Doppelte Fäden oder so sollten also eigentlich nicht auftauchen bzw zu den Kinderkrankheiten (der Software) gehören.

Ranitomeya hat geschrieben:Zum Fertigwerden mit Bewegung: Wenn die Software auch nur einigermaßen vernünftig geschrieben ist, erkennt sie Stellen des Bildes, die Bewegung beinhalten (durch Vergleich der Einzelbilder) und verwendet an den Stellen nur ein Einzelbild, während an statischen Stellen alle Einzelbilder verwendet werden. Doppelte Fäden oder so sollten also eigentlich nicht auftauchen bzw zu den Kinderkrankheiten (der Software) gehören.

Ähmmm... "Vergleich der Einzelbilder" ist jetzt nicht sooo trivial... Es gibt ja kein Objekt "Faden", welches in jedem Bild vorkommt, nur an anderer Stelle.
Es ist eine alles andere als einfache Aufgabe. Auch diese erste Version von dcraw mit PS-Support vergleicht "nur" einzelne Pixelwerte der beiden "Grün"-Aufnahmen und als Fallback auch Blau/Rot (was mir fischig erscheint...). Bei Abweichung wird der lokale Wert einer der Aufnahmen genommen. Insgesamt werden die Grünwerte später gemittelt.

Kinderkrankheit würd ich das nicht nennen (eher Kinderschuhe), denn es ist toll, dass sich jemand die Mühe gemacht hat, sowas überhaupt mal zu programmieren. Das ist wirklich schon nett, ist aber eben einzelpixelbasiert. Irgendwann wird sicher eine gewichtete Umgebung betrachtet und dann vielleicht gar im Frequenzbereich der Bilder gewurstelt...
So, dann hab ich jetzt auch genug geklugschxxst : warten wirs ab.

m@rmor hat geschrieben:Ich persönlich finde, dass das JPG mit Pixel Shift, welches in der Cam erzeugt wird, das bessere Resultat liefert, als das mittels DCU 5 erstellte JPG, dafür hat man bei DCU 5 die Möglichkeit, ein TIFF (16 bit) zu erstellen.

Kann man denn PSR-RAW's nicht auch nachträglich in der Cam entwickeln? Bekommt man dann nicht, wie bei "normalen" RAW's auch, die Möglichkeit in TIFF zu entwickeln?

mfg tc

mesisto hat geschrieben:Ähmmm... "Vergleich der Einzelbilder" ist jetzt nicht sooo trivial... Es gibt ja kein Objekt "Faden", welches in jedem Bild vorkommt, nur an anderer Stelle.

Ist schon klar, dass es mehr als einer Codezeile bedarf, aber gemessen an der Komplexität sonstiger Algorithmen in der Bildverarbeitung ist es sicher einfach. Und, ja, mit "Kinderkrankheiten" wollte ich diese erste Version nicht herabwerten, sondern nur sagen, dass es wohl nur eine Frage der Zeit sein wird.