Jump to content

Die PEN, OM-D & E-System Community

rodinal

Mitglieder
  • Gesamte Inhalte

    576
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von rodinal

  1. Weder exakt ausgerichtet noch vollständig noch olympisch sortenrein:
  2. Die telezentrische Bauweise machte sicherlich zu Zeiten von CCD-Sensoren ohne Mikrolinsen Sinn. Aktuelle Technik dürfte da deutlich toleranter sein. Ausserdem eröffnet der Wegfall des Spiegels die Möglichkeit, Ausgleichslinsen nah vor dem Sensor zu platzieren. Wie das nachfolgende Schema des Pana 1,7/10-25 zeigt, kann dann der Einfallswinkel auch in der Ecke erstaunlich gering sein. Der Preis beim Beispiel ist allerdings die eher gruselige Verzeichnung: https://photonstophotos.net/GeneralTopics/Lenses/OpticalBench/OpticalBench.htm#Data/US20200371325_Example02P.txt,OffAxis,Chief,Pupils,AxisZ,Distortion Dagegen hatten die alten Leica-Linsen ganz andere Strahlengänge, was zu den bekannten Problemen führt.
  3. Das muss nicht sein, denn die Cam hatte ja wie meine E-510 noch einen eingebauten Blitz. Den habe ich gerade im Makrobereich mit manueller Dosierung gern zur Aufhellung benutzt. Scharfstellen mit Altgläsern ging dann auch- schliesslich gabs schon LifeView. Und dann gabs ja noch den genialen IR-Fernauslöser - m.E. ein Fortschritt gegenüber dem Gefummel mit Kabel oder App. Unten mal ein Beispiel mit dem 5,6/80 Rodagon, ooc. Das spezielle Rendering holte wirklich das beste aus dem bescheidenen Sensor heraus.
  4. Als Fernsteuerung mit LifeView unter Linux funktioniert Entangle recht gut- natürlich nur für die vier Cams, die das PTP-Protokoll beherrschen. Witzigerweise meldet sich die E-M5.2 dort als E-M1 an- möglicherweise lässt sich auch Firmware per Copy&Paste entwickeln....
  5. Es muss nicht Olympus sein. Die E-M1.1-3 und die E-M5.2 beherrschen das herstellerübergreifende PTP-Protokoll. Da gibt es einige andere Programme, die auch damit umgehen können und LifeView auf dem Rechner unterstützen- für Linux kommt z.B. Entangle in Frage. Das Protokoll ist übrigens steinalt- schon eine Agfa 1280 oder eine Oly C-1000 konnten es, und bei der Konkurrenz ist auch die Mehrzahl der Modelle damit ausgestattet. Mit einer Universalanwendung kann man also auch etliche andere Cams steuern.
  6. Erschwerend kommt hinzu, dass ACR beim Einlesen des Raws schon eine verdeckte Verstellung des Belichtungsreglers vornimmt (BASELINE_EXPOSURE). Die liegt z.B.bei der E-M5.2 und ISO200 bei 0,5 - entsprechend heller erscheint das Bild. Diese zusätzliche Helligkeit verändert natürlich auch das Histogramm, was den unkritischen Nutzer häufig zu Fehlbelichtungen verleitet. Die wiederum tun dem Rauschen und der Schattenzeichnung gar nicht gut.
  7. Gibts z.B. hier: https://www.dpreview.com/reviews/image-comparison?attr18=daylight&attr13_0=oly_em5iii&attr13_1=olympus_em1iii&attr13_2=apple_iphonex&attr13_3=apple_iphonex&attr15_0=raw&attr15_1=raw&attr15_2=jpeg&attr15_3=jpeg&attr16_0=200&attr16_1=1600&attr16_2=32&attr16_3=32&attr126_0=1&attr126_1=1&normalization=full&widget=1&x=0&y=0
  8. Dabei sollte man aber einbeziehen, dass z.B. bei acht Hires-Aufnahmen auch die achtfache Photonenmenge eines Einzelbildes eingefangen wird. Das entspricht einer Sensorgrösse von ca. 50x37 - also fast echtem Mittelformat. Anders gerechnet: Stellt man bei Hires ISO200 ein, entspricht das einer echten Empfindlichkeit von ISO25. Dabei sollte Rauschen vernachlässitgbar sein und die Dynamik deutlich steigen. Hier geht es aber um eine Firmware, die nicht alle Vorteile dieses Aufnahmeverfahrens zum Tragen bringt.
  9. Ich wette mal, du bist Lightroom-Nutzer und siehst das Rauschen deines Konverters. Ich hab hier mal ein Beispiel gezeigt, bei dem die Raws einer E-M5.1 bei ISO200 in homogenen Flächen extrem wenig rauschten. Bei einer DxO-Entwicklung blieb das geringe Rauschen erhalten- die Bilder waren perfekt glatt. Bei den meisten anderen Konvertern schwankte der Verstärkungsfaktor des Rauschens zwischen zwei und vier- die Bilder waren sehr brauchbar, vor allem wenn die homogenen Flächen beim Schärfen ausmaskiert wurden (was eigentlich jeder Konverter automatisch machen sollte). Lightroom verachtfachte aber das Rauschen, und die Bilder sahen genau so aus, wie du es beschreibst.
  10. Nicht jeder Viltrox-Adapter muss auf Anhieb perfekt funktionieren- Vorsicht deshalb vor allem bei Gebrauchtkäufen. Mein Exemplar war zwar neu, aber trotzdem zu kurz, was die Bildqualität in den Ecken dramatisch verschlechterte. Mit ein paar Unterlegscheiben für Centbeträge liess sich das zwar korrigieren, aber etwas Übung im Umgang mit Messschraube oder Messschieber sollte man schon haben. Wer selbst kocht, hat sicherlich auch einen Bankstein zum Messerschärfen. Damit kann man die Scheiben auch so zurechtläppen, dass eine evtl. Schieflage des Adapters ausgeglichen wird. Der Aufwand lohnt in jedem Fall, denn m.E. sind FT-Objektive im mft-System leider immer noch unersetzlich.
  11. Das Croppen entspricht einer virtuellen Verkleinerung des Sensors. Und dieses neue, kleinere virtuelle Format darfst du dann in deine Tabellen einsetztén, um vergleichbare Werte zu bekommen. Das war übrigens schon bei Ausschnittsvergrösserungen zu Analogzeiten so und stand in jedem besseren Fotobuch.
  12. Wenn ich zum gefühlt zehnten Male einen Wunsch äussern dürfte: Man möge der Cam einen Pixelshift-Modus spendieren, der nur vier um einen vollen Sensel versetzte Bilder schiesst -jeweils hinter einem anderen Farbfilter - und die Raws getrennt und einzeln zugänglich in einem Container speichert. Das ist z.B. bei der Pentax K1 möglich. Der Effekt: Man spart das Demosaicing mitsamt Moire, Artefakten etc. ein und könnte stattdessen die Bilder mit einem simplen Script zu einem Tiff verrechnen. Weiterer Effekt: Ohne Demosaicing sollte die lineare Auflösung sich um den Faktor 1,3 verbessern - sie entspräche also einer 36MPix-Bayer-Cam. Die kürzere Gesamtbelichtungsdauer würde das Risiko von Bewegungsartefakten reduzieren, und was verbleibt, kann dann der Konverter herausrechnen. Das klappt bei der K1 schon sehr gut. Und programmiertechnisch sollte das ganze kein Hexenwerk sein.
  13. Ich weiss nicht, mit welcher Antialiasing-Einstellung sich die dpreview-Leute ihre Bilder betrachten. Bei mir zeigt der 25MPix-Sensor jedenfalls seine Vorteile. Da ihr verlinkter Testaufbau ja netterweise einen Auflösungschart enthält, habe ich mal für GH6 und OM1 den Bereich über der "48" grafisch verglichen - siehe Anhang. Die Pana erkennt hier von den vorhandenen neun Linien noch sieben, die Oly noch sechs. Eine A7c löst an dieser Stelle übrigens auch nur sechs Linien auf. Es fällt aber mal wieder auf, wie schwer sich das dpreview-Team mit ihrer Software tut. Die ooc-Bilder der GH6 bringen jedenfalls Details m.E. besser zur Wirkung als die gezeigten ACR-Entwicklungen. Dabei hatte Pana mal die schlimmste Jpeg-Engine des Marktes... Valide Vergleiche wird man wohl erst sehen, wenn auch andere Konverter die Pana-Raws lesen können. Für mich scheint der 25MPix-Sensor aber ein so grosser Fortschritt zu sein, dass er nach Möglichkeit in meiner nächsten mft-Cam stecken sollte.
  14. Da gibts ein generelles Problem: Selbst billige Grafikkarten haben eigentlich mehr Rechenleistung als teure CPUs. Wer diese Leistung für sein Programm oder sein Betriebssystem nutzen kann, verbucht damit epochale Geschwindigkeitsvorteile. Es gibt aber mehrere Möglichkeiten, die Grafik-Rechenleistung zu einzubinden, und derjenige Hersteller (zur Auswahl stehen AMD, Intel und Nvidia), der es schafft, sein Modell zum Industriestandard aufzuwerten, dürfte in Zukunft von einem Desktop-Monopol profitieren. Hier herrscht fast eine Art Krieg zwischen den Anbietern - glücklicherweise in einer Form, die keine Verletzten oder Toten, sondern allenfalls bankrotte Aktionäre nach sich zieht. Das scheint aber Grund genug für einige merkwürdige Erscheinungen zu sein. Bei Grafikkarten-Beschleunigungen wundere ich mich deshalb über gar nichts mehr.
  15. Dazu müsste man wissen, auf welche Entfernung das Objektiv eingestellt war - es fokussiert nämlich durch Veränderung der Brennweite. Eine anschauliche Darstellung findest du hier: https://photonstophotos.net/GeneralTopics/Lenses/OpticalBench/OpticalBench.htm#Data/US010048474_Example01P.txt,Principals,AxisZ Beim Abbildungsmasstab von 1:1 beträgt die Brennweite noch 37,5mm. Fügst du einen Zwischenring von Brennweitenlänge ein, sollte der ABM dann auf 2:1 steigen, beim zweiten Ring dieser Länge sind es 3:1 - und so weiter...
  16. Eben nicht. Mit dem Schlitten bewegen sich Kamera und Eintrittspupille natürlich auf der Z-Achse im Raum. Mal kurz hingeschmiert: Die Auswirkung der Verschiebung der Pupille von P zu P' auf die Sichtbarkeit von Blatt2.
  17. Die Perspektive ändert sich, wenn sich die Position der Eintrittspupille verändert. Stell dir zwei Blütenblätter vor, die sich gegenseitig verdecken. Kommst du näher ans Objekt heran oder entfernst dich davon, ändert sich der Ausschnitt, den du vom unteren Blatt siehst. Das IST eine Perspektivänderung, die beim Stacken zu den scheusslichen Halos führt. Eine etwas ausführliche Darstellung findest du z.B. hier: https://zerenesystems.com/cms/stacker/docs/troubleshooting/ringversusrail Die Eintrittspupille - das ist das virtuelle "Auge" der Kamera - kann sich leider auch verschieben, wenn du mit dem Objektiv fokussierst. Beim 60er Makro ist das sichtbar, das 30er Makro hat diese Eigenschaft aber nicht - die ideale Stackińg-Linse.
  18. Beim 60er Makro und Abbildungsmasstab 1:1 liegt die Eintrittspupille sogar 30mm hinter dem Sensor(!), die Brennweite beträgt dann noch 37.5mm. Man darf aber auch die Vorteile dieser Bauweise nicht verschweigen. Bei einem auszugsfokussierten Makro mit der Anfangsblende 2,8 bleibt beim Massstab 1:1 davon noch magere f5,6 über. Beim 60er Makro ist es immerhin noch 3,4.
  19. Genau das geschieht in RawTherapee, wenn du das Demosaicing auf "Mono" schaltest. Die Einstellung kann ideal sein zur Reproduktion von SW-Vorlagen, z.B. Negativen. Im wirklichen Leben hast du aber ein Problem: Bei z.B. einer blauen Fläche entsteht ein Punktmuster, weil die roten Sensel davon nichts sehen und deshalb schwarz bleiben. Die blauen Sensel leuchten dafür umso heller, und die grünen werden mittelgrau. Entsprechendes geschieht im wechselnder Reihung bei allen Farben. Daran wird keine Firmware etwas ändern können.
  20. Die Vorteile der im M1 verbauten ARM-Archtektur sind derart extrem, dass wir sie in nächster Zukunft auch für "normale" Rechner erwarten dürfen. Ohne Chipkrise hätten wir sie wahrscheinlich schon. Aufgrund des geringeren Stromverbrauches wäre sie gerade für Laptops ideal. Ich würde mir unter diesen Umständen nichts Neues mehr mit Intel-CPU kaufen, sondern einen Blick auf den Gebrauchtmarkt werfen. Prinzipiell liegst du mit deiner Auswahl nicht falsch. Helicon und Workspace würden eine Gamer-Grafik honorieren (C1, DxO und diverse Topaz-Programme übrigens auch). Der Rest der Programmwelt ignoriert diese Hardware leider und möchte eine schnelle CPU. Alle Grafikprogramme wollen aber viel Speicher- ich bin mir nicht sicher, ob 16GB da nicht zum Flaschenhals werden. Selbst mit dem genügsamen Linux bin ich erst mit 64GB auf der scheren Seite. Überleg aber zweimal, ehe du dir Hardware-Overkill leistest. Ich habemeine besten Stacks jedenfalls mit Zerene auf einen CoreDuo von 2007 gemacht (den kann man immer noch benutzen). Ging langsam, aber die Ergebnisse waren überzeugend.
  21. Das Problem liegt nicht in der DNG-Umwandlung, sondern im Demosaicing. Das war noch nie eine Stärke von LR, ist aber in älteren Versionen noch deutlich schlimmer als heute. Du kannst mal einen Trick versuchen und bei der DNG-Umwandlung Kompatibilität mit LR1 einstellen. Dann wird das im DNG-Konverter enthaltene ACR mit dem aktuellen Demosaicing genutzt und das RAW zu einem "linearen DNG" - das ist eigentlich ein TIFF - entwickelt. Die Dateien werden dann zwar riesig, die Qualität sollte sich aber sichtbar verbessern.
  22. Ich arbeite regelmässig mit einem älteren C1, DxO, und RT. Das finde ich überhaupt nicht chaotisch. Kennt man eine Software, kennt man jede Software. Das Ziel einer Bearbeitung hat man stets im Kopf, und man verschiebt die Regler intuitiv. Funktioniert der eine Konverter unbefriedigend, wechselt man zum nächsten. Wichtig ist m.E. eine Bildverwaltung, die die Sidecars mehrerer Konverter speichert, damit man auch noch nach Jahren seine vergeblichen Versuche vergleichen und evtl. pimpen kann.
  23. Von RawTherapee gibt es auch noch einen Ableger namens ART. Dank des genial gewählten Namens findest du ihn nur, wenn du nach dem Urheber Alberto Agriggio suchst. Ziel von ART sind eine Entrümpelung von RT, eine eingängigere Bedienung und vor allem die Möglichkeit, umfangreich mit Masken zu arbeiten. Einen Blick ist das Programm allemal wert, da es die m.E. unerreichte Detailwiedergabe von RT geerbt hat.
  24. Jedes mir bekannte Raw enthält eine Farbmatrix der Sensorfilter, bei den ORFs gibts zudem Korrekturdaten für die unterschiedlichen Farbtemperaturen. Die reichen aber- genausowenig wie die etwas umfangreicheren DNG-Daten - für eine hochwertige Entwicklung nicht wirklich aus.
  25. Das Raw-Format hat sich seit der E-1 bei Olympus nicht geändert. Bei der OM1 haben sich nur der Herstellername, der Kameraname und die Farbfilter vor dem Sensor geändert. Die Filter müssen erstmal vermessen werden, und die Software ordnet dann die Werte über die Namen dem Kameratyp zu. Schafft ein Programmierer in einem Nachmittag, wenn er die Raws mit Testaufnahmen erstmal hat. Schau dir die Beiträge hier im Forum zum Thema "libraw" an, dann weisst du, wie schnell das geht.
×
×
  • Neu erstellen...

Wichtige Information

Wenn Sie diese Seite nutzen, stimmen Sie den Community-Regeln zu. Wir haben Cookies gesetzt, um die Bedienung des Forums zu verbessern. Du kannst deine Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass du damit einverstanden bist. Mehr Informationen in unserer Datenschutzerklärung