rodinal

Warum sollte eine Kamera den Temperatursensor an einer Stelle plazieren, auf die manche Fotografen gelegentlich den Zeigefinger legen? Damit die in die exifs schreiben kann: "Vorsicht, kranker Fotograf" oder Fehlermeldungen ausgeben kann im Stil von: "Kurieren Sie bitte ihre Grippe aus, ehe Sie mich das nächste mal anfassen"!?

Nö, denn allein das Wörtchen "sollte" drückt ja aus, dass ich nicht davon ausgehe dass jeder interessierte Fotograf den Rawdigger hat. Ich hab ihn ja auch nicht - vor allem, weil das Ding nicht unter Linux läuft. Dafür stellt der Autor Alex Tutubalin die Grundfunktionen seines Programms kostenlos in der libraw zur Verfügung, und ich kann mir mit ein paar Programmzeilen alle Informationen aus dem Raw holen, die ich möchte. Nun sehe ich hier eine angeregte Diskussion über die richtige Belichtung und speziell ETTR. Die kann man m.E. deutlich besser führen, wenn man neben dem jpeg- auch das Raw-Histogramm sieht. Das bietet der Rawdigger in sehr komfortabler Form. Noch mehr scheinen viele Fotografen am Thema "Rauschen" interessiert zu sein. Dazu werden unendlich viele Bilder ins Netz gestellt, die meist mehr über die Qualität des Bearbeiters und seiner Software aussagen als über das Rauschen der Kamera selbst. Im Rawdigger kann man sich von beliebigen homogenen Flächen des Raw das durchnittliche Nutzsignal und dessen Standardabweichung anzeigen lassen. Deren Verhältnis wird als Rauschen bezeichnet. Man muss also nicht mehr mit Bildern, sondern kann auch mit Zahlen argumentieren- und diese Zahlen sehen fürs mft-System ziemlich gut aus. Eine meiner ersten Erkenntnisse aus der Raw-Analyse war z.B., dass der grösste Teil des Rauschens im fertigen Bild häufig vom Raw-Konverter stammt und nicht von der Kamera. Entsprechende Zahlen habe ich auch hier im Forum veröffentlicht. Verschärft ausgedrückt: Wer sich am Rauschen stört, kann häufig mit einem Konverterwechsel mehr erreichen als mit einem Formatwechsel. Wenn du solche Informationen als "gefährliches Halbwissen" bezeichnest, stehst du damit im Forum sicher nicht allein. Wenn du sie widerlegen, weiterentwickeln oder nachvollziehen möchtest, bietet dir der Rawdigger eine komfortable Möglichkeit. Du kannst das Programm schliesslich kostenlos ausprobieren.

Ich bräuchte für meine Altglasbetände wegen verschiedener Bajonette mindesten zwei Speedbooster - was mir doch ein wenig zu teuer ist. Also experimentiere ich seit einiger Zeit mit dem Pixco-Reducer mit Minolta-Anschluss. Der passt zwar nicht an jede mft-Cam, sitzt aber an der M5.2 perfekt und kostet nur ca. 60€. Unten mal ein Vergleich mit dem Tamron 2,5/90, offen, das erste Bild ohne, das zweite mit Reducer, schief, wie die Bilder aus der Kamera kamen. Der Vergleich zeigt m.E. dreierlei: - Das Tamron ist auch ohne Reducer nahezu perfekt - Der Billigreducer liefert in der Bildmitte eine überaus brauchbare Leistung, verursacht in den Ecken aber eine starke Bildfeldwölbung. Die geht beim Abblenden zurück. Bei entsprechender Billdkomposition kann der Effekt sehr gut zur "Freistellung" genutzt werden. - Beide Bilder wurden im A-Modus aufgenommen. Beim ersten wählte die Kamera 1/80sek, beim zweiten 1/125sek. Die versprochene eine Blende Lichtgewinn wird also nicht geliefert; ca. 1/3 EV bleibt wohl in der zusätzlichen Optik hängen.

Das Histogramm bei der E-M5.2 ist eine Krücke. Es zeigt dir nur das fertige, also je nach Bildstil "optimierte" Bild an, und das hat u.U. mir den Rohdaten nur noch wenig zu tun. Deutlich besser funktionieren die "Blinkies" - also die Überbelichtungsanzeige -, aber auch die sind nicht immer zuverlässig. Eine saubere Kontrolle deiner Arbeitsweise ist daher nur nachträglich mit einem echten Raw-Histogramm möglich. Das bieten in rudimentärer Form die Konverter RawTherapee und PhotoNinja. Eine sehr übersichtliche und ausführliche Darstellung liefert das Tool RawDigger https://www.rawdigger.com/ das eigentlich zur Grundausstattung jedes interessierten Fotografen gehören sollte.

Beim Dual-Iso-Sensor wird der nativen Sensel-Kapazität in der niedrigen ISO-Stufe ein Kondensator parallelgeschaltet, um die Full-Well-Capacity und damit die Dynamik zu erhöhen. Bei der hohen ISO-Stufe schaltet man diese Kapazität ab. Hier findest du das White Paper des Erfinders dieser Technik: http://photonstophotos.net/Aptina/DR-Pix_WhitePaper.pdf Beim ISO-invarianten Sensor fehlt dieser Kondensator. Vorhandensein und Nicht-Vorhandensein eines Bauteils schliessen sich in meiner primitiven Weltsicht leider aus. Zudem scheint sich der zusätzliche Kondensator nicht immer positiv auf die Gesamtleistung des Sensors ausgewirkt zu haben. Bekannt wurde die Technik in der Nikon V1 und den Nachfolgemodellen. Das CX-System wurde von Nikon inzwischen vom Markt genommen - die Kundschaft war von der mässigen Sensorleistung wenig entzückt. Dual-ISO gibts im mft-System bekanntlich inzwischen auch bei der GH5s - und die blamiert sich trotz der grösseren Sensel gegenüber ISO-invarianten Kameras gründlich: http://photonstophotos.net/Charts/PDR.htm#Olympus OM-D E-M1 Mark II,Panasonic Lumix DC-GH5S

In diesem Fall solite dein Dank aber eher an Apple gehen. Wenn die begrüssenwerterweise Python in ihr Betriebssystem integrieren und das Tool pip installieren, sollte das auch anstandslos arbeiten. Und der 443-Fehler bei brew kommt auch aus dem Dilettantenstadel - aus anderen BS lässt sich der Link problemlos anklicken. Wenn deim Mac schon bei solchen Kleinigkeiten versagt, betrachte meinen Tipp besser als nicht gegeben. Eigentlich schade - denn Python ist eine Sprache, die sich traditionell nie um Betriebssystemgrenzen gekümmert hat (und mir deswegen stets sympathisch war).

BSI bringt - wie man bei Sony leicht nachmessen kann - u.a. mehr Rauschen. Wäre kaum mein Ding. Und bei ISO-Invarianz hat der Sensor eine, bei Dual ISO zwei Empfindlichkeiten. Aber unmögliche und widersprüchliche Wünsche gehören ja zum guten Ton.

Irgendetwas scheint mit deiner Pfadsetzung nicht zu stimmen. Das ist schon merkwürdig, denn m.W. ist Python seit der Version 10.8 Teil des Mac-Betriebssystems (von dessen Feinheiten ich sonst wenig Ahnung habe). Da du den Homebrew-Installer erwähnst: Hast du evtl. eine zweite Python-Version nachinstalliert? Das könnte allerdings für ein ziemliches Chaos gesorgt haben.

Falls du meinen Beitrag zufällig gelesen hättest, wäre dir aufgefallen, dass er ETTR als selbstverständlich voraussetzt. Falls du es immer noch nicht verstanden hast: ETTR heisst, die Lichter gerade nicht ausfressen zu lassen. Dazu brauche ich bei kontrastreichen Motiven eine möglichst hohe Dynamik- und die erreiche ich evtl. nur mit einer niedrigen ISO. Bei kontrastarmen Bildern sieht das natürlich anders aus- da kann ich überbelichten. Nur sind die kontrastreichen Vorlagen in der Überzahl- deshalb schrieb ich: In vielen Fällen..... Selbstverständlich nimmt bei Unterbelichtung das Rauschen zu. Das bekommt man mit einem geeigneten Konverter aber in den Griff.

Das Modul pyexiv2 ist nicht installiert. Kannst du nachholen mit dem Befehl: pip install pyexiv2 Pip ist das universelle Installations- und Deinstallationsprogramm der Sprache Python. Geht unter Linux und Win prächtig - unter Mac theoretisch auch. Übergabe per Kommandozeile: Wenn du das Programm "Brennstat. py" genannt hast und das Verzeichnis "/usr/local/Bilder" untersuchen möchtest, gibst du im Terminal ein: Brennstat.py /usr/local/Bilder

Wenn ihr schon programmiert - warum dann nicht mit einer flexibleren Sprache? Ich hatte hier z.B. mal ein Python-Skript vorgestellt, das auch die Brennweiten der Altgläser aus der Stabi-Einstellung auslas und zusätzlich zu den Daten der Systemobjektive grafisch darstellte. Das dürfte mit Shellskripten schwierig werden. Anbei mal ein nahezu selbsterklärender Vorschlag, der Python2.7 und die Module numpy, pylab und pyexiv2 voraussetzt. Man speichert das Skript als ascii-Datei mit der Endung *.py ab und macht es unter unixoiden Systemen ausführbar. Der Erhalt der Einrückungen ist wichtig- sie ersetzen einige der in anderen Sprachen üblichen Klammerschwärme. Anschliessend kann man dem Progrämmchen per Drag'n Drop oder Kommandozeile ein Verzeichnis übergeben und erhält ein Brennweitenhistogramm als Ergebnis. Das Skript sollte unter Linux, Mac und Win laufen- leider nicht unter Android. Brennstat3.pdf

Dann erklär mal, warum Bill Claff ein Allerweltsfaselkopp ist... http://photonstophotos.net/Charts/PDR.htm#Olympus OM-D E-M1,Olympus OM-D E-M1 Mark II

Bei ISO200 habe ich z.B. einen Dynamikbereich von 12EV. Wird das Licht knapp und ich belichte eine Stufe unter, um eine gewünschte Belichtungszeit zu erhalten, habe ich immer noch einen Dynamikbereich von 12EV. Drehe ich stattdessen die ISO auf 400, habe ich noch einen Dynamikbereich von 11EV. Ich bekomme zwar eine Verbesserung in den Schatten, bezahle das aber mit ausgefressenen Spitzlichtern. Je nach Bildinhalt muss ich abwägen, was mir wichtiger ist. Es gibt Grenzwerte, oberhalb derer die Kamera nur noch interpoliert, also bei höheren ISO keine verbesserte Schattenzeichnung mehr bringt. Die liegen bei Oly zwischen 3200 (E-M5.x) und 12800 (E-M1.2). Höhere Werte sollte man nicht einstellen.

Nein. Die aktuellen Oly-Sensoren sind ISO-los, höhere Werte als 200 werden durch Unterbelichten und anschliessendes Aufhellen erzeugt. Je höher die eingestellte ISO, desto geringer ist die Dynamik- daher ist unterbelichten in vielen Fällen empfehlenswert. Anbei mal eine Spielerei mit der M5.2, 2,8/25 mit Reducer (also 2,0/17), 1sek. freihand. Eingestellt war ISO 1600, eine Stufe unterbelichtet - also ISO3200. Das Bild ooc war fast schwarz- es war nämlich stockfinster. Also in RT mal um fünf Stufen aufgehellt - was dann ISO102000 entspricht. Schon hat man ein Gemälde, das kein Artfilter besser hinkriegt. Früher wären bei solcher Aktion die Farben gekippt und die Sättigung eingebrochen. Diese Probleme beseitigen aktuelle Konverter. Wenns also um reine Dokumentation geht, gibts bei den ISO fast keine Grenze mehr.

RT 5.5 erreicht allmählich ein stabiles und bugfreies Stadium. Es hätte getrost die Versionsnummer 6.0 verdient, so gross ist die Zahl der Änderungen. Ich greife zunächst zwei Punkte heraus, die für die mft-Welt besonders bedeutsam sind: Alle Schärfetools - sowohl das "normale" als auch das Nachschärfen nach dem Verkleinern - bieten jetzt die Möglichkeit, homogene Flächen wie den Himmel auszuschliessen. Das geschieht über einen einfachen Schwellwertregler, ohne Masken oder ähnlichen Klamauk, und scheint durchaus effektiv zu sein. Noch tiefer ins System greift das "Dual Demosaicing" ein. Hier werden gleichförmige Strukturen mit dem sehr weich arbeitenden VNG4-Verfahren entwickelt, Details wahlweise mit Amaze, RCD oder DCB. Auch hier teilt man das Bild mit einem Schwellwertregler auf. Die Wirkung ist sichtbar. Zusammen mit dem erstgenanntem Tool bekommt man so Rauschen deutlich besser in den Griff. Wer sich in Zukunft noch über Himmelsgrieseln beklagt, verwendet einfach den falschen Konverter. Der LocalLab-Branch (lokale Farb-Helligkeits-und Kontraständerungen, begrenzt durch parametrische Masken) hat endlich seinen Weg in den Hauptzweig gefunden. Echte Ebenen gibts leider immer noch nicht. Auch 12Bit-Jpegs werden nicht unterstützt, dafür ist endlich eine verlustfreie 32Bit-Tiff-Ausgabe zur Weiterverarbeitung möglich. Dynamikkompression und das Lichter-Schatten-Werkzeug haben sich so stark verändert, dass sie selbst einem altgedienten RT-Nutzer zunächst Probleme bereiten. Ich bezweifele, dass damit eine Abwärtskompatibilität zu älteren Sidecars gegeben ist. Trotzdem scheint das neue RT ein grosser Schritt nach vorn zu sein.