[atmocontroller] Betrieb unter Windows

@Matthiasz
ja ich modularisiere den Code in getrennte CPP Files, und in Klassen - bin eben eher der Typ Objektorientierter Programmierer - mal sehen wie lang ich das durchhalte - bevor ich in meinen C-Stil zurückfalle und mit Pointern, Structs und Co. jongliere ...
Gestern hab ich mir erstmal die serielle Schnittstelle hübsch verpackt und ein Objekt mit der Konfiguration gebaut - was auch das Speichern in die Registry übernimmt.

Bei den Dialogen bin ich mir noch nicht sicher ob ich vielleicht richtig auf MFC gehe - da braucht man sich nicht mit ganz soviel LowLevel Zeugs mit Callbacks machen... obwohl das auch noch grausig genug ist... --> wenn man schonmal mit Delphi oder so programmiert hat und sieht in welcher kurzen Zeit man ein ansprechendes Programm hinzaubern kann ... *g* ohne nur einmal sich mit so niedrigen Dingen wie MessageLoops etc. herumzuärgern...

Igor

PS.: wenns jemanden interessiert kann ich den Arbeitsordner auch via Apache (HTTP) zum lesen freigeben - dann könnt ihr ja ab und an nach dem Rechten sehen - was ich mache... und es kommentieren im Forum.

Zitat

Original von Igor
PS.: wenns jemanden interessiert kann ich den Arbeitsordner auch via Apache (HTTP) zum lesen freigeben - dann könnt ihr ja ab und an nach dem Rechten sehen - was ich mache... und es kommentieren im Forum.

Ja, wäre schon nett. Aber wenn Du hin und wieder einfach hier eine Rückmeldung gibst sollte es auch reichen. Vor allem, da Du ja momentan eher den Code "reinigst", und (noch) nichts neues programmierst.

Zitat

Original von Igor
PS.: wenns jemanden interessiert kann ich den Arbeitsordner auch via Apache (HTTP) zum lesen freigeben - dann könnt ihr ja ab und an nach dem Rechten sehen - was ich mache... und es kommentieren im Forum.

Ich war drauf und muss sagen: das sieht für mich teilweise aus wie chinesisch... Aber solange es fluppt ist ja alles gut!

Ich glaube, ich muss mich mal ein wenig tiefer in die C++ Strukturen einlesen, also mit Pointern und solchen Zeugs. Allerdings denke ich, dass man mit der Vorlage von Igor - sobald sie public ist - sehr gut arbeiten werden kann.

Wie ist denn jetzt so der aktuelle Status?

Hallo Matthiaz,

für mich ist das auch "Chinesisch" muss erstmal meinen Stil wiederfinden - da ich ja fast 10 Jahre nicht aktiv C++ gemacht habe.. nur Object Pascal, und ein wenig µC Assembler.

Zur Zeit versuch ich erstmal mich ein wenig Codingconventions anzulernen - damit der Code vom Stil her ein wenig ähnlicher dem Original Linux Atmo Plugin wird - vor allem die Variablenbenennung... /
Klassen etc...

Zur Zeit hab ich erstmal nur die Hardware Kapselung soweit fertig - so dass sie im Prinzip ähnlich dem funktioniert wie in der Linux Version.

Auch die Konfiguration wird jetzt von einer Extra Klasse verwaltet - in die Registry geschrieben und aus dieser gelesen...

Zum experimentieren hab ich erstmal den Fader der auf allen Kanälen läuft gebaut - ... zur Zeit gibts ja noch keinen Setup Dialog... von daher hilft nur einmal starten beenden - und Registry von Hand anpassen... dann sollte man schonmal den einen Effekt wieder haben - beendet wird das ganze über das Kontextemenü vom TrayIcon... (dort sollen später noch mehr Menüpunkte hin...)

Heute hat ich nicht soviel Zeit ... musste mal wieder länger arbeiten so dass nicht besonders viel geworden ist - ausser ein wenig Code Cleanup...
Naja ... die beiden anderen Effekt Statische Farbe, und LR Fading bau ich morgen ... die sind ja einfach... ThreadKlasse ableiten - Funktion überschreiben und im Prinzip fertsch...

Igor

(Wovor mich graut? -- der Setup Dialog... da ich wenns geht auf den Einsatz der MFC Klassen verzichten wollte - um die Exe klein zu halten - wird das nicht sonderlich lustig... wenn man Delphi gewohnt ist... wer beide welten kennt weiss was ich meine.)

Zitat

Original von Igor
(Wovor mich graut? -- der Setup Dialog... da ich wenns geht auf den Einsatz der MFC Klassen verzichten wollte - um die Exe klein zu halten - wird das nicht sonderlich lustig...

Also ich halte die bisherigen 80 Kbyte für das Programm nicht für sonderlich groß ehrlich gesagt...

Daher klick Dir den Dialog doch einfach mit MFC zusammen, dann kann man ihn später auch sehr leicht (grafisch) modifizieren und anpassen.

@Matthiasz

was bisher in dem Dialog gemacht wurde ist nicht MFC - das ist Windows PUR - MFC - bedeutet es gibt Klassen und Objekte für den Dialog - und die Edits...etc... man muss dort auch keine WndProc selber implementieren... Allerdings wenn man versucht MFC in so ne Anwendung zu basteln wie wir es haben - hat man das Problem das diese ganze MFC Bibliothek irgendwie perfider welch immer ein Hauptfenster/Dialog voraussetzt. - da muss man sich mit der ganzen MFC Geschichte denke ich mal schon gut auskennen, um dieses Verhalten loszuwerden. - und für unsere Zwecke mit dem ein / zwei Dialogöchen - solange wir damit keinen Designpreis gewinnen wollen - kriegen das auch so hin...

Zitat

Also ich halte die bisherigen 80 Kbyte für das Programm nicht für sonderlich groß ehrlich gesagt...

das sollte es auch bleiben - wenn ich die MFC richtig mit reinbaue - wird das größer oder wie bekommen Abhängigkeiten zu den MFC DLL's die ich/wir dann mit ausliefern müssten - (sofern wir das überhaupt dürften)...

Naja die Designmöglichkeiten für Dialoge sind selbst mit MFC noch erschreckend Abstoßend... weil MFC ja wirklich nicht mit der "Power" einer Borland VCL vergleichbar ist... damit macht Dialogdesign wirklich Spaß...

Naja wird schon werden... heut ist ja Freitag da kann ich ja mal ne Nacht durchproggen bis der Morgen graut ... oder es mich vom Stuhl haut... eins von beidem je nachdem was zuerst eintritt.

Igor

Ich habe das Problem - wie weiter oben schon kurz erwähnt wurde -, dass 16:9 bzw 2,11:1 Filme ziemlich schlecht mit AtmoWin laufen, da die schwarzen Balken zur Berechnung mit einbezogen werden. Desweiteren ist mir aufgefallen, dass wenn im Bild nur Schwarz und Rot vorhanden ist, das Atmolight kein Rot sondern eine seltsame Mischfarbe zeigt.

Ist es möglich, schwarze Punkte generell aus der Mittelpunktberechnung auszuschließen und diese optional zur Helligkeitsberechnung heranzuziehen?

DefCon_Drei
Da ich die Software derzeit - ziemlich radikal umbaue werde ich wohl auch daran arbeiten - aber nur in dem Rahmen das ich den Code aus dem VDR Plugin übernehme ... der diesen Sachverhalt bedingt durch eine Unterdrückung des Schwarzwertes - Rechnung trägt...

bis dahin musst du wohl mit dem "Mangel" der Sache leben - oder dir selbst versuchen zu helfen...

Igor

Zitat

Original von DefCon_Drei
Ich habe das Problem - wie weiter oben schon kurz erwähnt wurde -, dass 16:9 bzw 2,11:1 Filme ziemlich schlecht mit AtmoWin laufen, da die schwarzen Balken zur Berechnung mit einbezogen werden.

Schwarz wird als "Farbe" auch jetzt nicht mit eingezogen.

Zitat

Original von DefCon_Drei
Desweiteren ist mir aufgefallen, dass wenn im Bild nur Schwarz und Rot vorhanden ist, das Atmolight kein Rot sondern eine seltsame Mischfarbe zeigt.

Auch das kann so nicht stimmt: Atmo mittelt nicht, sondern nimmt die häufigste Farbe: also rot oder schwarz, nichts dazwischen. Versuch einfach mal ein Beispiel mit Paint zu bauen, dann siehst du das.

Seltsam - Ich kann das auch mit Paint reproduzieren. Bilder anbei.

Servus,

ich hatte mal kurz an den dlgboxen vom layout her geändert

Dies ließ sich ganz gut mit ResEdit.exe (Resource Edit) machen

im Anhang kannst du ja das Ergebnis mal sehen:

resource.c
resource.h
und atmoWin.rc

Resource edit gibts unter http://www.resedit.net/

schönes WE!

Zitat

Original von DefCon_Drei
Seltsam - Ich kann das auch mit Paint reproduzieren. Bilder anbei.

Hm, dass ist in der Tat komisch. Ich teste das mal später bei mir.

Zitat

Original von ipconfig
ich hatte mal kurz an den dlgboxen vom layout her geändert

Ja super. Allerdings ist z.Zt. noch die Version 0.34 von mir (inkl. Farbwechsel und erweiterter Konfig) aktuell. Und Igor ist momentan auch schon stark am Strukturwandel aktiv. Daher sollten wir erst mal abwarten, was dabei rumkommt.

Matthiaz
genau... aber bis dahin kann ja jeder der kreativ werden will es gerne tun - nur sollte er sich nicht wundern - wenn seine Änderungen in die "überarbeitete" Software nicht unbedingt einfliessen, weil der Dialog doch auch einige Änderungen erfährt.....
(Kannst dir ja mal meine exe aus dem debug Ordner herunterladen... und anschauen... dann siehst du was ich meine...)

Hoffe dass ich im Laufe der nächsten Woche ne ersten Version als Beta zum testen herausgeben kann... bin mir nur noch nicht sicher ob ichs gleich dem Grossen Publikum zugänglich mache oder nur einzelnen Testkandidaten... die auch ggf. gleich mal im Sourcecode mit nachschauen können wenns irgendwo klemmt... statt mich mit Messages zu bombardieren es geht was nicht...

Womit durchaus zu rechnen ist bei dem doch erheblichen Umbau den ich vorgenommen habe...

Igor

Matthiaz
DefCon_Drei

mmh schmutzige Farben Problem -- hab nen Verdacht und möcht mal nachfragen ... ich denk es liegt vielleicht am Weissabgleich und wie dieser auf die Farben angewandt wird:

derzeit steht im Sourcecode folgendes:

Zitat

RGB_R_ausgabe[s_1] = RGB_R_aus[s_1] + ( weiss_r_set - 255 );
RGB_G_ausgabe[s_1] = RGB_G_aus[s_1] + ( weiss_g_set - 255 );
RGB_B_ausgabe[s_1] = RGB_B_aus[s_1] + ( weiss_b_set - 255 );

if ( RGB_R_ausgabe[s_1] > 255 ) { RGB_R_ausgabe[s_1] = 255; };
if ( RGB_G_ausgabe[s_1] > 255 ) { RGB_G_ausgabe[s_1] = 255; };
if ( RGB_B_ausgabe[s_1] > 255 ) { RGB_B_ausgabe[s_1] = 255; };

if ( RGB_R_ausgabe[s_1] < 0 ) { RGB_R_ausgabe[s_1] = 0; };
if ( RGB_G_ausgabe[s_1] < 0 ) { RGB_G_ausgabe[s_1] = 0; };
if ( RGB_B_ausgabe[s_1] < 0 ) { RGB_B_ausgabe[s_1] = 0; };

Alles anzeigen

d.h. der Wert des ermittelten Weissabgleichs wird von der Istfarbe einfach abgezogen - und danach die werte wieder auf 0 - 255 beschränkt - sprich abgeschnitten -- das kann ja IMHO für das Farberhältnis nicht gut sein?? - nur um mit aller Gewalt Zahlen von 0 - 255 an den Controller zu schicken?

Beim Weisabgleich stellt man ja ein - welche Maximalwerte auf jedem Farbkanal man verwenden kann - so dass noch ein sauberes Weiss herauskommt?? Je Näher an 255 man die Werte da bekommt desto besser kann man die Farben abstimmen...

d.h. aber auch IMHO wenn ich für Blau z.B. 128 einstelle reicht mir dort das Spektrum von 0...128 als Wert für den Controller aus - damit Blau mit einem hellen Rot noch mithalten kann.

So will ich jetzt nen Blauwert von 64 ausgeben auf er Skale 0..255! womit ja im PC bei RGB 8-bit gerechnet wird... wird ja noch obiger Formel folgendes an den Controller gesandt:

ausgabe_blau = 64 + ( 128 - 255 );
ausgabe_blau = -63
ausgabe_blau = 0 (nach der Normierung d.h. der Farbwert verschwindet komplett?)

ist das nicht falsch? wäre es nicht richtiger den Wert nach folgender Formel abzugleichen?

ausgabe_blau : input_blau = 128 : 255

ausgabe_blau = (128 * input_blau) / 255;

ausgabe_blau = (128 * 64)/255;
ausgabe_blau = 32

?? wäre das nicht besser ?? .. ist nur so ne Idee? weil
den Wert einfach zu kappen - kann doch wenn man sichs überlegt nur zu Farbverfälschen führen????? oder? denk ich mir das zu einfach?

Igor

Igor:
Das sieht doch schon richtig gut aus! Jetzt ist Live-Bild und Weißabgleich dran, sehe ich das richtig? Und mit einer Beta... Ist wohl besser, wenn erst mal 3-4 Leute einfach auf Funktion testen, und dann kannst Du "für alle" freigeben.

Wegen Weißabgleich: ich benutze den nicht nur sehr beschränkt (Werte um 245), daher habe ich damit keine Probleme gehabt. Allerdings muss ich Deinen Überlegungen zustimmen: eine lineare Anpassung erscheint mir sinnvoller als ein einfaches Abschneiden. So ähnlich wird es übrigens auch im Original in calculations.c gemacht (ab Zeile 340):

Zitat

Ausgabe = [(neue_Farbe / Farbe_max) * 255] + 0.5

wobei das auch wenig Sinn macht, wenn die neue_Farbe>Farbe_max. Daher denke ich, dass Du Deinen linearen Ansatz

Zitat

(Farbe_max / 255) * neue_Farbe

mal verfolgen kannst. Testen kostet ja nichts...

yepp,

so habe ich es auch im Controller v3 auch umgesetzt. Der Kontrast (der die Helligkeit bestimmt) kann linear vor der Gammakurve angesetzt werden. Das ganze ist recht gut bei Wikipedia:Gammakorrektur erklärt.

Wichtig ist (so wie Du es gezeichnet hast) die Multiplikation in Klammern vor der Division auszurechnen, wenn Integer verwendet wird. Der Wertebereich muss natürlich dann größer 8Bit sein. Der Rundungsfehler (im Float mit +0,5 ausgeglichen) geht trotzdem verloren.
Also besser mit Float rechnen, oder mit 32Bit Integern und einem skalierten Wertebereich.

swifty

swifty99
Matthiaz
hab ich gerade mittels ifdef ins Programm aufgenommen...

ich denk mal das Abschneiden - kann auch zu Farbverfälschungen führen wie DefCon3 diese beschriebe hat - je nachdem wie stark man den Weissabgleich ne Farbe heruntergedreht hat... desto extremer dürfte das werden...

Igor

Ich habe den Weißabgleich mal ausgeschaltet (d.h. alle Farben zurück auf 255 gedreht) und leider bleibt das Problem mit der Farbverfälschung weiter bestehen. Wenn Ihr wollt, könnt Ihr das bei Euch auch testen, in dem Ihr das obige schwarz-rot-PNG-File mal im Fullscreen darstellt.

Beste Grüße
DefCon_Drei

Hi,

ja der Weißabgleich ist eine lineare Funktion.

vereinfacht muss es so aussehen:

ROTausgabe = ROTberechnet * KOEFFIZIENTweissabgleich.

wobei KOEFFIZIENTweissabgleich immer zwischen 0 und 1 liegen muss!

Die Methode, einfach was zu addieren kann nur zufällig funktionieren.

Das Problem mit den verwaschenen Farben könnte daran liegen, dass im original-atmowin kein Histogramm über S gebildet wird sondern das Maximum.

Grüße,
Simon

Matthiaz

Zitat

Igor:
Das sieht doch schon richtig gut aus! Jetzt ist Live-Bild und Weißabgleich dran, sehe ich das richtig? Und mit einer Beta... Ist wohl besser, wenn erst mal 3-4 Leute einfach auf Funktion testen, und dann kannst Du "für alle" freigeben

genau - und diese Leute werden jetzt gesucht... es gibt ne erste Version von mir - also wer ein ein wenig Zeit hat ggf. auch mal ein wenig Source Review betreiben kann will (also C bzw. C++ mächtig ist) soll sich mal melden...

- noch gibt es ein paar Einschränkungen
-- kein Multimonitor Support (das pack ich heut nimmer)
-- man kann die Paramter für das Live View nur in der Registry Ändern
(wer die Linux Variante und deren Parameter kenn - wird da schon durchsehen - die Bezeichnungen hab ich im wesentlichen beibehalten)
-- der Weissabgleich in Hardware geht noch nicht
-- auch ein Gammaabgleich wie die Linuxversion ihn vorsieht hab ich noch nicht... sieht auch ohne hübsch aus...

- im wesentlichen habe ich 100% des Sourcecodes für die Berechnungen aus dem aktuellen Linuxplugin "geklaut" passte im wesentlich ja recht gut in meine Vorstellungen von Objektorientierung so wars auch recht leicht für mich...

- die Fading Effekte etc. machen noch keinen Weissabgleich - der wird zur Zeit nur vom Live Modus verwendet...

- da die CPU Last zur Ermittlung des 64x48 Pixelbilder bei meiner 1600x1200 Auflösung und einer X2 4600 CPU mit 25% CPU last zu Buche schlug (im 20ms takt!) -- habe ich mal experimentell ein Schwarzes Loch erfunden - d.h. in der Mitte der 64x48 Pixelmatrix klafft ein 44x28 Pixel grosses Loch... d.h. es wird am Ende auch nur wieder der Randbereich betrachtet... die Parameter werden aber noch rausgereicht... so dass mans je nach CPU einstellen kann ... tja Windows eben ... warum kann man sich nicht so tief reinhacken... das man alle Bildänderungen mitbekommt? - Callback im Grafiktreiber...?? oder gibts sowas ??

..eine andere Idee wäre die es wohl lohnt zu verfolgen ist - sich als Modul (Plugin) in den Videoplayer zu hängen - für Videolan würde ich das vielleicht sogar machen - dort bekommt man ja jedes Frame einzeln zu fassen bevors ausgegeben wird..... da hätte mans dann auch nur mit bestenfalls PAL Auflösung zu tun - die man auf 64x48 bringen müßte....??

Igor