OM-Software. Ein Rant.

[Erich_Wien]

vor 17 Minuten schrieb verlei:

Ich möchte das Gejammer hier nicht lesen, wenn es heisst:" Das blöde Einstellungs-Programm hat meine Kamera gebrickt! Das geht gar nicht! Ich muss sie einschicken zum Service, aber der hat 3 Monate Wartezeit, weil er von gebrickten Kameras völlig überlastet ist."

So nutzvoll sie auch wäre, Omds wird so eine Software niemals herausgeben. 

Ändert aber nichts daran, dass @kabe einen absolut legitimen Wunsch hatte.
Zwei idente Kameras mit der gleichen Firmeware-Version zu synchronisieren. Was nicht funktionierte.

Man braucht keine offenen Schnittstellen - bloß funktionierende und vollständige Save/Restore-Methoden!

[tgutgu]

Wenn ein Einstellungsprogramm die Kamera „brickt“, ist das Einstellungsprogramm schlecht programmiert. Das heißt aber nicht, dass es nicht möglich und auch nicht sinnvoll wäre, gerade bei komplexen Systemen wie einer OM-1.

Meine Garmin Epix 2 Fitness Smartwatch kann ich nahezu komplett über mein Smartphone einstellen, was ein Segen ist. Es geht also auch bei komplexeren  Geräten.

Es ist eher eine Frage von Kompetenz und Wirtschaftlichkeit.

Ausgangsfrage war ja nicht, ob es ein Einstellungsprogramm geben sollte, sondern warum das Verwenden der Einstellungen einer OM-1 Kamera in einer anderen OM-1 nicht zu den gleichen Einstellungen auf der zweiten Kamera führt, sondern letztlich so viel „durchgeht“, dass man trotzdem umfangreich Hand anlegen muss. *Das* ist unerwartet und sollte von OMDS dringend nachgebessert bzw. zumindest dokumentiert werden, an welchen Stellen es unter welchen Umständen nicht geht.

bearbeitet 27. Februar 2023 von tgutgu

[Gast]

vor 11 Minuten schrieb Erich_Wien:

Ändert aber nichts daran, dass @kabe einen absolut legitimen Wunsch hatte.
Zwei idente Kameras mit der gleichen Firmeware-Version zu synchronisieren. Was nicht funktionierte.

Man braucht keine offenen Schnittstellen - bloß funktionierende und vollständige Save/Restore-Methoden!

Ich habe den gleichen Wunsch schon sehr lange.

Die Save/Restore_Methode funktioniert, nur eben nicht für alle Parameter.

vor 10 Minuten schrieb tgutgu:

Es ist eher eine Frage von Kompetenz und Wirtschaftlichkeit.

Ausgangsfrage war ja nicht, ob es ein Einstellungsprogramm geben sollte, sondern warum das Verwenden der Einstellungen einer OM-1 Kamera in einer anderen OM-1 nicht zu den gleichen Einstellungen auf der zweiten Kamera führt, sondern letztlich so viel „durchgeht“, dass man trotzdem umfangreich Hand anlegen muss. *Das* ist unerwartet und sollte von OMDS dringend nachgebessert bzw. zumindest dokumentiert werden, an welchen Stellen es unter welchen Umständen nicht geht.

Die Kompetenz würde ich Omds in keinem Fall absprechen, wirtschaftlich kann die Entwicklung einer solchen Software wohl kaum sein, da dann auch jede neue Firmware jeder Kamera in jede Save/Restore-Methode eingepflegt werden müsste.

*Das* ist nicht unerwartet, wenn man das Forum verfolgt (und die Bedienungsanleitung bis zum Ende durchgelesen) hat, und dokumentiert ebendort ab Seite 332.

[Kabe]

vor 6 Stunden schrieb verlei:

wirtschaftlich kann die Entwicklung einer solchen Software wohl kaum sein, da dann auch jede neue Firmware jeder Kamera in jede Save/Restore-Methode eingepflegt werden müsste.

Das führt jetzt hier etwas weit, aber solche Sachen lassen sich schon so bauen, dass Daten auf- und abwärtskompatibel wären. Die Kamera nimmt dann beim Einspielen der Settings nur das an, was sie versteht, da braucht es gerade keine separaten Methoden für jede Kamera und jeden Firmwarestand.

Gerade partielle MySets, die eben nur manche Parameter speichern, wären auch mit so etwas abbildbar.

Und wie gesagt: Mein ursprüngliche Anlegen war die Duplizierung der Kamera, und da halte ich nach wie vor für nützlich und legitim.

[Karsten]

Am 27.2.2023 um 14:38 schrieb verlei:

Die Save/Restore_Methode funktioniert, nur eben nicht für alle Parameter.

Eine herstellerfreundliche Umschreibung für "die Methode arbeitet nicht fehlerfrei".
 

Am 27.2.2023 um 14:38 schrieb verlei:

Das* ist nicht unerwartet, ... (und die Bedienungsanleitung bis zum Ende durchgelesen) hat, und dokumentiert ebendort ab Seite 332.

Falsch. Dort ist dokumentiert, welche Einstellungen als Teil von MySets gespeichert werden können. Beim Speichern/Laden (egal über Workspace oder die App) gibt es neben C1..C4 zusätzlich noch die "Aktuellen Einstellungen", welche alle Einstellungen in P/A/S/M/B umfassen. Inklusive derjenigen, sie sich nicht als Teil von MySets speichern lassen (zB viele der Einträge im Schraubenschlüssel-Register). Ansonsten würde der FW-Update Prozess mit Beibehaltung der Kameraeinstellungen ja gar nicht funktionieren.

Wie in #13 von mir erwähnt, hatte ich einen mit FW1.1 reingekommenen Fehler in eben diesem Mechanismus berichtet, den Nils nach Japan weitergemeldet hat. Der wurde bislang genauso wenig korrigiert, wie die diversen Einträge in der Fehlerliste von Reinhard Wagner. OM System hat sich bislang ganz offensichtlich auf das Beheben von kritischen Fehlern konzentriert. Ein nicht unübliches Vorgehen, wenn man Aufwand und Risko für solche Releases minimieren will (oder muss).
 

Am 27.2.2023 um 14:20 schrieb tgutgu:

Es ist eher eine Frage von Kompetenz und Wirtschaftlichkeit.

Die Einführung einer offenen Schnittstelle für Kameraeinstellungen kann für den Hersteller gar nicht wirtschaftlich sein, denn deswegen verkauft er keine einzige Kamera zusätzlich. Eine solche Schnittstelle bedeutet Erstellungsaufwand, laufenden Pflegeaufwand, und nicht zuletzt eine de facto Abhängigkeit nach außen, das aufrechterhalten zu müssen und nicht mehr nach Belieben ändern zu können. Das tut sich niemand freiwillig an.
 

Am 27.2.2023 um 21:14 schrieb Kabe:

Mein ursprüngliche Anlegen war die Duplizierung der Kamera, und da halte ich nach wie vor für nützlich und legitim.

Ich schlage vor, du adressierst die von dir gefundenen Problem-Parameter per PN an Andreas und Nils - so habe ich das auch gemacht. 

[kleiner_Hobbit]

Am 25.2.2023 um 10:32 schrieb Kabe:

die Defaultwerte der MySets waren falsch oder wurden nicht abgespeichert

Das kann ich aus eigener Erfahrung nicht nachvollziehen. Ich habe mir Anfang Dezember eine zweite OM-1 gekauft und konnte mit OM Workspace problemlos die MySets der ersten OM-1 auf die neue Kamera einspielen. Es kam zwar eine Meldung, dass nicht alle Einstellungen übernommen werden können, aber die MySets wurden alle 1:1 übernommen.  Welche Einstelungen nicht übernommen werden konnten habe ich bisher nicht feststellen können, da ist mir bisher nichts aufgefallen.   

[Gast]

vor 7 Stunden schrieb kleiner_Hobbit:

Welche Einstelungen nicht übernommen werden konnten habe ich bisher nicht feststellen können, da ist mir bisher nichts aufgefallen.

Das ist im Prinzip vergleichbar mit den älteren Modellen. Es werden nicht nur die geänderten Werte im Back-up oder den MySets gespeichert. Einige wenige Parameter werden dann beim Wiederherstellen leider auf default gesetzt. Arbeitest Du also bei dieser Auswahl mit den Werkseinstellungen, wirst Du davon nichts merken. Bei der E-M1X ist zum Beispiel "Stabi bei halbgedrückten Auslöser" nach einem Wiedereinspielen der Sicherungen sehr oft "on". Da dies die bevorzugte Einstellung der meisten User ist, merken sie auch nicht, dass das gar nicht gesichert wurde und somit von off nach on wechseln würde.

[tgutgu]

vor 19 Stunden schrieb verlei:

Die Kompetenz würde ich Omds in keinem Fall absprechen, wirtschaftlich kann die Entwicklung einer solchen Software wohl kaum sein, da dann auch jede neue Firmware jeder Kamera in jede Save/Restore-Methode eingepflegt werden müsste.

*Das* ist nicht unerwartet, wenn man das Forum verfolgt (und die Bedienungsanleitung bis zum Ende durchgelesen) hat, und dokumentiert ebendort ab Seite 332.

Bzgl. der Kompetenz wäre ich mir da nicht so sicher, wie die Umsetzung des Firmware Update Prozesses zeigt. Wie Karsten schon geschrieben hatte, beziehen sich die Tabellen ab Seite 332 nur darauf, was in MySets abgespeichert werden kann, was sich möglicherweise davon unterscheidet, was beim Sichern auf dem Smartphone abgespeichert wird.

Die Einstellung der Kamera via externem Programm ist dann wirtschaftlich, wenn diese Funktion dazu führt, dass mehr Kameras verkauft werden bzw. Nutzer dazu veranlasst werden, im System zu bleiben. Zumindest dazu beiträgt. Das würde ich nicht ausschließen. Bei Smartwatches ist das bereits ein wichtiges Feature, warum sollte das bei Digitalkameras nicht auch so sein. Zwei parallel betriebene Kameras in den gleichen Zustand zu versetzen, kann für Vielnutzer ein wichtiges Argument sein.

Eine Alternative wäre es, dieses Einstellungsprogramm kostenpflichtig zu machen. Für 50-100 € würde ich es kaufen.

[elwoody]

Am 27.2.2023 um 23:09 schrieb Karsten:

Wie in #13 von mir erwähnt, hatte ich einen mit FW1.1 reingekommenen Fehler in eben diesem Mechanismus berichtet, den Nils nach Japan weitergemeldet hat. Der wurde bislang genauso wenig korrigiert, wie die diversen Einträge in der Fehlerliste von Reinhard Wagner. OM System hat sich bislang ganz offensichtlich auf das Beheben von kritischen Fehlern konzentriert. Ein nicht unübliches Vorgehen, wenn man Aufwand und Risko für solche Releases minimieren will (oder muss).

Ich sehe in dieser Fehlerliste von RW nur Fehler, die auch ich als Entwickler mit der allerniedrigsten Priorität einstufen würde. Da sind noch ein paar Zwischenabstufungen zu "kritischen Fehlern" drinnen, z.B. solche die die Bildqualität beeinflussen. Die lassen sich halt nur meist nicht so einfach und publikumswirksam vorführen...

z.B. hatte ich in den erste Wochen nachdem die Kamera rauskam einen Fehler gemeldet, bei dem die Kamera in low-light situationen unter bestimmten Bedingungen einzelne Bilder völlig falsch belichtet hat. Der Support konnte den Fehler sogar nach einigem Experimentieren nachstellen und hat diesen an die Entwicklung weitergegeben. Da ich jedoch selten solche Aufnahmen mache, ist der Fehler bisher nicht mehr aufgetreten (bzw. ich weiß nicht, ob er korrigiert wurde).

Dann wäre ja noch das Thema bzgl. dem dynamik Range bei HiRes Aufnahmen. Ich glaube, da hat sich auch nix getan... oder doch?

Das sind Fehler, die ebenfalls nicht kritisch sind, aber im ggs. zu den von RW genannten die Bildqualität teilweise deutlich beeinflussen.

Da wäre es wirklich wünschenswert, einen echten Changelog zu haben.

[Fanille]

es hat doch vor gar nicht so langer Zeit eine "Wunschliste" für zukünftige FW Updates, Features, Kameras udgl. gegeben. Evtl kann man den Punkt dort auch unterbringen mit Verweis auf den Thread.

Früher gab es für einige Geräte SYNC Kabel. Da konnte man in Geräten eine Synchronisation anstoßen und so das eine Gerät klonen.
Wäre doch durch die USB-C Schnittstelle eigentlich durchaus machbar. Eine Kamera auf Receive Settings stellen und von der zweiten die Einstellungen über das Kabel übertragen.

Wobei es heute durchaus auch üblich ist, dass man die Geräte vollständig über den PC Konfigurieren kann bzw. am PC eine Konfigurationsdatei erstellt und diese dann auf das Gerät schickt. Bei meinen Funkgeräten kann ich zB auch die Konfigurationsdatei des Vorgängermodelles importieren oder zwischen Handfunkgeräten und Mobilfunkgeräten importieren und exportieren. Und ja bei den Amateurfunk Geräten mit speziellen Funktionen gibt es einiges einzustellen und das Menü ist vergleichbar lang mit den Kamerasettings.
Das Programm von den Hersteller ist kostenlos - die Alternative von einen Dritthersteller mit zusätzlichen Funktionen und einfacher Bedienung kostet 35€ und ist jeden Cent wert (auch wenn ich es nur sporadisch 1-2x pro Jahr nutze)
Also wie @tgutgugeschrieben hat - kostenpflichtig stellt sicher kein Hindernis dar

Bei den Kameras habe ich das bis heute nicht gesehen.
Wobei ich auch gestehen muss, dass ich die Kamera einmal einstelle und dann ziemlich lang nix mehr Umstelle.

 

[Kabe]

vor einer Stunde schrieb Fanille:

Wäre doch durch die USB-C Schnittstelle eigentlich durchaus machbar. Eine Kamera auf Receive Settings stellen und von der zweiten die Einstellungen über das Kabel übertragen.

Wobei es heute durchaus auch üblich ist, dass man die Geräte vollständig über den PC Konfigurieren kann bzw. am PC eine Konfigurationsdatei erstellt und diese dann auf das Gerät schickt.

Genau so ist es ja bei OM „eigentlich“. Funktioniert halt nur unvollständig.

[anselm]

vor 13 Stunden schrieb elwoody:

Ich sehe in dieser Fehlerliste von RW nur Fehler, die auch ich als Entwickler mit der allerniedrigsten Priorität einstufen würde.

Naja, einige dieser Sachen sind weniger Fehler als vielmehr Regressionen, also Sachen, die früher mal (wenn auch bei anderen Kameras) funktioniert haben und eigentlich immer noch funktionieren müssten. Wir wissen nicht, wieviel Code die OM-1 sich mit, sagen wir mal, der E-M1 III und der E-M1X teilt, aber man kann wohl davon ausgehen, dass die Überschneidung nicht 0% ist. (Mensch und Schimpanse haben ja auch fast 99% ihrer DNA gemeinsam …)

Bei “normaler” Softwareentwicklung ist die Antwort auf das Problem von Regressionen “automatische Tests”. Bei jeder Änderung wird eine Batterie von Tests durchlaufen, die sicherstellen sollen, dass alles noch so funktioniert wie erwartet. Einen Fehler repariert man, indem man erst einen Test schreibt, der dessen Anwesenheit demonstriert, dann das eigentliche Programm ändert, und danach sicherstellt, dass der Test nicht mehr anschlägt. Diese Tests müssen automatisch sein, weil es nicht realistisch ist, mit der Hand jedesmal, wenn Code geändert oder hinzugefügt wurde, Tausende von Tests auszuführen.

Aber wie macht man automatische Tests für eine Digitalkamera? Wenn ich das zu organisieren hätte, würde ich bei der Kamera eine Methode vorsehen, entweder über die USB-C-Schnittstelle oder über eine spezielle Schnittstelle auf der Hauptplatine, die von außen nicht zugänglich ist (könnte auch USB-C sein) simulierte Ereignisse wie Tastendrücke, Drehrad-Operationen usw. einzuspielen und die Anzeige des Monitors bzw. Suchers als “Screen-Dump” auszulesen. Dann kann man auf einem richtigen Computer Testskripte laufen lassen, die Interaktions-Szenarien mit der Kamera durchspielen und prüfen, ob jeweils das Richtige in der Anzeige erscheint. Und/oder man lässt die Firmware der Kamera in einer “virtuellen Maschine” auf dem Computer laufen, so wie man ja auch Handy-Software entwickelt. Wird irgendwas davon gemacht? Hoffentlich. Aber keine Ahnung.

[Karsten]

Das Wissen um Fehler ist eine Sache, die unternehmerische Entscheidung ob und zu welchem Zeitpunkt diese behoben werden, eine andere.

Ganz offensichtlich hat sich OM System bei den bisherigen OM-1 FW Releases auf die Behebung von priorisierten Fehlern beschränkt. Das minimiert den Aufwand für dieses Releases und reduziert Risiko für neue Regressionen.

Eine gerüchteweise angedeutete "FW 2.0 mit neuen Funktionen" wird vermutlich so viele Änderungen (und damit einen erhöhten Testaufwand) mit sich bringen, dass man auch weniger kritische Punkte von der "To-Do Liste"  einarbeiten kann.

[Andreas J]

Ich habe gerade einen Beitrag und zwei Reaktionen darauf (eine sachlich, eine weniger sachlich) ausgeblendet.

Stein des Anstoßes war dieser Satz:

vor 9 Stunden schrieb anselm:

Wir wissen nicht, wieviel Code die OM-1 sich mit, sagen wir mal, der E-M1 III und der E-M1X teilt

Diese Formulierung ist in jeder Hinsicht in Ordnung, solange niemand glaubhaft machen kann, dass er den Quellcode der genannten Kameras kennt.

Etwas anderes wäre es , wenn eine Meinung oder Forderung per „wir“ pauschalisiert wird:

„Wir wollen doch alle, dass eine OM-1X kommt“

Bitte alle entspannt bleiben und nicht alles auf die Goldwaage legen

Gruß
Andreas

[elwoody]

vor 10 Stunden schrieb anselm:

Naja, einige dieser Sachen sind weniger Fehler als vielmehr Regressionen, also Sachen, die früher mal (wenn auch bei anderen Kameras) funktioniert haben und eigentlich immer noch funktionieren müssten. Wir wissen nicht, wieviel Code die OM-1 sich mit, sagen wir mal, der E-M1 III und der E-M1X teilt, aber man kann wohl davon ausgehen, dass die Überschneidung nicht 0% ist. (Mensch und Schimpanse haben ja auch fast 99% ihrer DNA gemeinsam …)

Bei “normaler” Softwareentwicklung ist die Antwort auf das Problem von Regressionen “automatische Tests”. Bei jeder Änderung wird eine Batterie von Tests durchlaufen, die sicherstellen sollen, dass alles noch so funktioniert wie erwartet. Einen Fehler repariert man, indem man erst einen Test schreibt, der dessen Anwesenheit demonstriert, dann das eigentliche Programm ändert, und danach sicherstellt, dass der Test nicht mehr anschlägt. Diese Tests müssen automatisch sein, weil es nicht realistisch ist, mit der Hand jedesmal, wenn Code geändert oder hinzugefügt wurde, Tausende von Tests auszuführen.

Genaugenommen wissen wir ja nichtmal, ob es sich bei diesen Regressionen um Fehler handelt, oder ob die Änderungen in voller Absicht implementiert wurden (von zwei oder drei Punkten mal abgesehen). Wenn beispielsweise etwas im SCP nicht mehr angezeigt wird, dann ist es imho ja durchaus denkbar, daß hier aus Gründen der Übersichtlichkeit eine Funktion geopfert wurde.

(da hätte ich doch dann glatt mal einen Feature-Wunsch: ein konfigurierbares SCP).

Er schreibt da ja auch in der Einleitung recht reisserisch "..einige der übelsten Fails..". Ob es wirklich einer der übelsten Fails ist, wenn beispielsweise ArtFiltereffekte im SCP nicht angezeigt werden? Ist zwar lästig, aber ich meine, da gibt es deutlich schlimmeres.

[elwoody]

Am 28.2.2023 um 11:16 schrieb elwoody:

Ich sehe in dieser Fehlerliste von RW nur Fehler, die auch ich als Entwickler mit der allerniedrigsten Priorität einstufen würde.

Um Mißverständnissen vorzubeugen: es war gemeint "die auch ich, wenn ich Entwickler wäre..."