You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

41

Friday, August 24th 2007, 8:24am

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

This post has been edited 1 times, last edit by "Matthiaz" (Aug 24th 2007, 9:15am)


42

Friday, August 24th 2007, 5:47pm

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

43

Saturday, August 25th 2007, 11:28pm

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?

This post has been edited 1 times, last edit by "Der Wichtel" (Aug 25th 2007, 11:28pm)


Papsi

Professional

Posts: 1,716

Location: Vohburg

Occupation: Benzinveredler

  • Send private message

44

Sunday, August 26th 2007, 6:42am

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...?
Vice President Logistics and Materials Handling of the first 40" TFT Sammelbestellung and Atmolight I + II + III

45

Sunday, August 26th 2007, 10:41am

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.

This post has been edited 1 times, last edit by "Der Wichtel" (Aug 26th 2007, 10:42am)


46

Sunday, August 26th 2007, 10:39pm

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.
Matthiaz has attached the following files:
  • Archive.zip (50.8 kB - 326 times downloaded - latest: Nov 15th 2014, 4:12pm)
  • atmoWin_src.zip (35.73 kB - 273 times downloaded - latest: Mar 19th 2014, 9:53am)

47

Sunday, August 26th 2007, 10:41pm

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

48

Monday, August 27th 2007, 9:06am

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

This post has been edited 1 times, last edit by "Der Wichtel" (Aug 27th 2007, 9:08am)


49

Wednesday, August 29th 2007, 6:53pm

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!
Matthiaz has attached the following files:

50

Wednesday, August 29th 2007, 8:44pm

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

51

Wednesday, August 29th 2007, 9:08pm

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

This post has been edited 1 times, last edit by "Der Wichtel" (Aug 29th 2007, 9:20pm)


52

Thursday, August 30th 2007, 9:29am

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...
Matthiaz has attached the following file:
  • atmoWin_nomin.zip (44.35 kB - 313 times downloaded - latest: Aug 16th 2014, 12:10am)

This post has been edited 1 times, last edit by "Matthiaz" (Aug 30th 2007, 7:11pm)


53

Thursday, August 30th 2007, 7:57pm

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

[edit]
aber nicht immer ?

This post has been edited 1 times, last edit by "swifty99" (Aug 30th 2007, 9:35pm)


Igor

Intermediate

Posts: 550

Location: Plauen /i.Vogtl. - Sachsen

  • Send private message

54

Sunday, September 2nd 2007, 2:03pm

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
Mein HTPC
Commell LV670M, Pentium 4M-2,4 GHZ, 512MB, 80 GB 2,5", PVR250, Windows XP, myHTPC, VideoLan
Mein IR-Receiver/Transmitterprojekt mehr dazu gibt es hier
permanenter Download Server (YARD, AtmoWin)

55

Sunday, September 2nd 2007, 9:10pm

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

Igor

Intermediate

Posts: 550

Location: Plauen /i.Vogtl. - Sachsen

  • Send private message

56

Sunday, September 2nd 2007, 9:16pm

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?
Mein HTPC
Commell LV670M, Pentium 4M-2,4 GHZ, 512MB, 80 GB 2,5", PVR250, Windows XP, myHTPC, VideoLan
Mein IR-Receiver/Transmitterprojekt mehr dazu gibt es hier
permanenter Download Server (YARD, AtmoWin)

57

Sunday, September 2nd 2007, 9:33pm

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

samc

Intermediate

Posts: 479

Location: München

  • Send private message

58

Sunday, September 2nd 2007, 11:19pm

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

This post has been edited 1 times, last edit by "samc" (Sep 2nd 2007, 11:19pm)


59

Monday, September 3rd 2007, 7:35am

Hi samc!

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

Danke
swifty

60

Monday, September 3rd 2007, 1:55pm

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.

This post has been edited 1 times, last edit by "Matthiaz" (Sep 3rd 2007, 1:57pm)