[atmocontroller] Betrieb unter Windows

  • Ja, dann zerleg doch den Code. Ich hatte da bisher keine wirkliche Lust zu... ;-)


    Die Sachen, die ich erweitert habe, habe ich bereits versucht, so weit wie geht in Funktionen zu verpacken. Mit ein wenig Parametererweiterung sollte ein Auslagern in Module problemlos möglich sein. Auch das reduzieren der globalen Variablen ist mit Sicherheit sinnvoll, und relativ einfach möglich. Ist halt nur sehr zeitaufwändig. Wenn Du daran Spass hast: Freiwillige vor! :-)


    Anbei übrigens jetzt wirklich die letzte Version von mir. Es werden jetzt alle Parameter gesichert, und der Bertriebsmodus, der beim Sichern der Parameter aktiv war, wird beim Neustart von AtmoWin wieder ausgeführt.


    Ich habe hier auf der Arbeit allerdings "blind" - also ohne AtmoLight am COM Port - programmiert. Ich hoffe, es haben sich keine Fehler eingeschlichen... Ansonsten gibt es heute Abend dann eine korrekt laufende Version.

  • Quote

    Original von swifty99
    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.


    Mir auch. Ist auch mein erster Versuch an Windows-Programmierung. Vorher nur mit MatLab, PHP, HTML, und sowas progammiert. Ist schon ein wenig anders... ;-)


    Quote

    Original von swifty99
    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.


    Im Endeffekt kann man das dann aber auch direkt mit BitBlt machen. Also pro Kanal den nur den relevanten Bildschirmteil ausschneiden. Runterscalieren hätte übrigens noch einen großen Vorteil: automatische Mittelwertbildung der enthaltenen Farben. Daraus ergibt sich die Idee:

    • Bild vom relevanten Bildschirmteil erstellen
    • Runterscalieren auf 1 (EINEN!) Pixel
    • RGB Wert auslesen und ausgeben


    Man müsste mal schauen, wie das Ergebnis davon ist. Vorteil: HSV Umrechnung entfällt komplett. Nachteil: evtl. höhere Rechenlast


    Quote

    Original von swifty99
    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.


    Genau! ;-)

  • matthias



    Also mit BitBlit wird das wohl so nicht gehen - da BitBlit keine Interpolation macht soweit ich das weiss -- dafür muss ich mal in die Funktion von GDI+ gucken da könnte sowas dabei sein wie Interpolation. (BitBlt - lässt nur Pixel weg dachte ich... auch StretchBlt)


    Igor



    PS.: bei mir ists genau umgekehrt - programmiere ganztags Windows - allerdings mit Delphi (weils für unsere Anwendung um sehr viel GUI Design geht - da krieg man beim Einsatz von C++/C das kalte Graussen - wenn ich da so die Dialog Steuerung sehe....schüttel...) Embedded Controller (µC) sowas mach ich als Hobby nebenbei in ASM und C/C++ (hab ich aber schon lange nichts mehr aktiv gemacht - mal sehen wie langs dauert bis ich da wieder voll im Saft steh)
    Noch brauch ich erstmal nen handlichen C Compiler - der mir kein .NET und mehrere GB nutzlosen Müll auf den PC lädt - vielleicht kommt Visual Studio 6 was hier noch inner Kiste liegt wieder mal zum Einsatz... *g*

  • Quote

    Original von Igor


    Also mit BitBlit wird das wohl so nicht gehen - da BitBlit keine Interpolation macht soweit ich das weiss -- dafür muss ich mal in die Funktion von GDI+ gucken da könnte sowas dabei sein wie Interpolation. (BitBlt - lässt nur Pixel weg dachte ich... auch StretchBlt)


    Ich meinte auch, dass man mit BitBlt den Teil des Bildschirmes einliest, der z.B. für den linken Kanal interessant ist. Dann per StrechtBlt auf 1x1 Pixel reduzieren, und dann Farbwert auslesen.


    Der Mittelwert der Farben kann per SetStretchBltMode und HALFTONE gesetzt werden (siehe MSDN)


    Aber das ist mir alles zu kompliziert mit den ganzen Handles und so... :-p

  • Matthiaz
    Ok - das mit dem Halftone hatte ich übersehen - muss ich mal testen wieviel CPU Zeit man dafür braucht - wenn man damit bestimmte Bereiche vom Bildschirminhalt in 1x1 Pixel Bitmaps kopiert ... ob das schneller ist und bessere Farben liefert als das derzeitige Verfahren - andernfalls würde ich mit der BitBlt / StrechtBlt Funktion nur einen Teil des Bildschirms in eine Temporäre Bitmap kopieren und diese wie gehabt analysieren... das Bedarf wohl einiger Experimente - um ne Variante zu finden die selbst auf schwachen CPU's noch halbwegs funktioniert...


    Quote

    Aber das ist mir alles zu kompliziert mit den ganzen Handles und so... :-p


    Aus dem Grund hab ich sowas auch schon seit ewigen Zeiten nicht mehr mit C oder C++ programmiert - was glaubst du wie schön Delphi ist - wie schnell man da selbst solche Dinge auf Grund der VCL programmieren kann... wo man sich mit C/C++ voll einen abbricht...;-) - aber Handles sind schon ok man muss sie nur zu greifen wissen :lol2


    Igor

  • Moin,


    Quote

    Der Mittelwert der Farben kann per SetStretchBltMode und HALFTONE gesetzt werden (siehe MSDN)


    mit dem Mittelwert der Farben haben wir damals auch angefangen.
    War alles andere als zufrieden stellend. Ist auch logisch, wenn man mal
    drüber nachdenkt.
    Es geht nämlich nicht um den Mittelwert der Farben, sondern um die
    Farbe, die am häufigsten in dem zu berechnenden Bereich vorkommt.
    Und für solche Zwecke ist der HSV-Farbraum sehr gut geeignet.
    Das ist hier im Portal übrigens auch in den ersten Threads zum Atmolight schon Thema gewesen.


    Samael

  • Hi!


    Ich denke auch, dass eine reine Mittelwertbildung nicht taucht, habt ihr ja auch schon ausprobiert. Allerdings finde ich den Ansatz die häufigste Farbe zu verwenden auch nicht ideal. Zumindest beim bisherigen Windowsalgo führt das zu einem hektischen Wechsel von Bonbonfarben. Das hektische mag daher kommen, dass ich mit den Parametrn 20ms, 2xInterpol, 20ms Senden arbeite. Zum Testen finde ich extrem schnelle Parameter wichtig, langsamer machen geht immer, das Schnelle sollte auch gut funktionieren.


    Ich hätte daher vorgeschlagen strategische Bildbereiche auszuschneiden, per mittelwert auf einen Pixel skalieren und dann die Häufigkeitsmethode anzuwenden.
    Die Bilbereich müssen deshalb sorgsam ausgewählt werden, damit horizontale und vertikale Bildschwenks nicht schlagartig zum Farbwechsel führen, so wie es jetzt ist.


    Alles Theorie, es muss halt jemand :versteck schreiben


    swifty

  • "Strategisch" geht, Bildwechsel erkennen nicht. Es ist UNMÖGLICH, bei schnellen Parametern sanfte Übergägenge zu zaubern, ausser länger zu interpolieren. Wie soll z.B. ein horizontaler Schwenk von einem vertikalen Unterschieden werden? Dazu müsste die Software "intelligent" arbeiten, und sowas zu programmieren ist, glaube ich, ein höllenaufwand.


    Einfachste Lösung: mehr interpolieren. ;-)

  • Nehmt doch einfach einen Filter, wie im Plugin auch.
    Ich verstehe sowieso nicht, wieso Ihr die ganze Geschichte nicht
    wie im Plugin löst. Das funktioniert und hat sich seit ca. 1 Jahr bewährt.


    Samael

  • Hi,


    genau, da pflichte ich Samael bei, warum baut ihr nicht auf dem auf was es schon gibt? Ist übrigens fast in jedem Schritt schön nachvollziehbar was wir gemacht haben, müsst euch "nur" diesen Thread durchlesen...wird aber bestimmt einige Fragen beantworten!
    (In dem Thread geht es um die Hardware und die Software bis zur 0.0.2 wenn ich richtig bin...)


    Grüße,
    Simon

  • Der Wichtel
    also wenn ich mich recht entsinne - wird der derzeit von Atmo Win nicht unterstützt und ständig mit 0 0 0 - angesteuert - zumindest wenn ich mir den Sourcecode anschaue?


    Wird der wirklich gebraucht? - gut dann werd ich das mal im Hinterkopf behalten bei meinen "Änderungen"... wenn ich damit anfange nächste Woche...


    Igor

  • Quote

    Original von Igor
    Der Wichtel
    also wenn ich mich recht entsinne - wird der derzeit von Atmo Win nicht unterstützt und ständig mit 0 0 0 - angesteuert - zumindest wenn ich mir den Sourcecode anschaue?


    Wird der wirklich gebraucht? - gut dann werd ich das mal im Hinterkopf behalten bei meinen "Änderungen"... wenn ich damit anfange nächste Woche...


    Igor


    Jo da wird nur 000 ausgegeben. Ich benutze den Atmo ab und zu als Partybeleuchtung zusammen mit einen Beamer. Mit mehreren Farben sieht das Ganze etwas zu bunt aus. Deshalb würde ich mich den Summenkanal freuen.


    Bisher habe ich immer die LEDs alle auf einen Kanal eingestellt, aber das passt dann wiederum nicht ganz zu den Farben vom Beamer.


    Außerdem würde ich mich noch freuen, wenn man die Farbberechnung pro Kanal an oder ausschalten könnte.


    Auf meinem zweit PC mit 300MHz läuft das Programm nicht ganz optimal....
    Zwar ist da nur das nötigste installiert, aber ab und zu kommt es zu rucklern in der Musik oder die Visualisierungen auf dem Beamer bleiben für kurze Zeit stehen. Liegt wohl auch wahrscheinlich daran, dass der Ton und die Visualisierung von der CPU berechnet wird

  • Der Wichtel
    naja der aktuelle Sourcecode ist eher dafür geschrieben - es geht ja - es wurde dabei nicht gerade darauf geschaut was man für Arbeitsspeicher und CPU Ressourcen man braucht - da es ja für "normale" PC's auch kein so riesen Problem ist - mal sehen was ich da noch an kleinen Verbesserungen machen kann - um auch so schwachen CPU's ne Chance zu geben.


    @Matthiasz?
    Mal ne Frage ich fang jetzt so langsam an den Code zu durchforsten - jetzt bin ich erstmal an ne Stelle gekommen - wo ich mich frag warum muss das so sein? gibt es dafür nen speziellen Grund?
    - Warum wird ein Teil der Konfiguration in Abhängigkeit von LiveBild, LR Wechsel, Farbwechsel und statisches Bild getrennt gespeichert?
    Speziell warum ist für jeden dieser Modi ein extra COM Port in der Registry konfigurierbar? - finde ich nicht gerade logisch - weil in der Software sieht mans noch nichtmal dass diese Einstellungen in Abhängigkeit vom Modus gespeichert werden *g*


    Wenns für den COM Port keinen Grund gibt - kommt der in den statischen Konfigurationsteil... die anderen Parameter von mir aus... muss nur im Dialog dann nur noch klar werden...


    Ebenso die Speicherung aller Werte in Form von Strings? hat das ne spezielle Bewandnis? man kann ja auch double int und Co. so wie sie sind in die Registry schreiben? dann spart man sich die Rückkonvertierung?


    Igor

  • Hallo Igor,
    dann fang ich mal an:

    Quote

    Original von Igor
    - Warum wird ein Teil der Konfiguration in Abhängigkeit von LiveBild, LR Wechsel, Farbwechsel und statisches Bild getrennt gespeichert?


    Primär habe ich das gemacht, um bei den Farbwechseln die Überblendzeit getrennt einstellbar zu machen, da es mit den Live-Bild Einstellungen viel zu unruhig ist.


    Quote

    Original von Igor
    Speziell warum ist für jeden dieser Modi ein extra COM Port in der Registry konfigurierbar? - finde ich nicht gerade logisch - weil in der Software sieht mans noch nichtmal dass diese Einstellungen in Abhängigkeit vom Modus gespeichert werden *g*


    Ja, kleiner Schönheitsfehler... Den COM-Port sollte man einmal unter den globalen Settings speichern, wie du schon sagst.


    Quote

    Original von Igor
    Wenns für den COM Port keinen Grund gibt - kommt der in den statischen Konfigurationsteil... die anderen Parameter von mir aus... muss nur im Dialog dann nur noch klar werden...


    Der Dialog könnte eh nochmal überarbeitet werden: z.B. bei stat. Farbe die Einstellungsboxen inaktiv setzten, oder bei den Farbwechsel die nicht gebrauchten Boxen auf inaktiv setzten. Mir ging es erst mal darum, ein funktionierendes Grundgerüst zu bauen.


    Quote

    Original von Igor
    Ebenso die Speicherung aller Werte in Form von Strings? hat das ne spezielle Bewandnis? man kann ja auch double int und Co. so wie sie sind in die Registry schreiben? dann spart man sich die Rückkonvertierung?


    Ich hab mit Strings angefangen, darum... :-p Und hinterher vergessen, die Funktion anzupassen...

  • Ok. - wenns keine besondere Bewandnis hat mit den Strings - kann ichs ja ändern ;-)
    Werd mich dann hier und da auch nochmal melden - weil so richtig versteh ich die ganze Berechnung noch nicht ... aber bis dahin hab ich erstmal genug andere Dinge noch im Hinterkopf an die ich denken muss - will mir dann für die Berechnung auch nochmal die Sourcen der Linuxer durchlesen - mal sehen was die noch anders machen...


    Igor

  • Hi,


    sourcen in Linux: (damit dus leichter hast)


    es werden 2 Histogramme gebildet statt nur eins


    und


    Bild wird nicht hart in Teile geteilt für die Kanäle sondern es wird immer das ganze Bild hergenommen, aber mit einer Abstandsfunktion zum Rand hin bewertet. So erzeugt auch ein einzelner Farbpunkt auf schwarzem Bild das korrekte licht.


    und noch ein paar Kleinigkeiten..


    Grüße,
    Simon

  • samc
    klingt irgendwo logisch - das so zu machen - nehmt ihr dafür wirklich das ganze Bild her in voller Auflösung? oder nehmt ihr nur jeden 2. oder 3. Pixelspalte/Pixelzeile her? (Vom Prinzip her ja ein primitiver downscale des Bildes?)


    Die Sourcen schau ich mir dann trotzdem an wenn ich soweit bin - weils mich schon interessiert wie es da gelöst ist... vielleicht kann mans ja direkt weiterverwenden... (wäre zumindest mein Ziel)


    Igor

  • Hi,


    der dvb-Treiber liefert das Bild in 64x48 Pixeln...die werden voll ausgewertet, klar.


    Es wäre sicher ein Vorteil für dich, wenn du die sourcen möglichst genau so übernimmst, weil die sind auch schon nach Geschwindigkeit optimiert! Auch die RGB->HSV Transformationen...


    Im Prinzip müsstest du nur das Bild in einer Auflösung von etwa 64x48 bereitstellen und die Berechnung drüberlaufen lassen.


    Zwischen Berechnung und Ausgabe an RS232 liegen dann noch die Filter; die sind auch unbedingt nötig und haben erst ein flackerfreies atmo ermöglicht. Das ist ein bishcen Intelligenz eingebaut (Sprungerkennung). Auch die sind schon Performance optimiert....


    Schaus dir einfach mal an!


    Grüße,
    Simon

  • Ja, das klingt doch schon mal vielversprechend hier. Zumindest passiert jetzt hier mal was mit der Windowsversion. :-)


    Jetzt lassen wir also erst mal den Igor ein wenig programmieren, und dann kann ich ja auch mal wieder was machen, z.B. das grafische Interface ein wenig aufräumen.
    Ich denke, dass man auf jeden Fall die Berechnungsgrundlage des Linuxalgorithmus integrieren sollte. Hört sich irgendwie intelligenter an als das was z.Zt. passiert... ;-)


    Igor : Modularisierst Du den Code dann evtl. direkt mit? Du hattest ja schon einmal einen kurzes Beispiel gepostet. Wäre für eine weitere Entwicklung mit Sicherheit nützlich... Dann könnte man auch parallel am Code arbeiten.