Seite 2 von 4

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 27.06.2018 15:09
von fabulouspaul
NicTheQuick hat geschrieben:Ich würde vermuten, dass 5 Hz ganz und gar nicht ausreichen werden. Du solltest wenigstens über die 24 FPS kommen, damit das Auge kein Flackern wahr nimmt. Auch die Farben am Rand des Bildschirms können sich mehrmals pro Sekunde ändern (Maschinengewehrfeuer, sonstige grellen Lichtblitze oder wilde Kamerafahrten). Da möchte man sicherlich kein Gefühl des Ruckelns bekommen. Reine Theorie meinerseits, aber ich stelle es mir mit wenigen FPS nicht besonders erträglich vor.
Vielleicht kann Hoto ja mal von seinen Erfahrungen berichten?
Wenn die Routine für die Auswertung des Images für die LEDs steht, kann man den Arduino ja auch mit einer langsameren Lösung "befeuern", wenn die finale Lösung noch nicht klappt.

Ich hab auch schonmal über eine Ambilight-Lösung für den Fernseher (bei uns wird er meist mit Streams über eine kleine Windowsbox gefüttert) nachgedacht.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 27.06.2018 15:35
von NicTheQuick
Ich habe auch schon mal darüber nachgedacht, allerdings würde ich es für Linux brauchen. Und anstatt über COM würde ich es wahrscheinlich über das Netzwerk senden. :-)

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 27.06.2018 19:22
von Hoto
Viel Erfahrung hab ich da auch nicht, ich hab das ja auch erst seit diesem Monat.

Es ist zumindest nicht so, dass die LEDs ständig neue Daten brauchen, es werden lediglich die Farben geändert, aber die bleiben so lange stehen bis man sie ändert. Ein Flackern gibt es daher nicht, aber natürlich ist der Effekt um so besser desto öfter diese aktualisiert werden und je geringer die Latenz ist.

Und darum eben über die Desktop Duplication API. Rein die Get_Frame_Bytes(*dxgi_manager, @buf_size, @*buf) Abfrage, also das Abrufen eines neuen Bildes und reinkopieren in einen PB Speicherbereich, in meinem Code benötigt meist so um die 17ms. Was allerdings merkwürdig ist, sobald ich die Maus bewege geht es runter auf 5-6ms. Erklärung?

Ist jedenfalls ein guter Wert für ein 4K Bildschirm (3840x2160).

Ich würde dann sowieso mit Threads arbeiten, eine Idee wäre die LEDs / 4 zu teilen und jeweils 1 Thread einen Teil berechnen zu lassen. Und die DDA Abfrage auch noch mal in einen extra Thread.

Edit: Ok, gerade mal innerhalb Jurrasic World Evolution getestet (auch 4K Auflösung ~30FPS), da sieht es dann nicht mehr ganz so rosig aus. ~35ms mit Ausreißern nach oben, ab und zu teils auf über 100ms, öfters auf ~65ms. Aber ich bilde mir ein auch die andere Software, die ich aktuell nutze (Prismatik), hat bei dem Spiel Schwierigkeiten. Mal noch ein anderes Spiel testen.

Edit2: bei The Witcher 3 hänge ich bei ~33ms. Was mir aber gerade etwas Sorgen bereitet ist, dass bei beiden Tests mit Spielen sich PB am Ende komplett aufgehängt hat. "Inaktiv" im TaskManager.

Edit3: Ok, noch mal ohne FPS Limit auf 30 FPS getestet, dann sieht es schon schlechter aus, dann komme ich auf ~55ms (~18 FPS) mit häufigen Ausreißern auf über 60/70ms. Die FPS zu limitieren scheint also eher besser zu sein.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 28.06.2018 15:27
von fabulouspaul
@Hoto: hast Du denn schonmal ein Image ausgelesen und für die LEDs aufbereitet? Mich würde mal interessieren wie das aussieht...

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 28.06.2018 22:46
von Hoto
Inwiefern aussieht? Kann dir gerade nicht folgen. Die Farben werden einfach nur hintereinander weg, mit einem kleinen Header davor, an das Arduino Nano übertragen, das kümmert sich dann um die RGB Stripe Ansteuerung.

Eine fertige Routine hab ich da nicht wirklich, ich hab mir nur ein Testprogramm geschrieben, dass ein Bild auf der Platte nutzt, ein paar Bereiche außen rum als LED Quellen nutzt, um dann rum zu probieren wie die einzelnen Farben raus kommen, je nach dem wie ich diese berechnen lasse. Allerdings lasse ich mir die Ergebnisse in einem Fenster anzeigen, nicht auf den LEDs.

Intern arbeite ich da mit einem lediglich 120x90 Pixel großen Bild, das dann erst in die LED Bereiche "zerlegt" wird, das sind genug Pixel um damit etwas anfangen zu können. Ich denke aber ich mach die interne Auflösung später von der Anzahl der LEDs abhängig, wäre sinnvoller. Mein Setup hat z.B. Oben 39 LEDs, für oben reicht in der Breite 1 Pixel (aber verkleinert mit Smooth Filter, nicht mit RAW), wichtiger sind die Pixel die in das Bild hinein gehen, die brauche ich zum berechnen.

Wobei ich mir hier gedacht habe, dass je weiter sie hinein ragen, desto weniger werden die Farben mit eingerechnet. So das eben die LEDs auch noch etwas reagieren, wenn z.B. eine Explosion nicht bis zum ganz äußerten Rand reichen. Auch sollte dadurch bei einer Explosion, die sich ja erst zum Bildrand ausbreitet, die LEDs nicht so ruckartig anspringen, weil im einen Frame war sie noch außerhalb des Frames und im nächsten im inneren... zack von dunkel schlagartig auf hellem Farbton. Standard ist ja den Bereich für eine LED einfach mit Smooth auf 1x1 Pixel zu verkleinern, dadurch erhälst du praktisch den Farbdurchschnitt des Bereichs, was oft nicht gerade die besten Ergebnisse liefert.

Zu aufwendig darf die Berechnung natürlich auch nicht sein, sonst dauert die Berechnung zu lange.

Edit: -----------------------------------------

Bin ich doch noch über eine Idee gestolpert, die ganz gut aussieht (zusammen kopiert, rein zum Funktionsverständnis).

Code: Alles auswählen

*buf2 = AllocateMemory(Width*Height*4)
CreateImage(0,Width,Height,32)
StartDrawing(ImageOutput(0))
  *buf2 = DrawingBuffer()
  Get_Frame_Bytes(*dxgi_manager, @buf_size, @*buf)
  CopyMemory(*buf,*buf2,buf_size)
StopDrawing()
Hatte erst versucht Get_Frame_Bytes() direkt in den DrawingBuffer() schreiben zu lassen, aber das schein wohl nicht zu gehen, kriege ich bloß ein schwarzes Bild raus. Oder geht das doch irgendwie?

So klappt es aber, auch wenn das Bild auf dem Kopf steht (vertikal gespiegelt), was aber für die Weiterverarbeitung völlig egal ist, zumindest in meinem Fall, da das Bild ja nicht zum anzeigen gedacht ist. Ich hatte eigentlich mit falschen Farben gerechnet, weil ich BGRA statt RGBA von der DLL zurück kriege, aber auch das wäre egal gewesen. ^^

Wenn ich so in Schleife aufnehme, komme ich bei nem Spiel, dass mit 30 FPS läuft und somit die Grafikkarte nicht auslastet, auf 27 bis 30ms, wovon ~2-3ms das kopieren der Daten von einem Buffer zum anderen ist und nochmal ~1-3ms das verkleinern des Bildes auf 120x90 Pixel, allerdings mit RAW, mit Smooth schießt der Wert gleich hoch auf über 100ms.

Sind doch recht gute Werte, das abrufen des Bildes über die DLL dann noch in einen extra Thread packen und es ist noch genug Puffer die Daten zu verarbeiten ehe das nächste Bild vorliegt. Im Schnitt gehen jetzt ca. 4-6ms für CopyMemory() und ResizeImage() drauf, bleiben noch ca. 27ms für die Verarbeitung (max. 33ms um 30FPS nicht zu unterschreiten). Das ist doch etwas Spielraum.

Mal sehen wie viel ms drauf gehen jedes einzelne LED zu berechnen, ich hab insgesamt 115 Stück, da kann sich also schnell was aufsummieren.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 29.06.2018 12:56
von fabulouspaul
Hoto hat geschrieben:Inwiefern aussieht? Kann dir gerade nicht folgen. Die Farben werden einfach nur hintereinander weg, mit einem kleinen Header davor, an das Arduino Nano übertragen, das kümmert sich dann um die RGB Stripe Ansteuerung.
Ich hatte nur gefragt, weil ich dachte du könntest schon etwas dazu sagen, wie das Ergebnis "in echt" ausschaut, auch wenn noch nicht die ideale Geschwindigkeit erreicht wird.

Beim Experimentieren habe ich mal zum Spaß einen seriellen Port geöffnet habe (mit 115.200 bps) und in die Schleife meiner Routine (s.o.) ein WriteSerialPortString() eingebaut. Die Durchlaufzeiten steigen bei 350 Byte Stringlänge (3 Farben x 115 LEDs + etwas Overhead) von 33ms auf 67ms auf meinem System.
Ich denke die Übertragung mit PB-Bordmitteln könnte nochmal zu einem Zeitfresser werden.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 29.06.2018 13:36
von NicTheQuick
fabulouspaul hat geschrieben:Beim Experimentieren habe ich mal zum Spaß einen seriellen Port geöffnet habe (mit 115.200 bps) und in die Schleife meiner Routine (s.o.) ein WriteSerialPortString() eingebaut. Die Durchlaufzeiten steigen bei 350 Byte Stringlänge (3 Farben x 115 LEDs + etwas Overhead) von 33ms auf 67ms auf meinem System.
Moment, du überträgst binäre 115 · 3 Bytes mit WriteSerialPortString()? Das solltest du nicht tun. Sobald eine LED den Wert 0 hat, brichst du damit deinen String ab. Nutze stattdessen WriteSerialPortData(), wenn du binäre Daten sendest.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 29.06.2018 13:58
von Mijikai
Mit Blitting (GDI) bekomme ich meinen 1080p HD-Screen mit 20 - 30 FPS in OpenGL gerendert.
Wenn Threads verwendet werden (kenne mich damit nicht so gut aus) sollte das Rendern noch schneller gehen.
Fürs Blitting habe ich mein Capture-Module (leicht modifiziert) verwendet welches ich auch im Forum veröffentlicht habe.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 29.06.2018 19:33
von Hoto
Die Desktop Duplication API schafft unter 1080p ein vielfaches davon (kann problemlos 120 FPS bei einem 120Hz Monitor). Es hat schon seinen Grund wieso ich die verwende. ;)

Das ich unter 4K weniger schaffe liegt neben der 4fachen Auflösung daran, dass meine Grafikkarte oft zu 100% bereits durch das Spiel ausgelastet ist, das mag weder das Spiel (die FPS sinken um ein paar ab) noch die Desktop Duplication API (die ms steigen nach oben). Kommt halt davon wenn man mit einer GTX 1070 unter 4K am Limit lebt, wie ich meistens. Da muss ich mal gucken wie ich dem entgegen wirken kann.

Es hat sein Grund wieso viel Software mit Screen Capture inzwischen Win8 voraussetzen oder unter Win7 deutlich schlechter laufen, weil die Desktop Duplication API gibt es erst seit Win8. Gerade im VR Bereich nutzen die ganzen Lösungen, die den Desktop in die VR bringen, diese API.


@fabulouspaul: zum Testen der Adalight Verbindung hab nur ein 5 LED Stripe benutzt, der Rest was übrig blieb und da ich 3 Ardunio Nano gekauft hatte (3 Stück 1:1 Nachbau für knapp unter 15 Euro bei Amazon), hatte ich noch genug da um mir ein Testgerät aufzubauen. ^^

Bei dem Testprogramm hatte ich die Laufzeit allerdings nicht gemessen. Wird eh darauf raus laufen so viel wie möglich zu parallelisieren. Mal gespannt wie knifflig das wird, hab noch nie derart mit Threads gearbeitet. ;)


@NicTheQuick: weiß nicht ob er da tatsächlich LED Strips testet, wäre schon ein Zufall wenn er so viele LEDs wie ich verbaut hat, oder das nur simuliert hat, bei letzterem wäre es ja egal ob er ständig das gleiche sendet.

Re: Erweiterte Ambilight Windows Software für Adalight (Ardu

Verfasst: 29.06.2018 21:02
von Mijikai
Hoto hat geschrieben:Die Desktop Duplication API schafft unter 1080p ein vielfaches davon (kann problemlos 120 FPS bei einem 120Hz Monitor). Es hat schon seinen Grund wieso ich die verwende. ;)
DXGI ist definitiv die bessere Lösung keine Frage. :)
GDI ist relativ langsam aber dafür auch einfach in der Anwendung.
Wollte nur Anmerken das es funktionieren könnte (-> 4k Blit ~ 30 FPS ohne Rendern/ Optimierung).