Farbe von Bildschirminhalt ermitteln ?

[Medium]

Ich hab nun mal ein wenig rumprobiert, allerdings quick & dirty, ohne auge auf die geschwindigkeit, und auch erstmal nur in C# (weil ich grad keine Lust hatte mein XP System zu booten ). Ich bin dabei den Weg über HSV gegangen, und mit folgender Taktik habe ich bisher ganz nette Ergebnisse gehabt:

Pre 1) Farbstreifen an den Bildrändern, nicht weiter unterteilt.
Pre 2) Für einen Streifen betrachte 1/8 Breite bzw. Höhe des angrenzenden Bildteiles.

A) Laufe durch alle Pixel eines Bereiches:
1) Umwandlung in HSV
2) Wenn S und V einen Mindestwert überschreitet, Eintrag in einer Liste an der Position von H um 1 erhöhen (bedingtes Hue-Histogramm erstellen)
3) Unabhängig davon S und V aufkummulieren (um später einen einfachen Durchschitt draus zu berechnen)

B) Laufe durch das Hue-Histogramm:
1) Finde den höchten Eintrag
2) Wenn der Eintrag > 5% der Gesamtpixelanzahl des Bereiches ausmacht, Aufkummulieren des H-Wertes - Zähler mitführen wie viele Werte man da zusammenrechnet.
3) Wenn 2 zutrifft, diesen Eintrag löschen und bei 1) weitermachen
(So lange Einträge aufsummieren bis kein Wert mehr >5% Beitrag hat. Sind meist nicht mehr als 2-5 Farbwerte.)

C) Erzeugen der Durchschnitte
1) H-Summe / Anzahl der Hue-Einträge mit >5% Beitrag an der Pixelmasse
2) V-Summe / Gesamtpixel des Bereiches
3) S-Summe / Gesamtpixel des Bereiches

D) Zurückwandeln in RGB


Die Mindestwerte aus A2 sind hier recht entscheident, gute Ergebnisse hab ich mit S>75% und H>30% erzielt. Da ist aber mächtig Spielraum. Ebenso verhält es sich mit den 5% aus B2. Ich hatte auch mit 10% und 2% durchaus noch sinnvolle Ergebnisse. Hier lohnt es sich eine größere Menge sehr unterschiedlicher Bilder anzuschauen, und diese 3 Werte so zu wählen dass sie möglichst immer gut aussehen. Ist halt Fummelei.
Der Vorteil hier ist, dass wenn 2 sehr unterschiedliche Farben dominieren ein Mittelwert aus dem Spektrum, und damit ein "guter" Verlaufswert entsteht. Bei Mittlung im RGB Raum läuft man nämlich schnell Gefahr sehr stark im Grau zu landen.

Ich hoffe dass ich am WE dazu komme das mal in Delphi auszuprobieren, und dann auch auf Geschwindigkeit zu achten. Das einzig wirklich eklige ist hierbei diese Hue-Liste, bzw. die Maxima zu finden. Einfach sortieren ist da nicht, da die Indizes ja auch einen Nutzwert enthalten und erhalten bleiben müssten. Mal schauen ob sich da nicht noch eine geschicktere Datenstruktur finden lässt.

[Blamaster]

Hi,

hört sich ja schonmal super an

An Hue bzw. den HSV Farbraum hatte ich auch schon gedacht komme da aber irgendwie nicht richtig hinter die Berechnungsmethode.

Meine Gedanken die ich mir gemacht hatte, bevor du das mit dem HSV Farbraum geschrieben hattest war folgender. (Bei der RGB Methode)

1.) Farbe von Pixel ermitteln.
2.) Farbe von Pixel auf schwarz/weiß/grau untersuchen. (Wenn R and G and B < 50 or R and G and B > 200)
3.) Wenn 2 für Pixel zutrifft zähler erhöhen.

4.) Wenn 2. nicht zutrifft R,G,B in ein Array schreiben.

5.) Wenn alle Pixel durchlaufen, dann Zählerwert von 3. mit anzahl der Einträge im Array aus 4. vergleichen.
- Wenn pixelzahl Schwarz/weiß/grau höher als Farbwerte im Array das ganze verwerfen und entweder Schwarz oder Weiß setzen
- Wenn Farbwerte in Array mehr als Schwarz/Weiß/Grau weiter zu Schritt 6.

6.) Nun die Werte im array für R, G, B nehmen jeweils addieren und durch Anzahl der Einträge im Array teilen um den durchschnitt zu bekommen.

Ob das ganze so funktionieren könnte weiß ich allerdings nicht.

mfg Yannic

[hathor]

Zum Thema AMBILIGHT:
.
http://www2.philips.de/entspannter_f...enresuemee.pdf
.
http://www.consumer.philips.com/cons.../discover.html

[Medium]

Hmhmhmmmm, die HSV Variante erzeugt zwar bei Standbildern oft ganz nette Ergebnisse, bei Filmen dagegen neigt sie leider doch recht oft zu einigem "Blinken". Das Problem sind dabei vor allem sehr dunkle und sehr helle Bereiche, da diese ja nicht immer Farblos sind. Daher tragen sie einen viel zu großen Anteil an Farbigkeit bei. Eventuell lässt sich da noch das ein oder andere brauchbar verrechnen, was aber am Ende bleibt ist dennoch ein nicht zu knapper Rechenaufwand. (Der allerdings sehr stark von der "Dicke" der Bildränder die man einbezieht abhängt.)

Anbei mein Testprogrämmchen. Zum Kompilieren wird die Graphics32 und das DSPack benötigt, erstellt ist das ganze mit Delphi 7. (EXE liegt aber bei) Achtung: Nach start lässt sich nur ein Mal ein Video abspielen. Um ein neues/weiteres zu starten muss das Programm beendet und wieder gestartet werden - sauber auf Start/Stop-Events zu reagieren war mir jetzt zu anstrengend (und nicht das Ziel). Speicherlecks sollten aber nicht auftreten.
Es lassen sich alle Videoformate öffnen die das DSPack verkraftet, was in aller Regel alle sind für die man Codecs installiert hat. Der Open-Dialog kommt wegen Faulheit ungefiltert daher. Generell möge man mir mannigfaltige Verletzung von u.a. OOP Richtlinien vergeben. Es ist 4 Uhr, das Bier war lecker, und nach ein paar Monaten C# war es einfach mal wieder eine Freude ein paar Pointer schubsen zu können .

Fazit: Brauchbarer Ansatz, der aber in der Praxis schwächen hat. Insbesondere wird die Verarbeitungsgeschwindigkeit noch ein echtes Thema! Mal die Tage ein wenig mit RGB basiertem Krams basteln... ein Framework ist ja nun da =)

[Blamaster]

Hi,

ich habe gerade mal über die exe gestartet und ein Video geladen. Das Video wird auch abgespielt allerdings bleiben die Ränder die ganze Zeit weiß, woran kann das liegen ?

mfg Yannic

[Mithrandir]

Beweg mal einen der Regler...

[Blamaster]

Hi,

auch das bringt nichts. Die TForm1.SampleGrabber1Buffer wird ja nichtmal aufgerufen.

mfg Yannic

[Medium]

Arbeitest du unter Vista bzw. Win7? Es kann nämlich sein dass darunter das DSPack nicht mehr so 100%ig funktioniert. Bis XP ist es zumindest auf der Webseite angegeben, und das letzte Update stammt auch aus einer Zeit wo es Vista nicht mal gab.

[Blamaster]

Hi,

nein ich nutze WinXP.

Muss außerhalb der kompo noch etwas anderes installiert werden ?

mfg Yannic

[Medium]

Hmm, eigentlich nicht. EXE und selbst kompiliertes zeigen das selbe Symptom? Eventuell liegt es ja an dem Video. Ich hatte es wenn ich mich nicht irre mit einem einfachen MPEG1 getestet. Ich hatte auch mal was von Problemen mit DivX gelesen was das Grabbing angeht. Weil wenn auch die fertige EXE nicht klappt, muss es ja entweder am Video selbst, oder dem Codec liegen