VDR Portal

Erstmal danke für Dein Programm und den Source-Code! Ich bastelt mir grade auch eine Version zurecht, die das macht, was ich benötige (z.B. minimiert starten, usw).

Allerdings sehe ich nirgends, wie man die "Pixel-Breite" der einzelnen Kanäle definiert, also wo festgelegt wird, über welchen Bildschirmbereich gemittelt wird. Auf meinem 22" ist der Bereich nur etwa 2cm links und recht, und das ist definitiv zu wenig. Wo kann ich das ändern?

/edit: Alles klar, gefunden. Es werden wohl nur drei 1-Pixel-breite Spalten pro Kanal berechnet. Werde das wohl auch noch ein wenig anpassen am Wochenende...

super, das Du da was machst.

Ich hab mir die Quellen auch schon angeschaut, komme aber nicht vor Nov. dazu etwas zu ändern.

Vielleicht können wir die Quellen schon mal irgendwo unter eine Versionsverwaltung stellen, damit nicht jeder von vorne anfängt.

Ich bastel gerade eine neue atmocontroller Version, bei der der Farbabgleich im Prozessor erfolgt. Zusätzlich kann man auch die globale Helligkeit einstellen, das werde ich bei Gelegenheit einbauen.

Gruß
swifty

Also ich habe das Programm heute mal unter Windows Vista ausprobiert......

Am Anfang läuft alles perfekt. Nur nach etwa 5min. wird der PC extrem langsam. Die Festplattenzugriffe steigen an und alles wird extrem träge.


Die Einstellungen habe ich auf standard gelassen und mein PC sollte das leistungsmäßig auch packen.

Intel Core2Duo T7200 2Ghz
2GB Ram und ATI X1600

Hat jemand ne Ahnung woran das liegen könnte?

Hallo,

wenn hier mehrere Leute was entwickeln, da müßt Ihr schon dazu schreiben, bei welchen Programmen es Probleme gibt.

Ich habe die Version von MacGyver2k in Betrieb und die läuft soweit schon recht gut.

Gruß
Papsi


PS
Warum setzten sich die Programmierer nicht alle zusammen und machen was gemeinsames...?

Quoted

Original von Papsi
Hallo,

wenn hier mehrere Leute was entwickeln, da müßt Ihr schon dazu schreiben, bei welchen Programmen es Probleme gibt.

Ich habe die Version von MacGyver2k in Betrieb und die läuft soweit schon recht gut.

Gruß
Papsi


PS
Warum setzten sich die Programmierer nicht alle zusammen und machen was gemeinsames...?

Meine Probleme treten bei der Version von MacGyver2k auf.

Unter Win XP ist alles in Ordnung, nur eben nicht unter Vista.

Quoted

Original von Papsi
Warum setzten sich die Programmierer nicht alle zusammen und machen was gemeinsames...?

Eigentlich eine sehr gute Idee, allerdings müsste man dafür die Software viel Modularer aufbauen. Bisher ist sie irgendwie immer weiter ergänzt worden, und dadurch geht die Übersicht leider verloren. Auch sind einige Routinen nicht wirklich ressourcenschonend geschrieben...

Ich habe auch nicht wirklich viel gemacht, ausser Bildbreitenanpassung und konstanten, zufälligen Farbwechsel zu programmieren. Vieles davon auch nur in im Source-Code, und auch noch einiges nicht wirklich sauber... Aber egal, als Demo eignet es sich schon. Das Programm startet übrigens minimiert.

Ich habe mal mein aktuelles Programm angehängt, dann kann man sich selber ein Bild davon machen. Nächstes Wochenende komme ich eventuell auch dazu, mal richtig ordentlich was zu programmieren.

Nochwas: die Checkboxen sind noch nicht fertig programmiert, also immer nur EINE Box makieren, sonst passieren bestimmt komische Sachen...

Ja würde mich sehr freuen, wenn das Ganze übersichtlicher aufgebaut wird.
Dann könnnte ich als C++ Neuling auch etwas verstehen .
Hab bisher nur mit Visual Basic Programmiert.

Was ich nicht verstehe ist, weshalb die Farben in HSV umgerechnet werden.

Dann würde ich noch ein paar Checkboxen reinmachen, wo man den Kanal auswählen kann. Somit muss das Programm bei 2 Kanälen nicht so viel rechnen.

Zusätzliche Slider, zum einstellen der Farbe, wären auch nicht schlecht

So, mal wieder ein kleines Update. Farbwechsel parallel mit allen 4 Röhren, und von links nach rechts und zurück nur für die linke und rechte Röhre. Geschwindigkeit per Int.Schritte und -Pause wählbar.

Viel Spass!

Hi!

Hab ein paar Bugs gefunden:
- Nach jeder Benutzereingabe wird minimiert.
- Helligkeitswert 0.3 führt bei Weißabgleich 255/180/180 zu nur roter Anzeige
- Bildschirminhalt verändert bei mir nicht die Farbe ;-( 0.2 funzt.

Aber super, dass Du weitermachst, danke.

swifty

hmm also ppk auf 1000. ist das nicht ein wenig viel?

Edit:

Ka obs ein Bug ist oder ob das nur auf meinem System so ist.

Das Icon in der Trayleiste ist nach dem Beenden immer noch zu sehen

Quoted

Original von swifty99
Hab ein paar Bugs gefunden:
- Nach jeder Benutzereingabe wird minimiert.
- Helligkeitswert 0.3 führt bei Weißabgleich 255/180/180 zu nur roter Anzeige
- Bildschirminhalt verändert bei mir nicht die Farbe ;-( 0.2 funzt.

Danke für die Rückmeldung. Bei 1 hatte ich eine Konstante vergessen, jetzt ist alles ok.
zu 2) Hm, weißabgleich hatte ich nicht angerührt... Und genau deshalb lauft es nicht: die neuen Module werden nicht geschlossen.
zu 3) Seltsam... Funktioniert es auch nicht, wenn man nur das Programm aufruft und nichts daran ändert?

Die ersten beiden Bugs habe ich bereits beseitig, kann aber nicht testen, da ich auf der Arbeit bin. Daher erst heute Abend "korrigierte" Version...

Quoted

Original von Der Wichtel
hmm also ppk auf 1000. ist das nicht ein wenig viel?
Edit:
Ka obs ein Bug ist oder ob das nur auf meinem System so ist.
Das Icon in der Trayleiste ist nach dem Beenden immer noch zu sehen

PPK auf 1000 macht bei meinem Arbeitsathlon 3500+ grade mal 2-3% Systemlast. Das halte ich für nicht wirklich viel...
Und die 1000 Pixel werden auf 15 "Streifen" verteilt, also werden 15 x 65 Pixel pro Kanal ausgewertet. Natürlich kann man weniger nehmen, allerdings würde dann das Ergebnis darunter leiden, denke ich. Aber für die Puristen kann ich die Berechnungs-Parameter ja mal in ein weiteres Dialogfeld rausziehen. Mal schauen, wann ich dafür Zeit finde...
Und bei mir ist das Icon nach dem Schließen weg...

/Edit: Soa, neue Version drinne. Hoffentlich funzt die... Die Parametereingabe funktioniert übrigens NICHT. Man müsste einige Arrays anpassen, und irgendwie ist das dynamisch recht schwer...

zu 3.
- vor dem Weißabgleich tut es.

[edit]
aber nicht immer ?

Hallo,

inspiriert durch den Beitrag und da ich gerade mein Atmo Light Aufbaue (will es unter Windows mit VLC Betreiben) - kam mir folgende Idee - da ich zwei Kurze und eine Lange LED Röhre habe - also nur den linken und rechten und oberen Kanal verwenden wollte - könnte ich ja auch den Ausgang der eigentlich für den unteren Kanal gedacht war - dafür nutzen den langen LED streifen oben zu teilen - und die beiden hälfte getrennt anzusteuern?
Ist das sehr kompliziert so eine Idee in die Steuersoftware für Windows einzubauen?
So dass z.B. aus den 60% des Bildinhaltes von Links die Röhre oben Links gesteuert wird und aus den 60% des Bildinhaltes von rechts die Röhre oben rechts? -- so dass in der Mitte ein Teil in den Wert für Links und Rechts gemeinsam eingeht?

Igor

yepp,

das geht. Wenn jemand die SW schreibt.

Ich hab 4 lange Röhren und auch schon drüber nachgedacht, aber mir fehlt erstmal die Zeit. Vor allem sollte die SW ohne Problemchen die Standardfälle abdecken, bevor sie aufgebohrt wird.

Aber es ist ja nicht aller Tage abend ;-)
swifty

Hi Swifty99,

naja fürs erste wirds wohl auch Standard tun - wie greift die Software zur Zeit eigentlich den Bildinhalt ab? auf den sie sich bezieht?

Wenn ich jetzt im VLC ein Video abspiele was oben und unten schwarzen Ränder hat - funktioniert das ganze dann noch?

Ich hab mir nämlich schon überlegt für VLC ein passendes Modul zu schreiben vom Prinzip her ist das recht einfach - zumindest sagt mir das mein einstündiges Studium vom Quelltext einiger Beispielfilter...

Wie funktioniert eigentlich die Ermittlung des RGB Wertes der Röhre auf Basis des Bildinhaltes? wie wird der "Mittelwert" gebildet? gibts dafür irgendwo ne lesbare Beschreibung oder einen besser kommentierten Quelltext?


Igor

PS.: bin zwar kein C/ C++ entwickler kenne mich dafür aber halbwegs mit Windows aus der Programmierung auf Low Level Ebene in Object Pascal*g* ...
Welchen C Compiler verwendet ihr für die Windows Software?

Hi!

Gute Fragen. Komplett durchschaut habe ich den Code nicht, aber auch nicht lange versucht.
Es wird jedenfalls nicht das ganze Bild ausgewertet, was bei der ersten Version ziemlich hektisch wirkte. Ich wollte bei Gelegenheit die Bildbereiche anpassen, dass sie auch mit Cinamscope Filmen klarkommen und natürlich wirken.
AtmoWin rechnet im HSV Farbraum, kann sein dass bei reiner RGB Rechnerei keine brauchbaren Farben rauskommen, müsste man mal testen.

Wenn der Atmocontroller V3 fertig ist kommt die PC SW dran ;-)
swifty



PS: Versuch mal M$ Visual Studio

Hi,

also in den atmowin code hab ich auch mal nur kurz reingeschaut...soweit ich erkennen konnte erfolgt die Berechnung so wie im atmo-plugin...das halt ich auch für wichtig, da wir an diesem Algorithmus mehrere Monat egearbeitet haben. (man müsste mal verlgiechen ob wirklich alles wichtige im atmowin drin is)

das Problem beim atmowin ist aber, dass das Monitorbild nur in voller Auflösung zur Verfügung steht, atmo aber eins in 64x48 px bekommt (vom dvb treiber)
Bei diesem kleinen Bild kann das ganze Bild berechnet werden, bei 1024x768 würde die Berechnung ewig dauern...
Was dem atmowin also imho fehlt ist, dass das ganze Bild runterskaliert wird und dem Algorithmus zugefürt wird (in der Originalversion, da rechnet er in HSV, anders gehts ned). Dann sind übrgens schwarze Balken auch kein Problem mehr, geht automatisch.

Wenn sich jemand dran versuchen will helfe ich gerne!

Grüße,
Simon

Hi samc!

Danke für die Info und das Angebot. Ich werde mal nach einem Pixelbinning Algo ausschau halten.

Danke
swifty

Ich meld mich auch mal zu Wort...

Quoted

Original von samc
soweit ich erkennen konnte erfolgt die Berechnung so wie im atmo-plugin...das halt ich auch für wichtig, da wir an diesem Algorithmus mehrere Monat egearbeitet haben. (man müsste mal verlgiechen ob wirklich alles wichtige im atmowin drin is)

Die Berechnung erfolgt im Endeffekt über die am häufigst auftretende Farbe. Es wird also NICHT gemittelt oder so. Die Berechnung steht in der Function Berechnung().

Quoted

Original von samc
das Problem beim atmowin ist aber, dass das Monitorbild nur in voller Auflösung zur Verfügung steht, atmo aber eins in 64x48 px bekommt (vom dvb treiber)

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...

Quoted

Original von samc
Was dem atmowin also imho fehlt ist, dass das ganze Bild runterskaliert wird und dem Algorithmus zugefürt wird (in der Originalversion, da rechnet er in HSV, anders gehts ned)

Das dürfte auch ohne Probleme in C++ machbar sein. Dies wird ja eigentlich schon künstlich durch die Bänder gemacht. Und so ein skalieren dürfte weit mehr Rechenaufwand bedeuten, was ja nicht gewünscht ist.

Ich hoffe, die erklärungen waren plausibel. Ich benutze übrigens Microsoft Visual Studio 9 (Codename Orca). Kann man bei Microsoft als Beta kostenlos runterladen (schlappe 4 Gigabyte oder so...).

Sollte jemand am Pixelalgo rumspielen wollen, nehmt bitte meinen Code: dort sind PPK, Bänder die Anzahl zum Auswerten korrekt integriert. In der Originalversion 0.2 von MacGyver2k waren diese nicht variable.