vor 8 Minuten schrieb Peter Herth:

off-topic

Ach was: ich spekuliere einfach mal, dass in die Wow ein Smartphone eingebaut ist, dann sind die letzten Kommentare rückwirkend on-topic.

🤪

vor 11 Stunden schrieb tgutgu:

eine deutliche Verbesserung von bestehender Funktionalität (z.B. Fotoreihenfunktionen) und des Menüsystems, bzw. Teile davon

Was meinst Du genau, gerade dort ist Olympus mal ganz vorn dabei. Bei Sony z.B gibt es bis heute keine Fokusreihe.

Beste Grüße Matthias 

vor 10 Stunden schrieb finnan haddie:

[neue Kamera eine OM-1 und nicht EM1-IV] Das ist quasi sicher gegeben, das hat OMDS ja so schon kommuniziert. Unwahrscheinlich, das sie in letzter Sekunde noch einen Rückzieher machen.

Reinhard Wagner hat ja zumindest schon angedeutet, dass sie bereits in der Produktion sei und der Verkauf ab Ende März beginnen könne ... ???

Also das würde sonst auch nicht zu den Bildern im Teaser passen, denn es soll ja einen deutlichen Fortschritt geben (RW: der Sensor wird 4x schneller ausgelesen, Rolling Shutter würde dann keine Rolle mehr spielen und das 150-400er könnte einen noch ganz anderen Level erreichen !?)

Aber es wird wahrscheinlich richtig teuer werden (vielleicht gibt es dann ja ein Bundle-Objektiv so dazu, um die Schmerzensschreie etwas zu dämpfen, hoffentlich eines, das ich noch nicht habe); aber teuer wird es, wenn sich auch die Peripherie deutlich ändern würde, wie gemunkelt wird: neuer Speicherkartentyp und wieder ein neuer Akku, der im VK dann sehr viel teurer sei, als der jetzige der EM1Mk3

 

bearbeitet 23. Januar 20223 Jr. von miclindner

vor 4 Minuten schrieb Matthias Föhr:

Was meinst Du genau, gerade dort ist Olympus mal ganz vorn dabei. Bei Sony z.B gibt es bis heute keine Fokusreihe.

Beste Grüße Matthias 

Ich meine die schlechte, unflexible Implementierung. Trennung von HDR und AEB, HDR nur mit mechanischem Verschluss, beide Funktionen mit völlig unterschiedlichen Einstellungsmöglichkeiten. Das gehört zusammengeführt.

Fokusreihen: Einstellparameter tief im Menü versteckt, schnelle Sichtung der eingestellten Parameter oder gar deren Änderung unmöglich.

vor 7 Minuten schrieb tgutgu:

Ich meine die schlechte, unflexible Implementierung. Trennung von HDR und AEB, HDR nur mit mechanischem Verschluss, beide Funktionen mit völlig unterschiedlichen Einstellungsmöglichkeiten. Das gehört zusammengeführt.

Fokusreihen: Einstellparameter tief im Menü versteckt, schnelle Sichtung der eingestellten Parameter oder gar deren Änderung unmöglich.

Ok, Danke

Beste Grüße Matthias 

berechtigte Kritik, man müsste mal ans Ordnen gehen, Sachen für den Stromsparmodus (incl. Einstellmöglichkeiten für Sucher und Monitor) gehören z.B. auch in ein gemeinsames Menü (auch wenn man dann mal Dinge doppelt aufführen muss wie z.B. die Programmierung des schnellen Schlummermodus auf eine Taste)

bearbeitet 23. Januar 20223 Jr. von miclindner

vor 18 Stunden schrieb anselm:

Zum anderen weiß ich nicht, wo überhaupt die Idee herkommt, dass die Olympus-Kameras mit Linux laufen (RW hat das kürzlich mal in einem Nebensatz behauptet, aber nicht belegt). Traditionell verwenden japanische Hersteller – darunter auch Olympus – gerne ein Echtzeit-Betriebssystem namens ITRON, das seit den 1980er Jahren in Japan entwickelt wird und dort für elektronische Geräte sehr weit verbreitet ist. Die Prozessoren in den Olympus-Kameras (MN103 von Matsushita, bei Olympus “TruePic” genannt) werden vom Standard-Linux-Kernel seit ein paar Jahren nicht mehr unterstützt, und dass Olympus/OMDS entweder auf einem ziemlich alten Linux-Kernel sitzenbleibt oder die Unterstützung unabhängig weiterentwickelt, ist wohl eher unwahrscheinlich. Es ist natürlich möglich, dass die aktuelle Kameraentwicklung bei OMDS mit einem anderen Prozessortyp (ARM?) und Linux stattfindet, aber dafür wäre eine bessere Bestätigung interessant als die Kristallkugel von Herrn Wagner.

Sehr interessant, danke für die Info 🙂 Da Du Dich anscheinend näher mit dem Prozessorthema befasst: Was wäre denn der Vorteil der ARM Prozessoren? Wäre das überhaupt möglich das "einfach so" umzustellen (Hardware/Software)?

VG

Christian

vor 19 Stunden schrieb anselm:

wo überhaupt die Idee herkommt, dass die Olympus-Kameras mit Linux laufen

Ich bin nicht der ausgewiesene HW/IT- Fachmann und auch nicht auf der Höhe, was "state of the art" quer durch alle Industrien angeht. Aus meiner Erfahrung mit Automotive-Steuergeräten kann ich sagen, daß immer dann wenn es auf schnelle Verfügbarkeit eines Dienstes angeht, Linux als OS wegen der zu langsamer Startzeiten (d.h. mehrere Sekunden) nicht in Frage kommt. Gleiches gilt für SAT-Receiver, die von der SW-Komplexität einer OM sicher nicht weit voraus sind, wenn überhaupt.

vor 9 Minuten schrieb Karsten:

..wegen der zu langsamer Startzeiten (d.h. mehrere Sekunden) nicht in Frage kommt.

Das sehe ich ähnlich. Ein ARM-Prozessor würde sehr viel Leistung in eine Kamera bringen und in Verbindung mit einem offenen Betriebssystem auch die Möglichkeit bieten, eventuell von Drittanbietern Zusatzmodule zu installieren. Dann könnte man die Kamera softwareseitig erweitern für z.B. bestimmte Schwerpunkte der Fotographie oder einen Cloudservice, der in diesem Thread ja auch schon erwähnt wurde. Aber das ganze steht und fällt dann mit der Akkulaufzeit, Stabilität und Fehleranfälligkeit, sowie der Performance und der Startgeschwindigkeit des Betriebssystems. 

vor 2 Minuten schrieb Bobby_Digital:

Aber das ganze steht und fällt dann mit der Akkulaufzeit, Stabilität und Fehleranfälligkeit, sowie der Performance und der Startgeschwindigkeit des Betriebssystems. 

Schaut euch mal die Zeiss ZX1 an. Der Kaltstart der Kamera nimmt etwas mehr als 20 Sekunden in Anspruch.

vor 2 Stunden schrieb finnan haddie:

Schaut euch mal die Zeiss ZX1 an. Der Kaltstart der Kamera nimmt etwas mehr als 20 Sekunden in Anspruch.

Autsch!

vor 2 Stunden schrieb finnan haddie:

Schaut euch mal die Zeiss ZX1 an. Der Kaltstart der Kamera nimmt etwas mehr als 20 Sekunden in Anspruch.

Genau die richtige Kamera für entschleunigtes Fotografieren 😄

Sodala...ich habe mir heute die WOW Kamera vorbestellt💪

 

vor 5 Stunden schrieb finnan haddie:

Schaut euch mal die Zeiss ZX1 an. Der Kaltstart der Kamera nimmt etwas mehr als 20 Sekunden in Anspruch.

Ja da ist auch Android drauf und ansonsten ist das Gerät eher ein Negativ Beispiel wie man es nicht machen sollte 😀

Fest verbaute Festbrennweite, kann man nur ändern wenn man auf Video umschaltet, dann hat man immer einen 1,48x Zwangs Crop 

Kaum dedizierte Bedienelemente man soll wohl "den Touch" benutzen.

Langsamer Sensor mit entsprechend viel Rolling Shutter

Dafür geht der mechanische Verschluss nur bis  zu 1/1000s

Und es gibt keinen Kartenschacht

 

vor 30 Minuten schrieb systemcam-neu:

Ja da ist auch Android drauf und ansonsten ist das Gerät eher ein Negativ Beispiel wie man es nicht machen sollte 😀

Genau, darum kommt in die WOW auch eine Alexa rein, die braucht nicht viel Platz und übernimmt die Sucherei im Menu.

 

vor 13 Minuten schrieb Eddie:

Genau, darum kommt in die WOW auch eine Alexa rein, die braucht nicht viel Platz und übernimmt die Sucherei im Menu.

 

 "Alexa, mach ein Foto" 😀

vor 47 Minuten schrieb systemcam-neu:

Und es gibt keinen Kartenschacht

Na, dann hat dieCam ja immerhin ein zukunftsweisendes Feature! 😉

Am 24.1.2022 um 12:50 schrieb mindtrust:

Da Du Dich anscheinend näher mit dem Prozessorthema befasst: Was wäre denn der Vorteil der ARM Prozessoren? Wäre das überhaupt möglich das "einfach so" umzustellen (Hardware/Software)?

ARM-Prozessoren haben den Vorteil, dass heute fast jeder sie benutzt. Man findet sie in der Regel in Gestalt von SoCs (“systems on a chip”), die neben einem oder mehreren Prozessorkernen auch noch andere Elektronik enthalten (etwa Video-Hardware – Stichwort “Raspberry Pi”; der extrem populäre Kleinstcomputer basierte ursprünglich auf einem SoC, das Broadcom für Set-Top-Boxen angeboten hat, und das war im Grunde ein Videochip mit einem angeflanschten ARM-Kern). Die Firma ARM stellt selbst keine Prozessoren her, sondern lizenziert fertige modulare Prozessordesigns an Firmen, die dann festlegen können, wie “ihr” SoC tatsächlich aussehen soll (und anschließend irgendwelche Chinesen finden, die ihnen die Chips tatsächlich machen). Das wäre also für eine Firma wie OMDS durchaus interessant. Der Umstand, dass die allermeisten Smartphones heutzutage mit ARM-SoCs laufen und Probleme wie Stromsparen und ein geringes thermisches Budget bei maximaler Rechenleistung da sehr ähnlich sind wie bei Digitalkameras, legt nahe, dass es nicht die dümmste Idee sein muss, beim Entwickeln einer neuen Kamera auf ARM zu setzen.

Was die Software angeht, kommt es natürlich darauf an, was man schon hat und was man haben will. Wenn die Kamerasoftware schön sauber und übersichtlich modular in einer höheren Programmiersprache (etwa C) geschrieben ist, dann ist ein Wechsel der Prozessorarchitektur vermutlich kein unüberwindliches Problem. Wenn man dagegen aus Tradition und für maximale Kontrolle alles in verwickeltem Assemblercode geschrieben hat, schon eher. ITRON gibt es m.W. inzwischen auch für ARM, so dass zumindest daran, wie die Kamerasoftware mit dem Betriebssystem redet, eventuell nicht viel geändert werden muss; will man Linux einsetzen, vielleicht mehr – ich verstehe nach fast 30 Jahren als Softwareentwickler und Trainer im Unix- und Linux-Umfeld zwar ein bisschen was von Linux, habe aber keine Ahnung von ITRON und wie es programmiert wird.

Linux ist durchaus beliebt für “embedded systems” – aus guten Gründen –, aber für eine Kamera möglicherweise doch nicht die allerbeste Wahl. Es hat sich in den letzten Jahren zwar einiges getan am Fundament des Systems, das es für “Elektrokleingeräte” noch besser einsetzbar macht. Instantanes Aufwachen zum Beispiel ist heute kein Problem für Laptops oder Handies, die sich vorher einfach nur schlafen gelegt haben, aber bei einer Kamera würde man sich wahrscheinlich ärgern, wenn man sie ein paar Tage herumliegen lässt und anschließend der Akku leer ist. Für einen Kaltstart aus dem komplett ausgeschalteten Zustand muss man – je nachdem, welche und wieviel Hardware initialisiert werden muss – aber schon noch ein paar Sekunden einplanen. Auch im Echtzeitbereich (im Sinne von “auf externe Ereignisse wird innerhalb einer definierten – idealerweise sehr kurzen – Maximalzeitdauer reagiert”, vermutlich das, was man haben will, wenn man mit Autofokus, Videodaten usw. jongliert) hat Linux große Fortschritte gemacht, aber ich könnte mir vorstellen, dass ein reinrassiges Echtzeitbetriebssystem wie ITRON da noch die Nase vorn hat. Außerdem ist Linux, weil es so allgemeingültig und leistungsfähig ist, auch ziemlich groß und enthält einiges, was für eine Kamera nicht nötig ist; man kann es abspecken, aber eventuell ist es auch geschickter, mit etwas sehr Kompaktem anzufangen und nur diejenigen Sachen dazuzutun, die man dringend braucht. Und natürlich beschäftigt OMDS einen Stall voll Olympus-Entwickler, die vermutlich den größten Teil ihrer Karriere mit ITRON verbracht haben und das System und die Olympus-Kamerasoftware perfekt kennen, während gute Embedded-Linux-Entwickler wahrscheinlich auch in Japan so schwer zu finden sind wie hierzulande – und man darf ferner nicht vergessen, dass ITRON in Japan entwickelt wurde, die ITRON-Gurus selber Japaner sind und die ganze Dokumentation auf Japanisch ist (weswegen es auch fast niemand außerhalb von Japan benutzt), während die Linux-Kultur vor allem auf Englisch basiert und von Amerikanern und Europäern dominiert wird. Diese Kulturbarriere ist ebenfalls nicht zu unterschätzen.

bearbeitet 25. Januar 20223 Jr. von anselm

Am 24.1.2022 um 13:42 schrieb Karsten:

Gleiches gilt für SAT-Receiver, die von der SW-Komplexität einer OM sicher nicht weit voraus sind, wenn überhaupt.

Bei Fernsehern und ähnlichem hat man sich ja heute notgedrungen dran gewöhnt, dass sie etwas Zeit zum Booten brauchen (was kein Wunder ist, denn die meisten “Smart-TVs” laufen heute mit Linux). Auf der anderen Seite hat man da dank 230-V-Anschluss prinzipiell unbegrenzt Strom zur Verfügung – mal abgesehen von den engen Watt-Grenzen, die die EU für den Standby-Modus setzt – und kann darum ungeniert Tage oder Wochen lang schlummern, ohne komplett ausgeschaltet zu sein. Bei Kameras gibt es diese Option nicht wirklich.

Was die Software angeht, hat ein Standard-Linux-System, so wie man es auf einem normalen PC installiert, schon praktisch alles, was ein SAT-Receiver braucht (inklusive Treiber für DVB-S2-Chips, IR-Fernbedienungs-Empfänger und so). Man braucht außerdem nur Software wie “tvheadend”, die das Ganze organisiert. Eine Digitalkamera – vor allem ein Hochleistungsexemplar wie eine OM-D mit Autofokus, Fünf-Achsen-IBIS und ähnlichen trickreichen Hardwarekomponenten – ist davon ein bisschen weiter entfernt. Ich weiß nicht, um wieviel davon sich die CPU tatsächlich kümmern muss (es könnte sein, dass die Komponenten zumindest zum Teil eigene “Intelligenz” mitbringen), aber es ist in jedem Fall nicht komplett trivial.

bearbeitet 25. Januar 20223 Jr. von anselm

Der Instagram Account von Olympus der USA hat sich heute in OM-System umbenannt. 

bearbeitet 25. Januar 20223 Jr. von Bobby_Digital

vor 3 Stunden schrieb anselm:

Eine Digitalkamera – vor allem ein Hochleistungsexemplar wie eine OM-D mit Autofokus, Fünf-Achsen-IBIS und ähnlichen trickreichen Hardwarekomponenten – ist davon ein bisschen weiter entfernt.

Das ist noch milde ausgedrückt.

Vor allem: Den Aufwand, jetzt mal eben 10 Jahre Bestandsentwicklung in einem grundlegend anderen System neu zu implementieren, kann sich vermutlich kein Kamerahersteller leisten.

vor 23 Minuten schrieb Kabe:

Das ist noch milde ausgedrückt.

Vor allem: Den Aufwand, jetzt mal eben 10 Jahre Bestandsentwicklung in einem grundlegend anderen System neu zu implementieren, kann sich vermutlich kein Kamerahersteller leisten.

Panasonic hat es geschafft peu a peu ein wirklich gutes, kontextsensitives User Interface aufzubauen, da musste offenbar keine Bestandsentwicklung neu implementiert werden. Die Preise stiegen dadurch nicht ins Astronomische. Panasonic ist auch gelungen, vieles am Menüssystem von Anfang an recht gut zu machen, weil es offenbar die besseren Usability Experten hatte bzw. vielleicht auch sein Interface intensiver mit Leuten, welche die Kameras auch nutzen, erarbeitet und getestet wurde. An letzterem habe ich bislang bei Olympus erhebliche Zweifel. Aus diesen Gründen ist eine sinnvolle, nutzerfreundliche Überholung naturgemäß aufwändiger. Wenn man viel unterlässt, muss man irgendwann auch einiges nachholen.

bearbeitet 25. Januar 20223 Jr. von tgutgu

vor 47 Minuten schrieb Kabe:

Vor allem: Den Aufwand, jetzt mal eben 10 Jahre Bestandsentwicklung in einem grundlegend anderen System neu zu implementieren, kann sich vermutlich kein Kamerahersteller leisten.

Das glaube ich auch. Assemblercode hat zudem den Nachteil, nicht einfach für eine andere Prozessorarchitektur (z.B. ARM) umprogrammiert werden zu können. In der Programmierebene kann man ja auch nicht mehr compilieren. Extrem schnell reagierende Sytembestandteile (IBIS z.B.) wird man aber wohl kaum ohne Assenemblercode in den Griff bekommen können. Aber wenn das Auslesen des Sensors 4 mal schneller wäre, hätte man wirklich ein paar Reserven für den AF. Und wenn er wirklich eine ISO-Stufe rauschärmer wäre, wäre mein 300/f4 damit sofort in Belichtungszeiten gut zu gebrauchen, die ich bisher manchmal vermissen lassen muß. Erst recht mit 2xKonverter. Aber vielleicht wird dann irgendwann ein 500/f4 oder besser für OMDS sinnvoll, welches das ganze Konvertergehampel vielleicht noch ermöglicht, aber der Einsatz unnötiger werden würde.

Lassen wir uns überraschen.

bearbeitet 25. Januar 20223 Jr. von Trubadour

vor 24 Minuten schrieb Trubadour:

Aber vielleicht wird dann irgendwann ein 500/f4 oder besser für OMDS sinnvoll.

 

Ich wäre auch offen für ein 400-500mm f4.0. 😬

vor 2 Stunden schrieb Trubadour:

Extrem schnell reagierende Sytembestandteile (IBIS z.B.) wird man aber wohl kaum ohne Assenemblercode in den Griff bekommen können.

Das kommt drauf an. Gute optimierende Compiler können gerade für RISC-Architekturen wie ARM mitunter besseren Code erzeugen, als man von Hand schreiben kann – was auch damit zu tun hat, dass von der CPU die Instruktionen oft nicht in der Reihenfolge ausgeführt werden, in der sie im Programm stehen, und die daraus resultierenden Optimierungsmöglichkeiten (und Fehlerquellen …) für Menschen schwer zu erfassen sind.

Das Problem ist ferner, dass die Firmware einer leistungsfähigen Kamera mit vielen Features in reinem Assemblercode allein wegen ihrer Größe wahrscheinlich nicht sinnvoll zu beherrschen ist. Man wünscht sich da eine höhere Programmiersprache, einfach um besser den Überblick zu behalten, wobei es theoretisch natürlich sein kann, dass gewisse Teile davon (aus welchen Gründen auch immer) trotzdem in Assemblercode geschrieben sind.

Wenn ich vor der Aufgabe stünde, ein großes in Assemblercode für ITRON-auf-MN103 geschriebenes Programm in ITRON-auf-ARM neu zu implementieren, würde ich mir anschauen, ob ich MN103-Assemblercode automatisch in ARM-Assemblercode übersetzen kann, so dass er immerhin läuft, selbst wenn er den Prozessor nicht optimal ausnutzt. In den entsprechenden Kreisen kursieren wahrscheinlich fertige Werkzeuge für sowas. Die wirklich zeitkritischen Teile könnte man dann notfalls immer noch handoptimieren.

Und ARM-Prozessoren sind heute biestig schnell, wie die Besitzer von neuen Macs bezeugen können, wo der Intel-Maschinencode (übrigens wie der MN103 eine CISC-Architektur) von bestehenden Programmen transparent in ARM-Code übersetzt wird und man den Unterschied angeblich kaum merkt. Auch wenn man in einer Kamera da wohl Abstriche machen müsste, was die rohe Rechenleistung angeht (verfügbarer Strom und erzeugte Hitze) wäre da von der Performance her wohl schon eine gewisse Luft drin, zumal heute schon poplige Handys ARM-Prozessoren mit 8 Kernen haben und so.

bearbeitet 26. Januar 20223 Jr. von anselm