Olympus SDK oder offener API ?

[Erhard Karger]

Hallo, 
es gab wohl mal sowas wie einen OLY SDK..... wurde der weiterentwickelt ?
Ich würde gerne etwas programmieren, eine Anwendung mit der man Personen photographieren kann, diesen Personen nach Abschluss einen QR Code in die Hand drückt , der es dann ermöglicht die Bilder von einer Seite runter zu laden.
Oder hat jemand ne Ahnung ob es sowas oder Ähnliches irgendwo zu kaufen gibt ?

Ich meine für die Streetphotographie mit der Oly wäre das ne durchaus brauchbare Anwendung 😉

Ich brauche sozusagen Zugriff entweder direkt auf die Bilddateien oder auf die Namen um das Ganze asynchron zu gestalten. 

Viele Grüße
Erhard

[wteichler]

vor 4 Minuten schrieb Erhard Karger:

es gab wohl mal sowas wie einen OLY SDK..... wurde der weiterentwickelt ?

Nein, wurde eingestellt wegen mangelndem Interesse der Kunden.

[Geschütteltnichtgerührt]

Das wurde seitens Olympus nie richtig gepflegt und wird es auch nicht mehr geben. Wahrschenlich auch nur 16 Bit und mit nix mehr kompatibel.

Aber das, was du möchtest, dafür brauchst du definitiv nicht die Zugriffsmöglichkeiten einer SDK. Schau eventuell in Photobooth-Foren, da wirst du am ehesten fündig.

bearbeitet 14. September 2021 von Geschütteltnichtgerührt

[Karsten H.]

Mit dem Kommandozeilenprogramm Gphoto2 kannst Du unter Linux aus einem Programm oder einem Script heraus die Kamera via PTP fernsteuern und z.B. Bilder machen und auf dem Rechner weiterverarbeiten. Viele Olympusse werden von Gphoto2 unterstützt. 

Eingebaut in ein schickes Programm kannst du so alles weitererealisieren, was du möchtest.

[Erhard Karger]

Danke schön....Beides sind Interessante Ansätze.....  Auf jedenfalls gehe ich beiden nach.

[Peter Herth]

vor 5 Stunden schrieb wteichler:

Nein, wurde eingestellt wegen mangelndem Interesse der Kunden.

Das ist in meinen Augen eine sehr einseitige Formulierung. Ich z.B. wusste nicht mal von der Existenz des SDK, das darüber hinaus nur für Windows in Form einer binären Bibliothek angeboten wurde. Es mag sein, dass das SDK bei denjenigen, die von seiner Existenz wussten, nicht so große Resonanz hatte, aber vielleicht hat man es auch einfach nicht genug beworben.

Insbesondere da wir jetzt über eine Schnittestelle reden, die über http-Requests über Wlan kommuniziert, wäre eine Dokumentation des Kommunikationsprotokolls eine ganz andere Sache und würde zu mindestens einer freien Anwendung dafür führen.

[anselm]

vor 4 Stunden schrieb Karsten H.:

Mit dem Kommandozeilenprogramm Gphoto2 kannst Du unter Linux aus einem Programm oder einem Script heraus die Kamera via PTP fernsteuern und z.B. Bilder machen und auf dem Rechner weiterverarbeiten.

Gphoto2 basiert auf einer Bibliothek (libgphoto2), die man auch direkt in seine Programme einbauen kann, wenn man nicht über die Kommandozeile gehen will. Das ist mitunter effizienter und sicherer.

Der Vorteil einer Programmentwicklung mit gphoto2 bzw. libgphoto2 ist ferner, dass solche Programme dann auch mit Nicht-Olympus-Kameras funktionieren. Selbst wenn man selber nicht vor hat, andere Kameras zu benutzen, vergrößert man so den potenziellen Benutzerkreis, was entweder (im Bereich proprietärer Software) mehr zahlende Kunden oder (im Open-Source-Bereich) mehr mögliche Helfer bedeuten kann – und selbst falls man nur zum eigenen Spaß programmiert: Sollte man wirklich irgendwann auf ein anderes System umsteigen, muss man höchstwahrscheinlich nicht nochmal bei Null anfangen.

Es ist nachvollziehbar, dass Hersteller wie Olympus sich nicht darum reißen, ein SDK zur Verfügung zu stellen. Damit ist immer ein Dokumentations- und Supportaufwand verbunden und die Sache weckt ungebührliche Erwartungshaltungen bei den Anwendern (etwa dass das SDK auch für neue Kameras sofort funktioniert bzw. zeitnah entsprechende Updates erscheinen). Wenn man dann noch verschiedene Plattformen und Sprachumgebungen unterstützen möchte bzw. muss, dann steigt die Mühe exponentiell. Das Ganze geht also ins Geld und wenn sich dann noch scheinbar niemand dafür interessiert, liegt die Sinnfrage nahe.

Wenn ich ein Kamerahersteller wäre, würde ich wahrscheinlich ein REST-basiertes API (zugänglich über WLAN oder USB-basiertes ”Ethernet”) mit den wichtigsten Funktionen dokumentieren und die eigentliche SDK-Entwicklung der Open-Source-Szene überlassen, eventuell strategisch angefüttert mit Leihgeräten o.ä. für Leute, die da die Federführung übernehmen wollen (und den Eindruck erwecken, als hätten sie's drauf). Dann würde sich der Rest höchstwahrscheinlich schon finden, und im Notfall könnte man die Kamera immer mit curl o.ä. fernsteuern, was es auf jeder Plattform gibt.

bearbeitet 14. September 2021 von anselm

[Karsten H.]

vor 6 Stunden schrieb anselm:

vor 11 Stunden schrieb Karsten H.:

 

Gphoto2 basiert auf einer Bibliothek (libgphoto2), die man auch direkt in seine Programme einbauen kann, wenn man nicht über die Kommandozeile gehen will. Das ist mitunter effizienter und sicherer.

Hinter so manchem Programm stecken Programmbibliotheken. Ich schrieb: "aus einem Programm oder einem Script heraus." Selbstverständlich kann dies auch ein Programm mit grafischer Benutzeroberfläche sein. Ich verstehe aber nun gar nicht, warum die Kommandozeile selbst ineffizient und unsicher sein soll. Das ist vielleicht bei Windows so, wo die Kommanozeile ja seit langem nur noch ein Fake (Emulation) ist. Ich spreche nur für linux-type Systeme.

bearbeitet 15. September 2021 von Karsten H.

[Peter Herth]

vor 9 Stunden schrieb anselm:

Wenn ich ein Kamerahersteller wäre, würde ich wahrscheinlich ein REST-basiertes API (zugänglich über WLAN oder USB-basiertes ”Ethernet”) mit den wichtigsten Funktionen dokumentieren und die eigentliche SDK-Entwicklung der Open-Source-Szene überlassen, eventuell strategisch angefüttert mit Leihgeräten o.ä. für Leute, die da die Federführung übernehmen wollen (und den Eindruck erwecken, als hätten sie's drauf). Dann würde sich der Rest höchstwahrscheinlich schon finden, und im Notfall könnte man die Kamera immer mit curl o.ä. fernsteuern, was es auf jeder Plattform gibt.

Nach allem, was ich bisher herausfinden konnte, basiert die Kommunikation von oiShare auf einem REST-API per http. Das zu dokumentieren würde vollkommen ausreichen. Es wäre mir sogar viel lieber als irgend eine intransparente Bibliothek, gegen die man linken muss. Damit könnte man dann ohne weitere Unterstützung durch Olympus eine Software auf einer beliebigen Plattform entwickeln. Es ist mir nach wie vor unverständlich warum, auch nach vielen Nachfragen, das abgelehnt wurde. Eine gute Unterstützung durch Software wäre ein weiteres Verkaufsargument. Solch eine Dokumentation braucht auch nicht aufwändig zu sein, schon alleine eine Auflistung aller Funktionen mit ihren Parametern wäre ausreichend. Als ich damals meine ersten Hue-Lampen kaufte, konnte ich mir ein PDF mit dem zugehörigen API herunterladen und schon nach einer Stunde hatte ich ein einfaches Ansteuerscript am laufen...

[Oggo]

Zur air gab es wohl mal ein PDF, leider nicht mehr auffindbar. 

https://stackoverflow.com/questions/32046784/is-there-an-http-code-example-for-the-olympus-air-opc

[anselm]

vor 4 Stunden schrieb Karsten H.:

Ich verstehe aber nun gar nicht, warum die Kommandozeile selbst ineffizient und unsicher sein soll.

Das kommt drauf an, wie genau man aus seiner Software ein untergeordnetes Kommandozeilenprogramm aufruft. Wenn man sich ungeschickt anstellt, ist zum Beispiel oft noch eine Shell im Spiel, die ein Angreifer dazu bringen kann, Dinge zu tun, die im ursprünglichen Programm nicht vorgesehen waren. Ob und wie sehr das ein Problem ist, hängt natürlich davon ab, wie und wo das Programm läuft und wie allfällige Daten, die ein Benutzer kontrollieren kann, in die Kommandozeile eingebaut werden. Es ist also eher eine allgemeine Anmerkung als eine, die auf diese spezielle Anwendung abzielt. Wenn man nur aus einem lokal laufenden Programm heraus gphoto2 mit festen Parametern aufruft, ist das sicherheitstechnisch vermutlich relativ unbedenklich; wenn man aus einer im Internet offen zugänglichen Web-Anwendung heraus ein externes Programm mit Parametern aufruft, die von einer Benutzereingabe im Browser abgeleitet werden, sieht die Welt schon völlig anders aus.

Für ein externes Kommandozeilenprogramm muss unter Linux mindestens ein neuer Prozess erzeugt werden (möglicherweise mehrere). Das geht zwar ziemlich flott, ist aber auf jeden Fall ineffizienter als innerhalb des ursprünglichen Prozesses in eine dazugelinkte Bibliothek zu verzweigen. Auch hier gilt, dass es drauf ankommt, ob das ein Problem ist und wenn ja, wie schlimm. Wenn man etwas hundertmal in der Sekunde macht (bei einem Foto-Kiosk wahrscheinlich seltener der Fall), dann fällt es eher ins Gewicht, als wenn es nur alle paar Minuten gebraucht wird.

Zum Schluss sollte man auch nicht außer Acht lassen, dass Kommandozeilenprogramme nur eingeschränkte Möglichkeiten haben, mit ihrem Aufrufer zu kommunizieren. Man kann Daten über die Kommandozeile, die Prozessumgebung und/oder die Standardeingabe an das Kommandozeilenprogramm schicken, sich dessen Exit-Code anschauen und ggf. dessen Standardausgabe und/oder Standardfehlerausgabe analysieren, was mühsam und fehleranfällig sein kann (etwa wenn das Ausgabeformat von der eingestellten Lokalisierung abhängt, Stichwort “ls -l”). Programmbibliotheken haben oft differenziertere, praktischere und effizientere Wege, Erfolgs- und Fehlermeldungen oder Daten an ihren Aufrufer zurückzuliefern, und erlauben so die Erstellung robusterer Software.

[Karsten H.]

vor 3 Stunden schrieb anselm:

Das kommt drauf an, wie genau man aus seiner Software ein untergeordnetes Kommandozeilenprogramm aufruft. Wenn man sich ungeschickt anstellt, ist zum Beispiel oft noch eine Shell im Spiel, die ein Angreifer dazu bringen kann, Dinge zu tun, die im ursprünglichen Programm nicht vorgesehen waren. Ob und wie sehr das ein Problem ist, hängt natürlich davon ab, wie und wo das Programm läuft und wie allfällige Daten, die ein Benutzer kontrollieren kann, in die Kommandozeile eingebaut werden. Es ist also eher eine allgemeine Anmerkung als eine, die auf diese spezielle Anwendung abzielt. Wenn man nur aus einem lokal laufenden Programm heraus gphoto2 mit festen Parametern aufruft, ist das sicherheitstechnisch vermutlich relativ unbedenklich; wenn man aus einer im Internet offen zugänglichen Web-Anwendung heraus ein externes Programm mit Parametern aufruft, die von einer Benutzereingabe im Browser abgeleitet werden, sieht die Welt schon völlig anders aus.

Für ein externes Kommandozeilenprogramm muss unter Linux mindestens ein neuer Prozess erzeugt werden (möglicherweise mehrere). Das geht zwar ziemlich flott, ist aber auf jeden Fall ineffizienter als innerhalb des ursprünglichen Prozesses in eine dazugelinkte Bibliothek zu verzweigen. Auch hier gilt, dass es drauf ankommt, ob das ein Problem ist und wenn ja, wie schlimm. Wenn man etwas hundertmal in der Sekunde macht (bei einem Foto-Kiosk wahrscheinlich seltener der Fall), dann fällt es eher ins Gewicht, als wenn es nur alle paar Minuten gebraucht wird.

Zum Schluss sollte man auch nicht außer Acht lassen, dass Kommandozeilenprogramme nur eingeschränkte Möglichkeiten haben, mit ihrem Aufrufer zu kommunizieren. Man kann Daten über die Kommandozeile, die Prozessumgebung und/oder die Standardeingabe an das Kommandozeilenprogramm schicken, sich dessen Exit-Code anschauen und ggf. dessen Standardausgabe und/oder Standardfehlerausgabe analysieren, was mühsam und fehleranfällig sein kann (etwa wenn das Ausgabeformat von der eingestellten Lokalisierung abhängt, Stichwort “ls -l”). Programmbibliotheken haben oft differenziertere, praktischere und effizientere Wege, Erfolgs- und Fehlermeldungen oder Daten an ihren Aufrufer zurückzuliefern, und erlauben so die Erstellung robusterer Software.

Wie, wenn nicht via gphoto2, wird denn auf die Bibliothek libgphoto2 zugegriffen?

[anselm]

vor 2 Stunden schrieb Karsten H.:

Wie, wenn nicht via gphoto2, wird denn auf die Bibliothek libgphoto2 zugegriffen?

Indem man ein anderes Programm benutzt, das gegen die iibgphoto2 gelinkt ist, oder selber eins schreibt. Debian GNU/Linux 11 zum Beispiel enthält außer gphoto2 mehr als 20 andere Softwarepakete, die die libgphoto2 verwenden. Darunter auch z.B. eins, das die Funktionen der libgphoto2 in Python zugänglich macht (für Leute, die ungern in C programmieren).

bearbeitet 15. September 2021 von anselm

[Karsten H.]

Interessant! Das Python Interface ist allerdings nicht Bestandteil der libgphoto2. Ob man es nun via gphoto2 oder das gphoto2 Python-Modul anspricht, ist natürlich gerade bei Python, welches ich für die obige Ursprungsanforderung verwenden würde, beides möglich. Immerhin schön, dass es das Modul gibt.

[tomkn]

Moin, moin

 

Von datenschutzrechlichen Anforderungen mal abgesehen sehe ich da 2 Anforderungen :

1) Bild von Kamera, speichere es auf dem Server, generiere einen Link, bette den in einen QR Code ein und drucke ihn / sende ihn an ein Smartphone.

2) Und dazu eine Webanwendung die nach Aufruf eines Links das Bild anzeigt.

 

Wenn die Bilder im Zugriff sind, sollte 1 kein Problem sein, QR Code Generatoren / Libs gibt es reichlich.

Bei 2 sieht es schon anders aus. Vielleicht gibt es ja Webspace Anbieter (a la Dropbox, ...) bei denen die Linkgenerierung zum Zugriff auf Ordner / Files dokumentiert ist,

dann braucht es gar keine Webanwendung.

 

Grüße

tom

[Kabe]

2) ist ein Nichtproblem… der QR-Code encodiert direkt die URL, unter der das Bild angezeigt wird.

[Erhard Karger]

tja wäre schon cool so ne Schnittstelle. Vielleicht ist ja die neue Firmenführung offener für sowas, zumal das wieder einen Markt erschließen würde.....Das was ich gerne hätte wäre dass die Kamera per Bluetooth mit dem Handy in Kontakt ist. (Hab mal sowas im Browser gemacht für einem Puls Brustgurt. da gibt es eine LowEnergy Schnittstellen.

Ich konnte dann aus Chrome heraus von ner selbst gefrickelten Website meinen Puls abrufen.

Angenommen die Kamera würde statt dem Puls die aktuellen AufnahmeDaten schicken.....EinTraum was man da alles machen könnte .Bildname Zeit Man könnte sofort , zusammen mit den GPS Daten des Handies einen Katalog aufbauen etc.   Wäre insofern interessant wenn man die Kamera besser über App mit dem Handy Connecten könnte dass sich die Kamera aufs Photographieren und das Handy aufs verwalten spezialisiert. Wenn ich das heute mit der Olympus Share Software mache hab ist das WLAN erstmal für die Kamera besetzt. 

 

[JKoch51]

Am 14.9.2021 um 19:54 schrieb wteichler:

Nein, wurde eingestellt wegen mangelndem Interesse der Kunden.

Zu Zeiten der Camedia-Kameras gab es wohl Schnittstellen, die von findigen Programmierern genutzt werden konnten. Ich hatte damals für meine Camedia C5050 ein kleines Programm geladen, womit ich alle Funktionen "fernsteuern" konnte und das Bild gleich in den Rechner geladen wurde.

Mit Erscheinen der ersten PEN-Kameras wurde dies nicht mehr angeboten, leider!

Hier der Link:

http://www.sabsik.com/Cam2Com/

 

Gruß Jürgen

[Oggo]

Der Hinweis von Jürgen ist doch schon ein Anfang, die OM-Ds sind wohl ähnlich redselig wie die air. 

Mal kurz das WiFi der 10.1 angeworfen, verbunden und mit get_commandlist.cgi gefragt was die Kleine so kann.... 

Hilft das weiter? 

Lg 

[Erhard Karger]

Danke Oggo ich werd mich auf jeden Fall damit beschäftigen . Falls ich Fragen hab nerv ich Dich einfach mal direkt 😉