Matthiaz
...mmh wäre es nicht sinnvoll wenn man versuchen würde den innersten Teil der Berechnung so in Code zu verpacken den man sowohl mit einem C/C++ Compiler für Linux als auch für Windows kompilieren kann?
Würde ja sicherlich einiges an Arbeit sparen finde ich - wenn man für diesen doch recht aufwändigen Teil ein und den selben Source sowohl für Linux als auch Windows verwenden könnte?
ZitatDas 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...
mmh die Idee mit den Screenshot ist IMHO doch recht CPU belastend - ich überlege da ja eher in die Richtung ein Modul für den VideoLan Player zu bauen - wo man jedes Frame zugereicht bekommt - damit hätte man auch nicht die Probleme mit den Streifen bei 16:9 oder anderen nicht 4:3 Seitenverhältnissen.
Was meiner Ansicht nach aus einem Screenshot heraus nur schwer ermittelt werden kann - und diese Streifen "festwegzukonfigurieren" ist auch keine sinnvolle Lösung, da die Breite der Streifen ja doch recht häufig unterschiedlich ist - und da möcht ich nicht für jeden Film die Parameter von AtmoLight anpassen müssen.
Der Nachteil wäre zwar der das einem AtmoLight nur während der Videowiedergabe zur Verfügung steht - aber das wäre für mich Ok.
Ein weiterer Grund ist ja dass die Screenshot Methode es notwendig macht die Videoausgabe des Players komplett durch Software zu schleusen und damit die CPU zu belasten - nur damit ein Screenshot funktioniert. Während VLC ja normalerweise die Videoausgabe via Overlay erledigt - d.h. Videoskalierung und Teile der Aufbereitung laufen sonst in Grafikkarte ab...
Von aus diesen Gründen wäre es für mich am sinnvollsten wenn man die Steuerungssoftware wirklich Modular aufbaut - so dass man die Quellen in logische Einheiten teilt - d.h. z.B.
1.) - Bildbeschaffung - z.B. Screenshot anfertigen - simples Downscale (ohne Interpolation oder ähnliches) (durch Pixel weglassen - dürfte doch recht schnell gehen)
2.) - Umrechnung in anderes Farbmodell
3.) - Funktion die aus einem Bereich von Pixeln die Steuerwerte (Duty Cycles?) fürs AtmoLight ermittelt
4.) - Funktionen für den Zugriff auf die Hardware (serielle Schnittstelle)
Wobei die Funktionsblöcke 2) und 3) eigentlich cross plattform kombatibel zu bauen sein müssten?
Igor