Kundenumfrage Konnektivität / Connectivity – Deine Meinung ist gefragt!

[Peter Herth]

vor 15 Minuten schrieb anselm:

Stimmt, aber davon kommt OMDS ja nicht weg, nur dadurch, dass sie Dokumentation für ihr API veröffentlichen. Die Mehrzahl der Kund:inn:en dürfte erwarten, sich eine offizielle App oder ein offizielles Desktop-Programm herunterladen zu können, und nicht nach Drittanbieter-Kram mit zweifelhaftem Funktionsumfang und fragwürdiger Kompatibilität suchen wollen.

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.

vor 15 Minuten schrieb anselm:

Das ist schön, aber von der API-Komplexität her kann man eine glorifizierte Glühbirne und eine moderne Digitalkamera wohl kaum vergleichen – jedenfalls wenn das Kamera-API mehr können soll als “Mach ein Foto und schick es mir”.

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.

vor 15 Minuten schrieb anselm:

Bitte nicht falsch verstehen: Ich bin der erste, der ein weitreichendes und dokumentiertes HTTP-API für die Olympus-Kameras begrüßen würde. Aber als professioneller Software-Entwickler weiß ich auch, mit welchem Aufwand es verbunden ist, so eine offene Schnittstelle nicht nur zu entwerfen und zu implementieren, sondern auch zukunftsfest zu machen und über einen längeren Zeitraum zu unterstützen. Es ist ja auch niemandem damit gedient, wenn alle möglichen Apps für jede Kamera neu angepasst werden müssen. In der offiziellen App kann man das noch eher abfedern, und vor allem können die App-Entwickler mit den Kamera-Entwicklern Japanisch sprechen. Zumal man zwischen Kamera und offizieller App “dunkle Ecken” im API zulassen kann, die einfach nicht ausgenutzt werden (irgendwelche Kombinationen von Einstellungen, die in der Kamera zu Problemen führen könnten oder so); für Drittentwickler müsste man diese alle dokumentieren oder sogar in der Kamera-Firmware mehr Vorkehrungen treffen, um Fehlersituationen abzufangen, bevor es echten Ärger gibt.

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.

vor 15 Minuten schrieb anselm:

Damit, mal nur so eben ein PDF zu veröffentlichen, ist es halt nicht getan, und selbst das müsste wenn schon nicht von Grund auf neu geschrieben, dann doch debuggt und für den nichtjapanischen Markt übersetzt werden. Es gibt sicher ein paar enthusiastische Fans, die OMDS sowas mit Kusshand abnehmen würden, aber man kann es OMDS eigentlich auch nicht übelnehmen, wenn sie ihre knappen Ressourcen da investieren, wo die Kameras für viele oder alle besser werden und nicht nur für die Hobbyprogrammierer in der OMDS-Gemeinde – soweit ich es überblicke, liegt bei der OM-1 zum Beispiel im AF-Bereich noch das Eine oder Andere im Argen, das repariert oder verbessert werden sollte, und da freuen sich potenziell mehr Leute drüber.

Im übrigen gab es ja auch schon Menschen (auch hier im Forum), die der App und der Kamera bei der Kommunikation zugehört und dadurch auf das API zurückgeschlossen haben. (Einigermaßen vollständige) Dokumentation wäre natürlich netter, aber wenn es nur darum geht, die wesentlichen API-Funktionen zu benutzen, ist das kein Hexenwerk und immerhin besser als gar nichts.

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.

[Lord Helmchen]

Was mir in der App fehlt OI.Share App fehlt ist die Möglichkeit ein Namensschema für die GPS-Tracks vorzugeben. Ich hätte gerne etwas wie <Jahr><Monat><Tag>_<Titel>. Also z.B. "20220514_Wanderung_Deister" Entweder mehrere feste Schemata, oder besser frei konfigurierbar.

 

[Kabe]

Am 13.5.2022 um 19:42 schrieb anselm:

Ein “privates” API zwischen Kamera und eigener App lässt sich schnell zusammenbasteln und es erlaubt beliebige Änderungen nach Bedarf, aber bei einem offiziell veröffentlichten API erwarten die Leute nicht nur, dass es  von Anfang an funktioniert wie beschrieben, sondern auch dass es zu sich selbst und der darauf aufbauenden Software von Drittanbietern kompatibel bleibt, und das für die unbestimmte Zukunft, womöglich von einer Kamera zur nächsten und so weiter.

Ich hoffe schwer, dass die ihre eigene API auch intern nicht mal eben zusammenbasteln, sonder sie so entwickeln, dass das professionellen Ansprüchen genügt. Da ist auch intern mehr als eine Truppe beteiligt.

[tomkn]

Am 10.5.2022 um 20:23 schrieb Hacon:

Das wird seit mehr als 10 Jahren immer wieder gefordert,  aber in dieser Richtung unternimmt wohl kein Kamerahersteller irgendwas. Dabei würde man sich erstens viel Mäuseklavier sparen und könnte zweitens endlich eigene Kennlinien für die Programm- oder die ISO-Automatik festlegen.

Gruß 

Hans

Es würde ja schon eine gut dokumentierte API reichen, die GUI ist dann sicherlich machbar. Vielleicht trotz USB auch als webapp für alle Systeme. Oder vielleicht Mit BT oder als Netzerkgerät. Mit kleiner Datenbank für eigene, kommentierte einstellungssets, ex/importierbar. Hmm. 

 

Wir entwickeln Software die Recht komplexe Hardware über APIs nutzt, bei vernünftiger API, guter Dokumentation und wenn man das Gerät auch hat ist das kein hexenwerk.

 

Grüsse aus dem Norden 

Tom

bearbeitet 15. Mai 2022 von tomkn

[gloana]

Die App muß ja nicht gleich Komplett frei Progamierbar sein. Aber manche Funktionalitäten aus verschiedenen anderen Apps wären schon schön. Belichtungszeiten für Langzeit Belichtungen berechnen und diesen Wert dann gleich verwenden, siehe Nisi app. Oder Belichtungsreihen programmieren wie mit Casable. Oder Intervalle für Timelapse oder.....

Solche Funktionalitäten scheinen mir mit rudimentären längst vergessenen Progamierfähigkeit aus meiner Berufsoberschulzeit (Turbo Pascal) nicht besonders aufwendig. Vieles ist hauptsächlich Zeitsteuerung.

Gruß 

Gloana