Jump to content

Die PEN, OM-D & E-System Community

Peter Herth

Mitglieder
  • Gesamte Inhalte

    1.834
  • Benutzer seit

  • Letzter Besuch

Reputation in der Community

2.868 Ausgezeichnet

3 Benutzer folgen diesem Benutzer

Persönliche Informationen

  • Wohnort
    Zuikogasse 17, Feldkirchen, Bayern, 85622, Deutschland
  • Einverständnis Bildbearbeitung
    Ja

Letzte Besucher des Profils

3.958 Profilaufrufe
  1. Ich weiss nicht, ob die richtige Nutzung an der Stativmarke hängt, ausser, dass diejenigen, die sich ein teures Stativ kaufen, sich hoffentlich darüber informiert haben. Ja, um die beste Wirkung zu erzielen, sollte man das Stativ richtig einsetzen. Dazu gehört sicherlich, die Mittelsäule nicht unnötig hoch auszufahren. Hier war es aber so, dass ich, wie beschrieben, ganz absichtlich die Mittelsäule weit ausgefahren habe um eben nicht die maximale Stabilität zu haben.
  2. Du hast meinen Beitrag wohl falsch verstanden. Beim HHHR ist ja eine gewisse Bewegung notwendig gewünscht. Deshalb verwende ich mein Stativ* eben mit ausgefahrener Mittelsäule anstatt es auf maximale Höhe einzustellen und dann die Mittelsäule einzufahren. Das ist aber auch nur eine Vermutung, genaue Daten, was die optimale Einsatzweise für HHHR ist, hat ausserhalb von OMDS wohl niemand. *) Gitzo 3530LSV, das dürfte als "gutes" Stativ gerade noch so durchgehen.
  3. Das Problem ist mir gut bekannt. Beim HHHR scheint die Kamera anscheinend anhand der Bildinhalte zu versuchen, die Einzelbilder zusammen zu setzen. Vollmond vor schwarzem Hintergrund reicht da bis zu gewissen Brennweiten nicht aus, da gibt es wohl einen Schwellenwert. Mit 600mm klappt es aber üblicherweise, da sind wohl genügend Pixel vorhanden. Ich verwende dabei immer ein Stativ, wenn man die Stativsäule ausfährt, hat man genügend Bewegung bei der Brennweite.
  4. Stellt denn der Sucher irgendwas dar? Selbst mit Problemen am Objektiv sollten die üblichen Sucheranzeigen zu sehen sein. Aber wenn der Sucher komplett dunkel ist, dann muss man von einem Defekt ausgehen und dann muss die Kamera eingeschickt werden.
  5. Sie können eine App herunter laden, ein Desktop-Programm zur Kamerasteuerung vergleichbar zur App gibt es leider nicht. Um die App kommt OMDS nicht herum, aber wenn es 3rd-Party Support für solche Software gäbe, können viele andere Anwendungsfälle unterstützt werden, die so eben gar nicht oder nur auf Kosten von OMDS unterstützt werden. Man könnte auch eher auf exotische Features verzichten, wenn dies über Speziallösungen möglich wäre. Erstens glaube ich nicht, dass das API sonderlich komplexer ist - die Kommunikation ist bei beiden grundsätzlich die Gleiche, beides geht über HTTP-Requests. Bei der Kamera kämen sicherlich noch mehr Funktionen dazu, aber das ist nicht wirklich Komplexizität. Und schon die Fuktion "Mach ein Foto und schicke es mir" wäre ein großer Gewinn, wenn man die per Script steuern könnte. Es gibt viele Stufen zwischen dem Ist-Zustand und "weitreichendes und dokumentiertes" API. Aber das API exisitert, die App nutzt es. Es bliebe lediglich ein PDF mit einer gewissen Dokumentation frei zu geben (existieren wird da ja intern sowieso). Ich bin übrigens auch professioneller Software-Entwickler und weiss, dass das nicht komplett ohne Aufwand ist, aber wirklich kein Problem, wenn man es nur will. Eine kurze Auflistung der Requests und der Parameter reicht ja schon. Da das ganze per HTTP-Requests stattfindet, muss eine Fehlerbehandlung sowieso stattfinden, security by obscurity ist da eher keine gute Idee. Es reicht auch vollkommen, wenn so ein API im Wesentlichen die Bedienung der Kamera über die Knöpfe wiederspiegelt. Also die grundsätzlichen Funktionen und die Menüfunktionen mit den zur Auswahl stehenden Parametern. Wenn das in der Kamera zwischen UI und Verarbeitung nicht sowieso ordentlich getrennt ist, hat OMDS ein ganz anderes Problem. Irgendwie widersprichst du dir gerade. Ja, ich weiss, es haben schon einige das API Reverse-Engineered. Leider haben diese Personen nie ihre Erkenntnisse mit der Allgemeinheit geteilt, ansonsten wäre diese Diskussikon überfällig. Wäre vielleicht mal eine Idee, ein entsprechende Wiki zu starten, da wären diejenigen aufgerufen, die diesbezüglich schon etwas heraus bekommen haben. Aber wenn das Reverse-Engineering nicht so schwierig ist, warum soll das so für OMDS so ein unglaublicher Aufwand sein, das API, das existiert und von der App genutzt wird, offen zu legen? Da braucht es kein neues API, da gibt es auch keinen besonderen Aufwand, der über das hinaus geht, was man für die App sowieso machen muss. Denn wenn das API sich von Kamera zu Kamera weitgehend ändern würde (warum sollte es?) , dann treibt man ja nur den eigenen Aufwand hoch, die App jeweils daran anzupassen und gleichzeitig alle alten Versionen zu unterstützten. Da wird man schon aus Eigennutz die Zahl der neuen Funktionen klein halten. Und da die meisten Funktionen eher abstrakt sind, ist das auch kein extra Aufwand. Für jede neue Kamera kommen vielleicht ein paar neue Funktionen oder Parameter hinzu. Bei einer OM-1 kann man die Bildrate eben auf 120 fps einstellen, bei einer E-M1 eben nur auf 60.
  6. Also erst einmal würde ich ganz praktische Ergebnisse abwarten, MTF-Diagramme, gerade zwischen unterschiedlichen Herstellern, sind nur ein Anhaltspunkt, die sollte man nicht überbewerten bis man die dazu gehörige Optik in Aktion gesehen hat. Das mit dem Hauptmotiv am Bildrand ist aber bei 9mm schon sportlich, da hat man ja schon sehr starke geometrische Verzerrungen. Die 9mm sind sicher hervorragend auch in Innenräumen, da ist man nahe am Motiv dran, braucht auch die Lichtstärke und die Motive sind eher in der Bildmitte. Für Landschaft etc. kann man ja dann leicht abblenden.
  7. Man sollte bei dem Vergleich der MTF-Kurven aber nicht übersehen, dass Laowa 10/30 verwendet, Panasonic 20/40. Das reduziert den Abstand.
  8. Kostenlos nicht. Aber verglichen mit vielen Marketingmassnahmen auch keine große Investition. Eigene Softwareentwicklung ist viel teurer. Für meine Hue-Lampen konnte ich mir einfach ein PDF mit dem kompletten Protokoll herunter laden und schnell ein Script für die Ansteuerung erstellen. Langfristige Kompatibilität ist begrüßenswert, aber nicht erforderlich. Da kann man zur Not für jede neue Kamera das API anpassen - aber warum sollte OMDS sich den Aufwand machen und nicht einfach das bestehende API weiter verwenden? Und ja, das wäre mal eine Gelegenheit, sich von der Masse abzusetzen, was auszuprobieren. So geht Fortschritt.
  9. Ich weiss nicht, warum du immer wieder mit dem alten SDK ankommst. Aber ich kann dir wiederum antworten, was ich schon mal geschrieben habe: es gab wohl mal eine Windows-DLL mit der man per Kabel die Kamera ansteuern konnte. Keine Ahnung, welche Haken und Ösen da sonst noch dran waren. Ich habe erst Jahre später überhaupt von der Existenz erfahren. Wir reden aber heute über Kameras, die über ein HTTP-API kabellos angesprochen werden können. OMDS müsste gar kein SDK bereit stellen, ein PDF mit der API-Dokumentation wäre schon alles. Dann wäre vor allem auch der Zugriff von anderen Betriebssystemen aus möglich. Zur AIR: ich hätte daran ein deutliches Interesse gehabt, aber in Europa war die Kamera, nicht mal direkt über Olympus, erhältlich. Wenn so offensichtlich nicht versucht wird, das Produkt zu pushen, dann ist das genauso wenig wie das "SDK" von damals ein wirkliches Argument für die heutige Situation.
  10. In der Tat war die Beantwortung einiger Fragen nicht ganz einfache - ich würde sicher einiges mehr nutzen, wenn es denn nur existierte. Und ich kann auch nur den Wunsch nach einem dokumentierten API unterstreichen. Damit würden viele nützliche Möglichkeiten geschaffen, ohne dass OMDS dafür Entwicklungszeit investieren müsste. Was gerade besonders für spezielle Fähigkeiten relevant ist, die nur eine kleine Gruppe von Nutzern betreffen - ich denke da z.B. an die Astrofotografie.
  11. Das 40-150/4 hat auch einen Innenzoom. Es wird nur vor der Verwendung selber ausgefahren.
  12. Das 25/1.2 sowie 40-150/2.8, wenn ich dazu einen Telekonverter haben kann. Es ist verständlich, dass das 12-100 auf fast jeder Liste auftaucht, wenn ich nur ein Objektiv haben dürfte, wäre das auch naheliegend, wenn ich dann nicht nur das 25er wählen würde. Aber bei zwei Objektiven würde ich ungerne auf das 25er und etwas mehr Reichweite beim Tele verzichten, daher meine Wahl.
  13. Hängt etwas davon ab, von welchen Sensoren du redest. Bei den aktuellen 60MP Sensoren, die man bei 35mm Kameras findet, herrscht sicher kein Mangel an Auflösung und man braucht schon sehr gute Objektive um die voll auszunutzen. Umgekehrt, bei den 20 MP, die man bei mFT aktuell hat, haben die Objektive noch viele Reserven - wie man ja auch am HR-Modus sieht. Warum ein Farbfilter, den man vor das Objektiv schraubt, die Auflösung verringern soll, erschliesst sich mir nicht. Es gibt ja genügend Fotografen, die grundsätzlich mit Filtern vor dem Objektiv fotografieren und keine Verringerung der optischen Leistung feststellen.
  14. Danke für die Antwort - wenn die Ergebnisse besser sind, spricht das natürlich sehr für die Expodisk :). Ich habe die Graukarte von Novoflex bin damit sehr zufrieden, nutze sie abar auch nicht andauernd. Ich werde mir die Expodisk mal genauer anschauen :).
  15. Die Expodisk nutzt ja grundsätzlich das gleiche Prinzip. Man misst das einfallende Licht in Farbe und Intensität. Nur würde mich ernsthaft interessieren: warum hältst du die Expodisk für praktischer als eine Graukarte? Du musst ja die Kamera mit Expodisk erst auf die Lichtquelle ausrichten, dann die Belichtung und den Weissabgleich einstellung und dich dann erst dem Motiv zuwenden. Ist das schneller als einfach kurz eine Graukarte vor das Motiv zu halten?
×
×
  • 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