RGB-LED-Panel für Ambilight - geeignete LEDs/Dimensionierung?

Hab nicht angetestet, könnte aber ggf. interessant sein... im folgenden Paper geht es u.a. um das Auffinden der dominanten Farbe:

http://abacus.ee.cityu.edu.hk/…apers/2004_icip_mphsm.pdf

Zum Glück gibt's auch den Quelltext online:

http://abacus.ee.cityu.edu.hk/~mpeg7/resources.html

Bei citeceer und dblp findet man noch einige Papiere, die sich mit der Suche der 'dominaten Farbe' beschäftigen... zB:

(http://ieeexplore.ieee.org/iel5/8570/27136/01206122.pdf?tp=&arnumber=1206122&isnumber=27136)

Dominant color image retrieval using merged histogram

http://citeseer.ifi.unizh.ch/c…95b.pdf/smith95single.pdf

Vielleicht hilft es ja...

Gruß
Skobi

Zitat

Original von samc
Hallo,
Also: Wenn jemand sich ein bischen damit auskennt, wie man solche Histogramme sinnvoll auswertet, dh.nicht einfach nur das Maximum suchen, dann soll er bitte was dazu sagen.

Grüße,
Simon

Ich könnte mir vorstellen, dass man nicht nur einen einzelnen Histogrammwert für die Maximumbestimmung betrachten muss, sondern auch noch seine unmittelbaren Nachbarn. Wenn also die Farbe ReinBlau zu 30% vorkommt und ReinRot zu 40%, zusätzlich aber LeichtGrünlichBlau zu 25% dann ist die Dominate Farbe im Bild nicht Rot, sondern eher Blau.
Mein Vorschlag ist deshalb nicht das reine Maximum ( max(Farbton) ) zu suchen, sondern die Nachbarwerte (evtl. sogar mehrere Nachbarn in beide Richtungen) im Farbton-Histogramm mit einer Gewichtung in die Maximumbestimmung einzuberechnen.

Zweite Idee:
Evtl. kann es auch sein, dass die reineren Farben als dominanter angesehen werden als nicht so reine Farben. Wenn man also die Reinheit der Farbe auch noch als Gewichtung mit reinrechnet könnten die Ergebnisse besser werden.

Sind aber alles nur theoretische Überlegungen.

Gruß
Jarny

Hallo,

Zitat

daniel_k: hab mir jetzt den mega162, Programmieradapter und ein bischen Bauteile drumrum bestellt.

Hmm, ich warte immer noch auf meine LEDs...

Zitat

Hast du in C oder ASM programmiert?

In C, die Firmware ist im plugin-tar mit drin. Als Entwicklungsumgebung habe ich WinAVR verwendet.

Zitat

16bit PWM bei 12MHz Takt gibt ja nur 183Hz, oder? Also sollten wir doch lieber 12bit probieren, das müsste der Proz. ja auch können, oder?

183hz reichen nicht? Oberhalb von 25hz sollte man doch eigentlich kein Flimmern mehr sehen, oder? 12 Bit PWM sollten aber trotzdem möglich sein.

Gruß,
Daniel

Hallo,

Zitat

Mein Vorschlag ist deshalb nicht das reine Maximum ( max(Farbton) ) zu suchen, sondern die Nachbarwerte (evtl. sogar mehrere Nachbarn in beide Richtungen) im Farbton-Histogramm mit einer Gewichtung in die Maximumbestimmung einzuberechnen.

mein versuchsweiser Ansatz war:
Das Histogramm wird von 0-255 (so groß ist es) durchsucht und nicht jeder Balken isoliert betrachtet, sondern es wird immer ein Bereich aufsummiert; der Bereich ( es gibt so 255-Bereichbreite Bereiche) der gewinnt wird erneut betrachtet, und sein Maximum wird verwendet. Die Breite des Bereiches hab ich aus dem OSD einstellbar gemacht und so getestet:
hab keinen einzigen Unterschied festgestellt, nur wenn man den Bereich zu groß macht (>50 denk ich) dann kommen falsche Farben raus. Eine Gewichtung würde ja auch nur die Farbe ja nur um ein kleines Detail verändern, also ist es eigentlich das selbe, oder?
Den Effekt den man erwarten würde, also die Wahl einer ganz anderen Farbe kam so nicht vor.

Zitat

Evtl. kann es auch sein, dass die reineren Farben als dominanter angesehen werden als nicht so reine Farben. Wenn man also die Reinheit der Farbe auch noch als Gewichtung mit reinrechnet könnten die Ergebnisse besser werden.

Das kann ich mir schon eher denken, muss ich mal probieren, da werd ich mich mal in skobis Dokumente einlesen

Vielen Dank! Das denk ich hilft mir soweit weiter!

Hallo,

daniel_k:
hab hier grad mal einen anderen PWM Controller durchgemessen (Nachfolger).

Der hat eine Gamma-Korrektur mit ungefähr 2,2 eingebaut.

Was da rauskommt ist aber keine klassische PWM sondern eine Ansammlung von kurzen Peaks mit einer Krummen Verteilung. Die Grundfreq scheint bei 111Hz zu liegen.
Praktisch so, als würde in einem Timerlauf mehrmals umgeschaltet.

Grüße, Simon

Zitat

Original von samc
mein versuchsweiser Ansatz war:
Das Histogramm wird von 0-255 (so groß ist es) durchsucht und nicht jeder Balken isoliert betrachtet, sondern es wird immer ein Bereich aufsummiert; der Bereich ( es gibt so 255-Bereichbreite Bereiche) der gewinnt wird erneut betrachtet, und sein Maximum wird verwendet. Die Breite des Bereiches hab ich aus dem OSD einstellbar gemacht und so getestet:
hab keinen einzigen Unterschied festgestellt, nur wenn man den Bereich zu groß macht (>50 denk ich) dann kommen falsche Farben raus. Eine Gewichtung würde ja auch nur die Farbe ja nur um ein kleines Detail verändern, also ist es eigentlich das selbe, oder?
Den Effekt den man erwarten würde, also die Wahl einer ganz anderen Farbe kam so nicht vor.

Damit sich die Farbe verschiebt müsste man dann ein Art Schwerpunkt aus dem Histogramm errechnen. Vereinfachtes Beispiel: ein Histogramm mit 10 Farbwerten

Häufigk. 100 100 100 100 100 100 101 000 000 000
Farbton   1   2   3   4   5   6   7   8   9   10

Deine bisherige Methode: Das Maximum (=101) befindet sich bei Farbton Nr. 7
Besser bzw. anders: Wenn man ein Suchfenster über das Histogramm schiebt, wo vorher und hinterher 3 Farbtöne aufsummiert werden und daraus das Maximum (=701) ermittelt, kommt Farbton Nr. 4 als dominante Farbe heraus.

In der Praxis wertet man aber bestimmt die äusseren Bereiche des Suchfensters nicht so stark wie die mittleren. Da kann man bestimmt auch noch mit linearen oder quadratischen Gewichtungen beliebig lange rumprobieren :O.

Btw. Der Farbton ist ja im Prinzip auf einem 'Kreis' angeordnet, so dass du bei diesen gewichteten Berechnungen einen wrapAround beachten musst. Will damit nur sagen: Wenn das Suchfenster am Ende angekommen ist spielen Werte aus dem Anfangsbereich mit in die Berechnung rein. Beim Programmieren hilft da der Modulo-Operator wenns um die Indizierung im HistogrammArray geht ganz gut.

Gruß
Jarny

Hallo,

Zitat

daniel_k:
hab hier grad mal einen anderen PWM Controller durchgemessen (Nachfolger).
Der hat eine Gamma-Korrektur mit ungefähr 2,2 eingebaut.

Und wie macht der das bei geringen Helligkeiten? Unter 31 auch aus?

Zitat

Was da rauskommt ist aber keine klassische PWM sondern eine Ansammlung von kurzen Peaks mit einer Krummen Verteilung. Die Grundfreq scheint bei 111Hz zu liegen.
Praktisch so, als würde in einem Timerlauf mehrmals umgeschaltet.

Aha, merkwürdig. Vielleicht sollte man doch noch mal über ne Softwarelösung nachdenken, obwohl ich ja immer zu Hardwarelösungen tendiere. Falls Du bei
der Firmware für den 162er Hilfe brauchst, sag Bescheid!

@all: Für alle, die Interesse haben, stelle ich auch gerne mal unser Tool zur Verfügung, das unter Windows die Atmolight-Farbe in Echtzeit darstellt (Vorraussetzung: Netzwerk am VDR und der Windows-Kiste). Dann können alle, die noch kein lauffähiges Atmolight haben, trotzdem an der Algorithmus-Entwicklung teilnehmen, denn alle Theorie ist ja bekanntlich grau...

Gruß,
Daniel

Hallo daniel,

Zitat

Und wie macht der das bei geringen Helligkeiten? Unter 31 auch aus?

Er rechnet das Gamma im Controller, also ab 1 leuchtet die LED aber seeehr dunkel, aber passt so zusammen.

Zitat

Aha, merkwürdig. Vielleicht sollte man doch noch mal über ne Softwarelösung nachdenken, obwohl ich ja immer zu Hardwarelösungen tendiere. Falls Du bei

Ja jetzt gehts mir so wie dir, warten auf die Bauteile, dann versuch ichs einfach mal. Das mit den vielen kleinen Impulsen hat auch damit zu tun, dass das ganze mit Fernsehkameras zu filmen sein soll.

Ja, wenn jemand mitentwickeln will wäre das schon, kann den aktuellen sourcecode zur Verfügung stellen...

Grüße
Simon

Ich weiss nicht, ob sich der Aufwand überhaupt lohnt, über Histogramme zu gehen. M.E. liegt das Probslem darin, einen wirklich guten Farbton bei Standard-Bildern, also eine Landschaft oder eine Strasse in der Stadt usw. herauszubekommen.

Bei Bildern mit viel Wasser, Wald, Himmel, Wüste oder Feuer reicht die Mittelwert-Methode über RGB völlig aus. Wenn 1/3 oder 1/2 des Bildes eh mit dem gleichen Farbton ausgefüllt ist, funzt das auch. Bei Misch-Masch wird es eh schwierig. Welcher Farbton soll z.B. gewählt werden, wenn 1/50 des Bildes rot, 1/50 grün und 2/50 blau sind und der Rest Misch-Masch? Etwa blau? Macht auch nicht wirklich Sinn, oder? Was meint ihr?

Falls man über Histogramme geht, sollten statischtische Methoden nützlich sein - ich mache mich mal schlau.

maltic:

atmolight wertetnur 64x48 pixel aus, das Bild kommt so direkt vom Videotreiber. Deshalb kann man da ruhig ein bischen "intelligenz" reinstecken, im moment dürfte es im ms Bereich liegen was gerechnet wird.

Das mit dem RGB Mittelwert hab ich ja auch schon probiert, ist aber, wie du sagst, nur bei bei recht homogenen Bildern optimal.

Momentan gewichte ich hellere Farben stärker als dunkle, da ergibt sich schon schnell was ganz anderes als RGB Mittel.

Außerdem ist es ja durchaus ein Ziel, dass das Plugin einzelne Werte für rechts/links/oben/unten/gesamtes Bild ausgeben kann.
Und dabei will ich auch nicht einfach das Bild teilen, sondern Pixel die näher am jeweiligen Rand sind stärker bewerten als welche die weiter weg sind. (so mache ich das auch schon)

Zitat

Bei Bildern mit viel Wasser, Wald, Himmel, Wüste oder Feuer reicht die Mittelwert-Methode über RGB völlig aus. Wenn 1/3 oder 1/2 des Bildes eh mit dem gleichen Farbton ausgefüllt ist, funzt das auch. Bei Misch-Masch wird es eh schwierig. Welcher Farbton soll z.B. gewählt werden, wenn 1/50 des Bildes rot, 1/50 grün und 2/50 blau sind und der Rest Misch-Masch? Etwa blau? Macht auch nicht wirklich Sinn, oder? Was meint ihr?

das ist genau die Frage, da gibt es aber offensichtlich was, nur habs auch noch nicht gelesen

http://www.ee.cityu.edu.hk/~lm…tions/2003_ISCAS_DCIR.pdf
http://citeseer.ifi.unizh.ch/c…95b.pdf/smith95single.pdf
(danke skobi!)

Grüße,
Simon

Zitat

Original von samc
das ist genau die Frage, da gibt es aber offensichtlich was, nur habs auch noch nicht gelesen

http://www.ee.cityu.edu.hk/~lm…tions/2003_ISCAS_DCIR.pdf
http://citeseer.ifi.unizh.ch/c…95b.pdf/smith95single.pdf
(danke skobi!)

Grüße,
Simon

Alles anzeigen

Ich hab das Paper smith95single.pdf mal durchgelesen. Da gehts im Prinzip nur um die Umwandlung in den HVS-Farbraum und ne anschliessende Quantisierung (18 Hue, 3 Values, 3 Saturations)
Danach geht das Paper auf Bild-Segmentierung ein um die Bilder in einer Datenbank abzulegen und zu indizieren.
Für das Thema Ambilight also nicht brauchbar ausser die eh schon bekannte Transformation von RGB nach HVS und die Qauntisierung.

Hat schon jemand die anderen Papers durchgearbeitet?

Gruß
Jarny

Hallo,

hab das hier gelesen:
http://abacus.ee.cityu.edu.hk/…apers/2004_icip_mphsm.pdf
da gehts aber auch nur ums farbliche Vergleichen von Bildern.

Was allerdings das interessante ist: es ist von einem DCD = dominant color descriptor die Rede

Ist ein Farbvektor wohl im RGB Raum, mit einer rel. Häufigkeit. Das Bild wird auf möglichst wenige solche Verktoren reduziert. Der Vektor mit der größten Häufigkeit sollte die gesuchte Farbe sein...so hab ichs zumindest verstanden, werd mal versuchen in Literaturverzeichnis weiterzumachen

Danke und Grüße,
Simon

EDIT
Hab grad versucht ein paar kleine Videos von meinem Atmolight zu machen. Meine Digicam kann das nicht sehr gut, dh die Helligkeit flackert furchtbar, was in der Realität nicht so ist, aber die Farben kann man gut erkennen:
Link zu den Videos

Wenn ich später wieder "freien Zugriff" habe schau ich mal dass ich auch die Problemfarben aufs Video bringe.
/EDIT

Ich würd gerne nochmal zwei Punkte zum Anregen in den Thread einwerfen

Punkt 1: AmbiLight soll ja nicht wie in der Disco so ne Art hektisches Flimmern erzeugen, sondern sich etwa sekundenweise auf eine neue Farbe dimmen. Wenn man jede Sekunde (also jedes 50ste Halbbild) sozusagen eine Stichprobe macht und dann sanft dahin überblendet kann man ganz schön daneben liegen.
Um so eine zeitliche Dominanz von Farbeindrücken nicht unter den Tisch fallen zulassen müsste man also einfach die Histogrammwerte kumulieren. D.h. wenn für 49 Frames die Farbe Rot dominant war kann ein einziges dominantes blaues Frame den Roteindruck nicht zerstören.
Stichpunkt: zeitlich Integrieren

Punkt 2: Wenn die absoluten Histogrammwerte nicht einen bestimmten Schwellwert überschreiten würde ich Grau als dominant erklären. Das kommt zum Beispiel zustande, wenn zuviele bunte Sachen auf dem Bild zu sehen sind. 20% rot, 21% grün, 20% purpur, 20% schwarz, 19% gelb erweckt nicht wirklich einen grünen Eindruck, sondern eher das arithmetische Mittel aus allen RGB-Werten, also grau.

Der endgültige Algorithmus müsste deshalb folgende drei Kriterien implementiert haben:
1. zeitliche Integration der Histogrammwerte im HVS-Raum
2. Fensterbetrachtung bei der Maximumsuche und dann den Schwerpunkt berechnen (hatte ich im Thread schonmal genauer erklärt)
3. Schwellwertbetrachtung der absoluten Histogrammwerte, damit bei einer Fast-Gleichverteilung der Farben das Ergebnis Grau ist (und nicht irgendeine zufällige Farbe die ein Pixel mehr hat)

Sind aber nur Theorien von mir! Trotzdem kann man es ja diskutieren.

Die oben genannten Punkte sind noch relativ einfach zu implementieren. Wenn wir aber irgendwann anfangen und Bildsegmentierung zu betreiben um die Größe von zusammenhängenden gleichfarbigen Pixeln zu ermitteln, weil diese Flächen wohl dominanter sind als mehrere kleine Flächen, dann fänd ich das übertrieben und nicht mehr pragmatisch.

Gruß
Jarny

Hallo,

Zitat

Hab grad versucht ein paar kleine Videos von meinem Atmolight zu machen. Meine Digicam kann das nicht sehr gut, dh die Helligkeit flackert furchtbar, was in der Realität nicht so ist, aber die Farben kann man gut erkennen:

Wow, das schaut ja schon mal verdammt gut aus! Ist da irgendeine Art von Filter zur Überblenden der Farben drin? Welcher Controller ist das jetzt? Der mit der Gamma-Korrektur oder hast Du die im Plugin?

Zitat

Punkt 1: AmbiLight soll ja nicht wie in der Disco so ne Art hektisches Flimmern erzeugen, sondern sich etwa sekundenweise auf eine neue Farbe dimmen. Wenn man jede Sekunde (also jedes 50ste Halbbild) sozusagen eine Stichprobe macht und dann sanft dahin überblendet kann man ganz schön daneben liegen.

Deshalb würde ich vorschlagen, macht berechnet die Farbe doch für jedes Bild und filtert das ganze hinterher vernünftig. Hat zumindest bei den CCFLs damals ne Menge gebracht. Bei ner vernünftig dimensionierten Filterung bekommt man da schon Ruhe rein...

Zitat

Punkt 2: Wenn die absoluten Histogrammwerte nicht einen bestimmten Schwellwert überschreiten würde ich Grau als dominant erklären. Das kommt zum Beispiel zustande, wenn zuviele bunte Sachen auf dem Bild zu sehen sind. 20% rot, 21% grün, 20% purpur, 20% schwarz, 19% gelb erweckt nicht wirklich einen grünen Eindruck, sondern eher das arithmetische Mittel aus allen RGB-Werten, also grau.

Klingt erst mal nicht schlecht und führt bei nicht eindeutigen Szenen zumindest optisch nicht zu einer falschen Farbe. Allerdings gibt es "grau" ja nicht, sondern nur ein weiß in dunkler. Ich denke sowieso, daß man diese ganzen Parameter im Plugin einstellbar machen muß, dann kann es sich jeder hinterher so hindrehen, wie er es gut findet.

Gruß,
Daniel

Hallo,

JA Anregungen sind wichtig, wenn man nicht drüber reden kann wirds auch nix, ist ja altbekannt!

Also:

Zitat

Punkt 1: AmbiLight soll ja nicht wie in der Disco so ne Art hektisches Flimmern erzeugen, sondern sich etwa sekundenweise auf eine neue Farbe dimmen. Wenn man jede Sekunde (also jedes 50ste Halbbild) sozusagen eine Stichprobe macht und dann sanft dahin überblendet kann man ganz schön daneben liegen.

Wie genau soll das "zeitliche integrieren" aussegen?
Im Moment läufts so (Originalfilter noch von daniel_k): nach jeder neuen Berechnung, also konstant alle 40ms wird ein einstellbarer Prozentsatz der neuen Farbe ( im Moment 15% ) mit eben dann 85% der alten vermischt.
Dieser Filter ist alles andere als Ideal; bei großen Sprüngen ist das Überblenden schön so und "nicht spürbar", passt also.
Problem: Wenn sich die gefundene Farbe sich von Frame zu Frame ändern ohne dass sich das Bild dabei subjektiv groß ändern "flackerts" ein bischen hin und her.

Genau dieser Filter ist das nächste mit dem ich mich befassen will.
Mein theoretischer Ansatz im Moment:
gleitender Mittelwert über eine einstellbare Anzahl Frames; der Filter soll eine Sprungerkennung haben um bei Schnitten im Fernseher akzeptabel zu reagieren.
Solche Filter gibts zB bei der Simatic SPS im Analogeingang, den Algorithmus zur Sprungerkennung hab ich noch nicht gefunden.
Wenn da jemand helfen kann oder auch eine ganz andere bessere Idee hat, bitte her damit !

EDIT: ach ja, wichtig ist mein ich noch, ob der Filter im HSV oder RGB Raum läuft, ich würd ihn lieber in den HSV Raum packen, Meinungen?

Zitat

2. Fensterbetrachtung bei der Maximumsuche und dann den Schwerpunkt berechnen (hatte ich im Thread schonmal genauer erklärt)

Ist ja, wie auch schon erklärt, schon implementiert, aber der Effekt für mich subjektiv nicht positiv. Den "wrap around" muss ich allerdings noch machen
Aber: denke da muss es noch was besseres geben! Vielleicht muss da wirklich das vorherige Bild beachtet werden, aber wie weiss ich noch nicht. Ideen?

Zitat

3. Schwellwertbetrachtung der absoluten Histogrammwerte, damit bei einer Fast-Gleichverteilung der Farben das Ergebnis Grau ist (und nicht irgendeine zufällige Farbe die ein Pixel mehr hat)

Das ist ein interessanter Punkt, komischerweise hab ich sowas noch nie bewusst wargenommen, muss ich mal drauf achten. Ich gebe aber zu beachten, dass mein momentaner Algor. auch die Helligkeit mitbewertet, und so eigentlich immer was deutliches rauskommt. Aber genau da möchte ich ansetzen mit dem großen "Aufwand" hier: ich DENKE, dass einige Farben subjektiv stärker bewertet werden, die sollten dann ausgesucht werden. (-> reine Farben ? )

Zitat

Klingt erst mal nicht schlecht und führt bei nicht eindeutigen Szenen zumindest optisch nicht zu einer falschen Farbe. Allerdings gibt es "grau" ja nicht, sondern nur ein weiß in dunkler. Ich denke sowieso, daß man diese ganzen Parameter im Plugin einstellbar machen muß, dann kann es sich jeder hinterher so hindrehen, wie er es gut findet.

Auf jeden Fall! Es sollten wohl verschiedene Verfahren auswählbar und parametrisierbar sein.

Macht also gar nix wenn wir jetzt mehere Algorithmen finden. Der jetzt laufende ist gar nicht soo schlecht, nur manchmal eben ein bischen daneben, ein guter Filter erhöht die Trefferquote aber sicher noch.

Also, ich bitte um weitere Diskussion!

Grüße, Simon

Hallo,

Zitat

ach ja, wichtig ist mein ich noch, ob der Filter im HSV oder RGB Raum läuft, ich würd ihn lieber in den HSV Raum packen, Meinungen?

Das kommt ja drauf an, was denn als störend empfunden wird: der Farbwechsel oder die Änderung der Helligkeit. Vielleicht könnte man ja sogar versuchen, die Helligkeit konstant zu halten, um Ruhe rein zu bekommen und nur die Farbe filtern. Alles in allem denke ich, im HSV-Raum zu filtern wäre besser. Um verschiedene Filter für die einzelnen Anteile aufzusetzen, deren Parameter man dann getrennt einstellen kann.

Gruß,
Daniel

Hallo daniel,

ja da denkst du genauso wie ich!

Farbwechsel werden als störend empfunde. Das mit der Helligkeit ist mir auch noch nicht so ganz klar: grundsätzlich läuftst so ganz gut mit der mittl. Helligkeit des Bildes, hab das noch erweitert, dass er Bildpunkte, die dunkler als DarkLevel sind da auch nicht mehr mitrechnet, aber die Ausgabe ist meist insgesamt zu dunkel. Deshalb habe ich einen Korrekturfaktor eingeführt, also im OSD "Brightness" kann man von * -2 - *+2 einstellen. Ob das aber so das optimale ist kann ich noch nicht sagen. Evtl. sollte da ein Sensor für das Umgebungslicht her und gleichzietig sollte die Dymamik begrenzt werden ?

Grüße,
Simon

Hallo,

Zitat

Evtl. sollte da ein Sensor für das Umgebungslicht her und gleichzietig sollte die Dymamik begrenzt werden ?

Gute Idee, dann sind meine BPW34 ja doch noch zu was gut...
Eine Dynamikbegrenzung sollte auf jeden Fall rein, da gebe ich Dir recht.

Gruß,
Daniel

Zitat

Original von samc
Also:

Die zeitliche Integration würde nur bedeuten, dass man die Histogramm-Werte von n Frames aufkumuliert und den Algo dann auf das resultierende Histogramm loslässt (zB. nach 50 Frames), auf den neuen Wert wird dann einfach linear übergeblendet. Ich bin mir aber nicht sicher, ob die Idee wirklich so gut ist, weil das Ambilight dann dem Film immer 'hinterherläuft'. Deine jetztige Implementation klingt da schon besser. Wie lange dauert denn da ein AmbiLightwechsel von Schwarz auf Weiss wenn der neue Wert immer nur mit 15% eingeht. Das Ganze konvergiert ja, Schwarz und Weiss werden also nie erreicht.
Die Schnitterkennung ist ne gute Idee. In der Praxis darf man da den Schwellwert aber nicht zu niedrig ansetzen, sonst erkennt er andauernd Schnitte und das Ganze wird wieder nervös.

Deine Implementation ...
[quote]Original von samc: Das Histogramm wird von 0-255 (so groß ist es) durchsucht und nicht jeder Balken isoliert betrachtet, sondern es wird immer ein Bereich aufsummiert; der Bereich ( es gibt so 255-Bereichbreite Bereiche) der gewinnt wird erneut betrachtet, und sein Maximum wird verwendet.

Alles anzeigen

... geht immernoch im letzten Schritt auf das Maximum. Ich denke eine Schwerpunktsberechnung ist besser weil bei der Maximumermittlung ein einziges Pixel das richtige Ergebnis stark verzerren kann.

Ich mach mir am Wochenende nochmal richtig Gedanken.
Gruß
Jarny

Hallo,

ich möchte unbedingt auch so ein Teil basteln. Allerdings vielleicht mit anderer Hardware, ohne Mikrokontroller. Kennt jemand von euch den PCA9633 von Philips? Das ist ein Treiberbaustein für 4 LEDs mit I²C Interface. Er kann jede LED mit einem 8-Bit PWM-Signal ansteuern und zusätzlich nochmals alle vier Kanäle gemeinsam mit einer separaten PWM dimmen. Um die LEDs anzusteuern kann man über den I²C-Bus die DutyCycle-Werte der 5 PWM-Generatoren (4xLED + 1xGesamthelligkeit) schicken. Einfache I²C-Bus auf Parallelport-Adapter kann man selberbasteln. Ansonsten gibts I²C-Bus-Controller, die über eine Parallele-Schnittstelle angesprochen werden können (z.B. vom Microkontroller aus) Das ganze Protokoll wird dann vom Bus-Treiber erledigt.
Mit einen Bus kann man mehrere LED-Controller steuern, was bei "surround"-Ambilight praktisch ist.
Das einzige Problem an der Sache ist die Verfügbarkeit der Chips: Bis jetzt habe ich erst Digikey gefunden wo man die bestellen kann. Allerdings liefern die aus den USA mit Versandkosten um di 50 Euro.

Was meint ihr dazu?

Grüße,
Christoph