Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: VDR Portal. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

41

Freitag, 24. August 2007, 08:24

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Matthiaz« (24. August 2007, 09:15)


42

Freitag, 24. August 2007, 17:47

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

Samstag, 25. August 2007, 23:28

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?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Der Wichtel« (25. August 2007, 23:28)


Papsi

Profi

Beiträge: 1 716

Wohnort: Vohburg

Beruf: Benzinveredler

  • Nachricht senden

44

Sonntag, 26. August 2007, 06:42

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

Sonntag, 26. August 2007, 10:41

Zitat

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Der Wichtel« (26. August 2007, 10:42)


46

Sonntag, 26. August 2007, 22:39

Zitat

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« hat folgende Dateien angehängt:
  • Archive.zip (50,8 kB - 350 mal heruntergeladen - zuletzt: Gestern, 13:22)
  • atmoWin_src.zip (35,73 kB - 297 mal heruntergeladen - zuletzt: 17. November 2016, 01:00)

47

Sonntag, 26. August 2007, 22:41

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

48

Montag, 27. August 2007, 09:06

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Der Wichtel« (27. August 2007, 09:08)


49

Mittwoch, 29. August 2007, 18:53

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« hat folgende Dateien angehängt:
  • Atmowin_0.22.zip (43,99 kB - 339 mal heruntergeladen - zuletzt: 23. November 2016, 21:12)
  • Atmowin_0.22_src.zip (27,71 kB - 322 mal heruntergeladen - zuletzt: 22. November 2016, 19:49)

50

Mittwoch, 29. August 2007, 20:44

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

Mittwoch, 29. August 2007, 21:08

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Der Wichtel« (29. August 2007, 21:20)


52

Donnerstag, 30. August 2007, 09:29

Zitat

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

Zitat

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« hat folgende Datei angehängt:
  • atmoWin_nomin.zip (44,35 kB - 334 mal heruntergeladen - zuletzt: 24. November 2016, 19:45)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Matthiaz« (30. August 2007, 19:11)


53

Donnerstag, 30. August 2007, 19:57

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

[edit]
aber nicht immer ?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »swifty99« (30. August 2007, 21:35)


Igor

Fortgeschrittener

Beiträge: 550

Wohnort: Plauen /i.Vogtl. - Sachsen

  • Nachricht senden

54

Sonntag, 2. September 2007, 14:03

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

Sonntag, 2. September 2007, 21:10

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

Fortgeschrittener

Beiträge: 550

Wohnort: Plauen /i.Vogtl. - Sachsen

  • Nachricht senden

56

Sonntag, 2. September 2007, 21:16

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

Sonntag, 2. September 2007, 21:33

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

Fortgeschrittener

Beiträge: 479

Wohnort: München

  • Nachricht senden

58

Sonntag, 2. September 2007, 23:19

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »samc« (2. September 2007, 23:19)


59

Montag, 3. September 2007, 07:35

Hi samc!

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

Danke
swifty

60

Montag, 3. September 2007, 13:55

Ich meld mich auch mal zu Wort...

Zitat

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

Zitat

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

Zitat

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.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Matthiaz« (3. September 2007, 13:57)


Immortal Romance Spielautomat