Jump to content

Die PEN, OM-D & E-System Community
Ignoriert

Olympus SDK oder offener API ?


Empfohlene Beiträge

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

Link zum Beitrag
Auf anderen Seiten teilen

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 von Geschütteltnichtgerührt
Link zum Beitrag
Auf anderen Seiten teilen

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.

Link zum Beitrag
Auf anderen Seiten teilen
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.

Link zum Beitrag
Auf anderen Seiten teilen
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 von anselm
Link zum Beitrag
Auf anderen Seiten teilen
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 von Karsten H.
Link zum Beitrag
Auf anderen Seiten teilen
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...

Link zum Beitrag
Auf anderen Seiten teilen
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.

Link zum Beitrag
Auf anderen Seiten teilen
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?

Link zum Beitrag
Auf anderen Seiten teilen
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 von anselm
Link zum Beitrag
Auf anderen Seiten teilen

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.

Link zum Beitrag
Auf anderen Seiten teilen

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

Link zum Beitrag
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

  • Wer ist Online   0 Benutzer

    Keine registrierten Benutzer online.

×
×
  • 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