[atmocontroller] Betrieb unter Windows

  • Matthiaz
    ...mmh wäre es nicht sinnvoll wenn man versuchen würde den innersten Teil der Berechnung so in Code zu verpacken den man sowohl mit einem C/C++ Compiler für Linux als auch für Windows kompilieren kann?
    Würde ja sicherlich einiges an Arbeit sparen finde ich - wenn man für diesen doch recht aufwändigen Teil ein und den selben Source sowohl für Linux als auch Windows verwenden könnte?


    Quote

    Das ist eigentlich kein Problem. Die Berechnung macht einen Screenshot und wertet Pixelpunkte (PPK) aus, deren Position beliebig anpassbar ist. Dafür wird der Monitor in vertikale und horizontale 1-Pixel-Streifen unterteilt und ausgewertet. In meiner Version sind es 1000 Punkte pro Kanal, 40 equi-distante 1-Pixel Streifen, von denen jeweils 10 für die Berechnung genutzt werden. Auf gut deutsch: 10 Streifen a 100 Pixel pro Kanal. Um bei 16:9 Filmen den Schwarzen Rand zu entfernen kann man einfach einen Offset setzen. Das wäre bei mir pro Kanal eine Code-Zeile mehr...


    mmh die Idee mit den Screenshot ist IMHO doch recht CPU belastend - ich überlege da ja eher in die Richtung ein Modul für den VideoLan Player zu bauen - wo man jedes Frame zugereicht bekommt - damit hätte man auch nicht die Probleme mit den Streifen bei 16:9 oder anderen nicht 4:3 Seitenverhältnissen.
    Was meiner Ansicht nach aus einem Screenshot heraus nur schwer ermittelt werden kann - und diese Streifen "festwegzukonfigurieren" ist auch keine sinnvolle Lösung, da die Breite der Streifen ja doch recht häufig unterschiedlich ist - und da möcht ich nicht für jeden Film die Parameter von AtmoLight anpassen müssen.


    Der Nachteil wäre zwar der das einem AtmoLight nur während der Videowiedergabe zur Verfügung steht - aber das wäre für mich Ok.


    Ein weiterer Grund ist ja dass die Screenshot Methode es notwendig macht die Videoausgabe des Players komplett durch Software zu schleusen und damit die CPU zu belasten - nur damit ein Screenshot funktioniert. Während VLC ja normalerweise die Videoausgabe via Overlay erledigt - d.h. Videoskalierung und Teile der Aufbereitung laufen sonst in Grafikkarte ab...


    Von aus diesen Gründen wäre es für mich am sinnvollsten wenn man die Steuerungssoftware wirklich Modular aufbaut - so dass man die Quellen in logische Einheiten teilt - d.h. z.B.


    1.) - Bildbeschaffung - z.B. Screenshot anfertigen - simples Downscale (ohne Interpolation oder ähnliches) (durch Pixel weglassen - dürfte doch recht schnell gehen)


    2.) - Umrechnung in anderes Farbmodell


    3.) - Funktion die aus einem Bereich von Pixeln die Steuerwerte (Duty Cycles?) fürs AtmoLight ermittelt


    4.) - Funktionen für den Zugriff auf die Hardware (serielle Schnittstelle)


    Wobei die Funktionsblöcke 2) und 3) eigentlich cross plattform kombatibel zu bauen sein müssten?



    Igor

  • Hi,


    ja da gehe ich mit dir konform.


    Die schwarzen Steifen werden beim originalcode nicht beachtet, weil es den Parameter "Schwarzgrenze" gibt. Der legt fest, dass Pixel mit einem Helligkeitswert kleiner "Schwarzgrenze" gar nicht mit einbezogen werden, das Verfahren hat sich bewährt, unabhängig von den Kinobalken.


    Schau dir doch mal den code vom atmo-plugin an, da ist das schon beinahe so modularisiert wie du es dir vorstellst...Fragen kann ich dir dazu, wie gesagt, gerne beantworten.


    Grüße,
    Simon

  • Ja, es ist schon sehr modular. Allerdings benötigt man für die Fensterverwaltung (bzw. Dialogboxen) das MFC-Set von Microsoft, daher ist die Oberfläche so nicht in Linux einsetzbar.


    Auch die Ausgabe erfolgt über Windows-Handling des seriellen Ports, also auch nicht einfach umsetzbar.


    Austauschbar sind allerdings - soweit die Parameternamen übereinstimmen - z.B. meine Funktionen für konstanten Farbwechsel, oder auch die Farbumrechnung und Aufbearbeitung.



    Momentan bin ich grade dabei, die ganzen parallelen Threads zu reduzieren, um z.B. die Ausgabe nur laufen zu lassen, wenn sie benötigt wird. Dann kann man die Ausgabe auch zielgerichtet und vor allem exakt triggern, da sich evtl. Pausen nicht überlagern.

  • Soa, hier mal wieder eine neue Version. Grobes Changelog:
    [list=1]
    [*]Einstellungen werden in der Registry gesichert
    [*]Nur noch ein Thread bei Live-Bild
    [*]Berechnungsparameter sind anpassbar (Neustart von AtmoWin erforderlich!)
    [/list=1]


    Es gibt allredings auch ein paar kleinere Bugs, vor allem beim COM-Port wechsel muss AtmoWin neu gestartet werden. Dafür bleiben die Einstellungen erhalten. Morgen werde ich noch den Weißabgleich in die Registry einbauen, dann sollte aber auch alles wichtige gesichert bleiben.


    Viel Spass!

  • Hallo,


    Werte werden gespeichert - klappt
    Comportauswahl - klappt
    Minimieren - klappt


    ABER:
    Die untere Röhre wechselt immer von alleine von weis auf grün als Fade von ca. 2 sec.(wenn anderen Farben dargestellt werden soll, kann es auch schonmal von blau nach rot faden)
    Die Bildabfrage dauert bald ne Sekunde bei mir, egal was ich bei ms eintrage.
    Ich teste mit VLC und dem Atmotestfilm, der hier auch im Download zu finden ist.
    z.B. ist Vollbild blau und als nächstes kommt rot.
    Dann kommt rot und blau leuchtet noch min.1 sec nach erst dann wird nach rot gewechselt.

    Vice President Logistics and Materials Handling of the first 40" TFT Sammelbestellung and Atmolight I + II + III

    The post was edited 1 time, last by Papsi ().

  • Hi Matthiaz,


    hab grad mal kurz in die Sourcen der .22 Version reingeschaut.


    Hab ich das richtig verstanden:


    o Bild wird ausgelesen
    o nach der Pixelstreifenmethode in HSV umgewandelt
    o HSV Histogramm über H berechnet
    o Maximum von V gebildet
    o jede Sekunde ausgebenen, und zwischendrin linear gefadet


    Stimmt das ungefähr so?


    Grüße,
    Simon


  • Ausgabe ist eigentlich durch Abfrageintervall festgelegt. Eine Farbe wird also festgelegt, dann dauert es Interpolationsschritte * Interpolationspause, bis Farbe angezeigt wird, und dann ist die Pause "Bildabfrage" dran. Erst danach wird wieder wieder eine neue Farbe festgelegt.


    Quote

    Original von Papsi
    ABER:
    Die untere Röhre wechselt immer von alleine von weis auf grün als Fade von ca. 2 sec.(wenn anderen Farben dargestellt werden soll, kann es auch schonmal von blau nach rot faden)


    Ich habe nur 2 Röhren, daher ist ein Testen auf korrekte Funktion der beiden Kanäle Oben/Unten schwierig. Ich schaue mir das aber mal an.


    Quote

    Original von Papsi
    Die Bildabfrage dauert bald ne Sekunde bei mir, egal was ich bei ms eintrage.
    Ich teste mit VLC und dem Atmotestfilm, der hier auch im Download zu finden ist.


    Sicher, dass Du Interpolationsschritte und Interpolationspause auch reduziert hast...? Bei mir klappt der Film nämlich ohne Verzögerungen, wenn ich die Einstellungen niedrig setzte.

  • So, jetzt wird auch der Weißabgleich gesichert. Des weiteren werden für die Farbwechsel die Parameter gertrennt gesichrt.


    Leider konnte ich bisher den Bug mit dem fehlerhaften unteren Kanal nicht lokalisieren. Evtl. komme ich da heute Abend zu.


    /€dit: Hab leider bei der Kanalzuweisung etwas verhauen... Komm aber auch erst morgen wieder zum programmieren... :schiel

  • mal ne andere Frage (ich hoffe ich stör euch nicht aber ich wollte keinen neuen thread deswegen aufmachen):


    Hat jemand von euch den Atmo schon unter Windows mit einem USB-Seriell Adapter ausprobiert??


    Die Programmierung von Microcontrollern mit herkömmlichen Boards dauert ja unakzeptabel lange (ich weiß gibts auch schon neue Lösungen aber das ist ja hier nicht Thema).
    Jedenfalls gibts da doch einige Probleme und ich kann mir nicht vorstellen das die Kommunication problemlos läuft, allerdings hab ich am Laptop leider keine Serielle Schnittstelle...


    Gibts da Möglichkeiten oder soll ich lieber die Hoffnung aufgeben?

  • eigentlich off topic.


    Aber es ich habe gute Erfahrung mit USB-Seriell Adaptern mit Prolific Chipsatz. Ich habe sehr schlechte Erfahrungen mit Billigadaptern.


    Sprich: es geht auch über USB, nur darf am Adapter nicht gespart werden.


    Matthiaz : Werden die die Funktionen in Module ausgelagert? Ich würde gerne den Weißabgleich für die Atmo v3 ;-) in das Weißabgleichfenster einbauen.


    Gruß
    swifty

  • Quote

    Original von swifty99
    Matthiaz : Werden die die Funktionen in Module ausgelagert? Ich würde gerne den Weißabgleich für die Atmo v3 ;-) in das Weißabgleichfenster einbauen.


    Hört sich gut an. :-) Die einzelnen Bestandteile sind alle als Funktionen in der Datei main.cpp. Mit ein wenig Arbeit könnte man mit Sicherheit auch Module daraus bauen. Wäre sogar recht sinnvoll alleine der Übersicht wegen... ;-)


    Weißabgleich wird in einer eigenen Dialogbox geführt, wo im Hintergrund jede Sekunde eine statitsche Ausgabe als Thread abläuft. Gescpeichert wird erst, wenn man "Speichern" drückt. Da kannst Du Dich einfach zwischenhängen, evtl. sogar alt und neu über einen Schalter wählbar machen.
    Du wirst aber eine zusätzliche Ausgabefunltion schreiben müssen (eher alte kopieren, Anfangsstring und evtl. Ausgabe anpassen), um die Parameter übermitteln zu können. Wenn Du wirklich Spass daran hast, kannst Du die Eingabe ja auch noch per Schiebe-Balken realisieren...


    Ich poste heute Abend mal eine aktulle Version+Sourcen, dann kannst Du Dich daran probieren. Ich hoffe, dass ich noch den Fehler im unteren Kanal finden kann.


    Ich programmiere übrigens - wie schon erwähnt - mit der (kostenlos erhältlichen) aktuelle Visual Studio Beta Codename Orca. Die "normale" frei erhältiche Version Studio Lite (oder so ähnlich) reicht leider nicht, da die Fenster-Routinen (MFC Framework oder sowas) fehlen.


    Viel Erfolg!

  • Hier also Version 0.34, welches Einstellungen in der Registry speichert. Auch kann jetzt PPK angepasst werden (bis max. 5000 Punkte pro Kanal!). Und ob es minimiert starten soll. Und, und und...


    Ich hoffe ausserdem, dass der untere Kanal nun funktioniert... Ich werde jetzt dann auch mit dem programmieren erst mal pausieren. War genug arbeit... ;-)


    Falls allerdings jemand noch Ideen hat für statische Programme hat: nur her damit...

  • Moin!


    Funktioniert nach den 1. Tests gut.


    Mit der Auswahl der zu berechnenden Punkt bin ich noch nicht ganz glücklich. Vielleicht mach ich da mal weiter, hab zumindes schon ein paar Ideen, die auch rechenzeitmäßig nicht so dramatisch sein sollten.


    Danke nochmals
    swifty


  • Das freut mich zu hören. Dann kann ich ja erst mal pausieren... :-)


    Die Auswahl der PPK ist in der Tat nach der Holzhammer-Methode.... Allerdings ist sie auch nicht so der Ressourcenkiller, wie es sich anhört: AtmoWin benötigt ausgeführt nur etwa 1,5Mbyte Speicher und die CPU-Last ist unter 3% bei einigermaßen aktuellen Rechnern (bei 1000 PPK).


    Also wenn Du was änderst, bitte relativ zügig den Source posten, damit wir nicht "aneinander vorbei" entwickeln. :computertod :tup

  • Hi!


    Ich hab noch keinen Plan, wann ich dazu komme, aber ich werde es so schreiben, dass es einfach integriert werden kann. Wie sich das ressourcenrechnisch ganau auswirkt, weiß ich auch noch nicht. Es gibt aber ein paar mächtige Befehle wie BitBlt, die das ganze erträglich machen sollten.
    Vorher müsste aber eigentlich die SW modularisiert werden. :lehrer1 Hat jemand Bock?


    swifty

  • Quote

    Original von swifty99
    [...] Es gibt aber ein paar mächtige Befehle wie BitBlt, die das ganze erträglich machen sollten.[...]


    ...und genau der wird schon genutzt für das Screenshot machen... ;-)

  • @AtmoWin Coder :-)
    Naja die GDI Api - bietet allerhand nützliches - StretchBlt ist denke ich mal fürs erste die günstigstes Variante um den Screenshot gleich beim Abholen vom Bildschirm herunterzuskalieren - und anschliessend nur mit dem verkleinerten Bild zu arbeiten
    - spart Speicher
    - und bringt vielleicht Geschwindigkeit


    Das einzige was bei StretchBlt - vielleicht noch ein wenig "Krücke" ist die Art und Weise wie der Downscale erfolgt - aber naja wir wollen uns ja nicht am Bild ergötzen...(ggf. kann man mal in GDI+ gucken dort gibt es z.T. wesentlich mächtigere Funktionen zur Bildmanipulation)


    Was mir noch so aufgefallen ist - beim durchstöbern *g* - des Code warum werden recht oft bestimmte Parameter vom Bildschirm aufs neue abgerufen?
    Warum wird die serielle Schnittstelle (SetCommState) so oft neu konfiguriert? tut nicht wirklich not? oder?
    im WinMain ist mir aufgefallen - das dort beim beenden der ComPort (hCom_ende) nochmal neu geöffnet wird - aber die Schnittstellenparameter nicht gesetzt werden? ist das gewollt?


    Auch dieser riesige Berg globaler Variablen am Anfang - aua *g* - sowas hab ich ja schon lange nicht mehr gesehen - Programmierer halt vorwiegend Objekt orientiert (Java, Delphi) - wenn für die Programmierung schon C++ eingesetzt wird - kann man davon einiges sicher eleganter in Klassen verpacken? damit sollte es auch lesbarer werden?
    - z.B. könnte man die Konfigurationparamter in eine eigene Klasse verpacken - die auf Zuruf ihren Zustand in die Registry schreibt bzw. im Konstruktur wieder daraus liest... (wäre einfach bequemer und besser lesbar - weil so fällts mir doch recht schwer den Überblick zu behalten welche Variablen jetzt Parameter sind - und welche dynamische Prozessdaten beinhalten.)


    Das senden der Daten an den Controller µC würde ich auch in eine Funktion auslagern - da die vielen memcpy Aufrufe nicht gerade so schick (performant?) sind - und so den Blick auf das wesentliche verbergen.


    Ich hab mir mal erlaubt ein paar Klassenrümpfe Blind zu schreiben - um die Idee zu pflanzen :-) Es fehlen noch die meisten Include Anweisungen hab zur Zeit keinen C++ Compiler hier um es abzurunden...


    Wäre denke ich Sinnvoll den Rest ebenso zu zerlegen - so das einzelne überschaubare auf bestimmte Funktionen zugeschnittene Klassen/Module entstehen die man getrennt weiterentwickeln oder nutzen kann...


    Igor

  • guter Ansatz.


    Vielleicht komme ich nächste Woche zu einem Compile. Da ich aber Embedded Programmierer bin, fällt mir das Windows Zeug ziemlich schwer.


    Meine Idee war konfigurierbare Bildbereiche auszuschneiden (PlgBlt) dann auf einen Punkt runterzuscalieren (StretchBlt option ColorsNcolors). Die einzelnen Punkte können dann wie gehabt (oder anders) verkuddelt werden.


    Den Screenshot runterzuscalieren finde ich etwas oversized, da bei 1920x1200 Bildschirmen (und wer will weniger) ganz schön Rechenlast erzeugt wird. Muss man mal austesten.


    swifty