MODDING-FAQ FORUM

Moin Jungs!

Ihr kennt doch sicher von Phillips diesen Ambilight kappes. Link (http://www.philips.de/PV_Article-17481.html)

Das kann man sich doch bestimmt auch selber bauen...oder programmieren habt ihr da ne ahnung wie das funktioniert und könnt ihr mir da helfen?

Da ich mit LED-Ansteuerung inzwischen eine Menge gemacht habe, wäre so ein Ambi-Light für mich elektronisch wie µC-technisch überhaupt kein Problem.

Einzig wie die Burschen da ermitteln, welche Farbe nun konkret darzustellen ist, scheint ein Betriebsgeheimnis von Philips zu sein. Ich habe seit bestimmt einem halben Jahr schon die Augen offen in dieser Richtung - Fehlanzeige.

Und wenn ich es wüßte, würde ich es sicher nicht in die Welt hinausschreien, sondern ein "Ambi-Light 4 all" teuer verkaufen...

das zu ermitteln kann nicht so schwer sein, zumindest nicht, wenn man sowie mit den bereits vorhandenen rot/grün/blau-signalen direkt im fernseher am arbeiten ist. da sollte sich mit entsprechender daempfung recht gut ein mittelwert errechnen lassen, also welche farbe im bild überwiegt.

für den hausgebrauch duerfte das natuerlich um einiges schwieriger werden, da man schlecht an die signale im innern des fernsehers kommt bzw. das einzelbild mal eben auf einen pixel runterrechnen kann um die farbe zu ermitteln ;-)

ich wuerde wenn überhaupt versuchen mit dem chrominanz-signal was zu reissen, wie es zB im s-video bzw. s-vhs standard vorhanden ist, wie genau das signal aussieht und wie man das wohl am besten auswertet kann ich dir aber auch nicht sagen - jedenfalls enthält es die reinen farbinformationen...
vielleicht is der ansatz aber auch nicht wirklich geschickt, einfach wirds jedenfalls nicht... Olaf hat da in seinem nachsatz jedenfalls sehr recht - über kurz oder lang kommt sicher jemand mit sowas auf den markt.

also eher ne rechtkomplizierte sache....mhhz aber wenn man das nur fürn rechner macht müsste das doch einfacher gehn oder?

hi jungs
klar da machste ein screenshot alle 5 oder 10 sek lässt ein programm ausrechenen wieviel anteile die jeweilige Farbe hat und die dann auf 3 led bänge bzw kathoden aus. fertig wenn dein parallelport frei ist kannste des sogar mit dem realsisieren. Ich denke das ist nicht schwer in vb zu realisieren.

mfg hackspider

5-10 sek. ?

ich glaub das wär nicht der sinn der übung...oder spuckt dein tv alle 5-10 sek. mal ein bild aus ?

naja aber 85mal (85Hz) pro sekunde 786432 (1024*768) pixel durchzurechnen bedarf einiger rechenleistung. bei einem rechendurchgang werden 2,25 mb durchgerechnet das 85 mal pro sek. also 5-10 scheint schon große abstände zu sein aber die menge der daten die dann durch die gegend geschoben werden beschränken das ganze dann.

mfg hackspider

das heisst...
diese methode ist dafür ungeeignet...man müsste das direkt elektronisch machen...

alektronisch wüste ich jetzt nicht wie man das realisieren könnte vieleicht an der graka rgb abgreifen und das dan decodieren. aber nochmal zur software-methode man kann jedes 100teste pixel abfragen und die zeit anpassen so das man ein vernünftiges zeit/rechenleistungs verhältnis bekommt. bzw wenn das noch zu viel ist, einfach 100-500 zufällige pixel alle 1-2 sekunden abfragen. um zeit zu gewinnen könnte man auch zwischen den verschiedenen farben faden nur leicht und kurz aber das verhindert dann auch bei grenzfällen das hin und herflackern.

Ich hab grad noch ein bisschen in vb rumgespielt und einige nützliche sachen gefunden z.B. bei avtivevb.de wie man screenschots machen kann. dann kan man mit point(x,y) farbwerte aus dem bitmap auslesen. der rest is billig schleife die die gewümschte anzahl an pixel abfragt. ausgabe an den parallelport hab ich schonmal gemacht also auch kein problem. vieleicht setzt ich mich heute abend mal hin und schreib mal was brauchbares.

mfg hackspider

Das mit den Stichproben kann aber gewaltig in die Hose gehen. Mir fällt da z.B. "Blade I" ein. Hier kann man in einer Szene problemlos mit deiner Methode 50x einen blauen Pixel von einer Leuchtreklame treffen und somit das Ambi auf blau schalten - obwohl der Großteil der Szenerie eher ein blutrotes Ambi empfiehlt.

Will man es wirklich richtig machen, bleibt einem nichts anderes übrig, als tatsächlich über alle "Pixel" zu laufen und das etwas öfter als alle 10 Sekunden.

Eine andere Idee wäre vllt, per µC und einem A/D-Wandler bei jedem VSync für 20ms einen Farbkanal sehr oft abzusampeln (1000 Wandlungen vllt). Beim ersten VSync sampeln wir Blau, beim nächsten Rot, dann Grün. Daraus könnte man die Leuchtkraft der LED berechnen.

Die Farbe des Ambi würde sich dann mit etwa 16Hz passend zum Bild mitändern - und auch das Blade-Problem wäre dann keines  ;D

Das ganze wäre dann problemlos am VGA/DVI/Scart-Anschluß einschleifbar und somit für alle geeignet.

Wer hat Lust ? Bitte nur ernstgemeinte Meldungen ;)

ne möglichkeit wäre auch, nur nen 50px breiten rand zu rechnen, da das ambilight auch nur am rand ist...somit benötigt man die farben in der mitte garnicht...

geil wär natürlich ne weiterentwicklung des ambilight mit mehreren farben, mit z.B. 40 led blöcken rund um den screen, welche einen bestimmten bereich des bildes als licht anzeigen, wenn z.B. die untere hälfte des bildes blau und die obere blau ist...

ich hab grad mal rechnen lassen also
ich hab ein picturebox erstellt und da ein screen reingeladen.
hab mir heigth und width ruasgezogen allerdings als TWIPS nicht als pixel.
und hab dann mit 2 for schleifen alle pixel durch rechnen lassen bzw erstmal nur in eine variable speichern. das ganze hat ca 3 min bei 100% CPU auslastung gebraucht bis dann endlich ein ergebnis kam. Mir kam ne idee dabei zufällig rauspicken kann wie olaf gesagt hat schief gehn aber wenn man z.B. 500 pixel frei auf dem bildschirm verteilen würden kann jeder so einstellen wie man will. z.b. wie melloman am rand. Oder einfach ein raster das gleichmäßig verteilt ist so bekommt man einen gesamteindruck oder einen übergang wie man halt will. nur die 750k pixel sind einfach viel zu viel.
mfg hackspider

nehmt ein beamer und schleift die Linse ab  :headshot:
ich kann euch jetzt von der Software her nicht folgen  ::)

aber meine dumme Idee warum das Bild nicht erst klein rechnen und dann den
farbanteil messen

wen ich ein screenshot mache 1200x1600 und dann mit irfanview ein 1x1 Pixel Bild daraus mache
dann müsste ich ja nur noch die farbe eines pixels messen

und das Bild klein mache dauert keine merkbare zeit

@hackspider: 3 Minuten bei 1280x1024 ? Werf mal den Compiler in den Müll, der ist Schrott.

Die 4MPixel auzulesen solle in etwa 130ms dauern (100µs/Pixel, noch auf meinem alten P4 gemessen). Dann sind wir auch bei neo's "nicht merkbare" Zeit.

hey ich mag mein pc ^^  >:(

nein mal im ernst es waren 1027x768
nur mal so wie des gerechnet wurde: Wie gesagt aber in twips.


hat bei einem bitmap screenshot 3 min gedauert
AMD 1800+

hat wer ne idee wie man statt mit twips mit pixel rechnen kann ?

mfg hackspider

das muss doch viel einfacher gehn...kann man ned seinen treiber abfragen und dann die RGB leitung anzapfen?

idee: die steuerung von nem altem tft anzappen da muss doch irgendwo nen rgb-ausgang für die anzeige sein wenn ich da einfach ne verstärkerschaltung dran hänge um größere lichtquellen anzusprechen könnte das doch funzen oder?

Was das VB-Problem angeht...

Dann sollte allerdings mit ScaleWidth und ScaleHeight gearbeitet werden. Es sei, du stellst den ScaleMode auch im Formular um.

Einfach mal die MSDN welzen und nich immer auf "VB ist ja sooo einfach" verlassen ;)

MfG
Modshark

so was die hardware angeht weiß ich nicht inwiefern das machbar ist. bin jetzt nicht so bewandert aber wie werden die bildschirme den angesteuert. Digital oder analog ? wenn digital dann denk ich ein decoder is zu umständlich wenn analog könnte man einfach schaun welches signal das stärkste ist.

aber mal zum neuen ich hab mal gecodet so quick and dirty aus dem screenshot tipp von avtivevb. Also hab ein raster gemacht also jedes 50te twip wird abgefragt das gibt ein sauberes ergebnis bei akzeptabler zeit. (im ms bereich).

http://hackspider.toxic-link.net/Daten/screen0r.exe
also wie gesagt quick and dirty also nich lästern sieht alles S****sse aus und so aber es geht.

mfg hackspider

PS: wenn wirklich bedarf besteht dann bin ich bereit mal eine final zu schreiben.

Was spricht eigentlich gegen 3 Photodioden/Phototransistoren mit Farbfilterfolie davor, die man (mittels Blende und Linse) nur den Bildschirm sehen lässt?
Der einzige Nachteil ist halt, dass man die etwas vor dem Monitor anbringen müsste, aber sie können ja ruhig von unten in einem steilen Winkel hochschauen. Sämtliche Mittelung wird dann in Echtzeit analog durchgeführt, mann muss nur noch die jeweiligen Spannungen (evtl. mit der spektralen Empfindlichkeit der Sensoren kombiniert) als Grundlage für die Helligkeit der jeweiligen LEDs nehmen.

hmmm... ich habe das teil mal getestet... bei einem zum grossteil weissem screen, meinte er, rot weare der winner... hmmm find ich ganz komisch ;D

hab's auch getestet...

bei nem fast nur schwarzen wallpaper kan auch rot...
bie m-faq page kam blau...

fazit:
test nicht bestanden...

Wie ich schon sagte. Die Stichproben-Methode kann zu sehr seltsamen Ergebnissen führen.

Allerdings ist hier nicht auszuschließen, das evtl. noch ein Bug im Programm vergraben ist und daher die seltsamen Ergebnisse stammen. Auch in einem Dreizeiler kann man 5 Fehler verstecken  ;)

ich hab ja gesagt das es arg q &d ist aber
das programm mach nix anderes als ein screen vom aktuellen bildschirm und rechnet dan jedes 50 twip in seine grundbestandteile auf rot grün blau d.h. es kann kein schwarz bzw weis geben er gibt die farbe als gewinner aus die auf dem screen am meisten vorkommt das ist bei der mfaq halt blau und bei einem "fast" schwarzen desktop halt die farbe die am meisten da ist in deinem fall blau.
Es gibt nur 3 möglichkeiten die angesteuert werden könnten.
Eine weitere idee wäre ein hell/dunkel rechnung für alle leds an bzw allle leds aus. oder wenn 2 farben in etwa gleich viel anteile haben diese 2 led (balken) dann auch anzusteuern d.h. z.B. rot und blau gleichzeitig oder grün und rot gleichzeitig.

@ Olaf
ich hab das mit dem zufall über den haufen geschmissen weil da ja viel müll rauskommen könnte. deshalb hab ich ein gitter mit je 50 twips abstand über den desktop gespannt so das ich eine eher gleichmäßige Abfrage hinbekomme.

mfg hackspider

Ja schon klar aber man müsste dazu mindestens 1x die Sekunde einen Screenshot machen und bei diesem dann die RGB-Werte der Pixel zusammenrechnen und dann durch die Anzahl der Pixel insgesamt teilen. Das ist bei z.B. 1280x1024 sehr langwierig (1-2 Sekunden im Debug Modus von C#.Net) und auch stark CPU-fressend. Das heißt man könnte maximal alle 2 Sekunden das Ambilight ändern und das unter relativ hoher CPU-Last. Ist für z.B. Spiele nicht zu empfehlen.

Und glaub nich ich hab nen schlechten PC.. AMD64 3500+, 2GB Ram Dual, ..

ich würd auch sagen hardware mässig realisieren...
das sollet ja scho in realtime laufen...

man müsste einfach irgendwie die rgb werte auslesen und auf die leds übertragen, damit die jeweiligen farben dann stärker oder schwächer leuchten...

C#.Net ist auch nicht wirklich pfeilschnell, muß man dazusagen. Der ganze DotNet-Krams ist P-Code, ähnlich wie die VB6-Programme - die auch nicht für atemberaubendes Tempo berühmt waren.

Mir schwebte da ein anderer (softwaremäßiger) Ansatz vor, einen richtigen Compiler vorausgesetzt:

- Screenshot ziehen (z.B. 1024x768 Pixel, 24Bit = 2.4MByte)

Dann hat man sozusagen ein Array aus RGB-Werten vor der Nase. Ich nehme mal 200ms als Zeitdauer dafür an. [Edit: 76ms]

- Mittelwert aus Rotem Kanal bilden (Scannen von 768KB)
- Mittelwert aus Grünem Kanal bilden (Scannen von 768KB)
- Mittelwert aus Blauem Kanal bilden (Scannen von 768KB)

Die Scanvorgänge dürften kaum mehr als 10ms an Zeit fressen. Die RGB-Werte sind allesamt schon Bytes, Bitshiftereien entfallen also. da käme man vielleicht sogar ohne Assembler hin.

[Edit: Die "übliche" Methode benötigt 3,5 Sekunden]

- Ausgabe Roter Mittelwert an PIO
- Ausgabe Grüner Mittelwert an PIO
- Ausgabe Blauer Mittelwert an PIO

Alle drei zusammen kaum mehr als 100µs.

Der komplette Vorgang dauert dann 230ms - ergo ist eine Aktualisierung je Sekunde problemlos möglich.

Die eigentliche PWM müßte dann ein am PIO angeklemmter µC machen, der dafür eh mehrere Klassen besser geeignet wäre. Dieser könnte auch das "hinfaden" zur eingestellten Farbe übernehmen, so das dann fließende Übergänge möglich sind.

Anbei ein Schnipsel Code, den ich schnell zusammengehustet habe:

mhhz joa schon klar...aber des abilight soll doch sowieso ned so schnell die farbe wechseln weil dann haste ja ne art stroboskob :P und das ist ja ned sehr beruhigend....

also ich ziehe eine hardware lösung auch vor!

ich frag mal unsere verstrahlten et lehrer^^

Einige Experimente haben ergeben, das obiger Algo zur Farbermittlung echt Schrott ist. Besser funktioniert dieser hier:


Jeder Farbkanal wird stur aufsummiert (darum muß ein 32-Bit unsigned integer her) und anschließend durch die Anzahl Pixel insgesamt geteilt.

3657 ms Laufzeit bei 1280x1024 - wer bietet weniger ?

das ambilight kann vom prinzip her gar nicht so schnell schalten. es soll leicht von einer zu der nächsten farbe faden. nun stell dir mal vor, du zappst im tv rum und jedes mal leuchtet deine wand in einer anderen farbe  :headshot: -> augenkrebs ^^

also 1 sekunde müsste für das faden schon mit einberechnet werden :)

bei einer reinen Softwarelösung stellt sich mir die Frage wie man den Bildschirminhalt ermittelt bei Fullscreen DirectX Anwendungen / Spielen. Bekommt man da per software vernünftige ergebnisse (und die nötige rechenzeit). Bin da etwas unbewandert aber lasse mich gerne positiv überraschen ;-)

Ich habe mal ein Bischen zur Struktur/Stäre/Modulation des VGa Signals gegooglet und möchte folgenden Denkanstoß geben:
Das Signal hat 0,7 Volt und wenn man annimmt, dass dunkle Bereiche des Bildes mit weniger und helle mit mehr Spannung gekennzeichnet sind müsste man mit einer Integrator Schaltung mit Operationsverstärker  aus dem Signal ein Mittelwert bilden können. Mit dieser Mittelwertspannung über ne PWM die LED´s (oder was auch immer) ansteuern und fertig ist das Ambilight... (theoretisch ;-))

Nur damit man sieht, das es auch schneller geht als 3 Sekunden:

1280x1024 Pixel, 24 Bit Farbtiefe. Gemessen auf meinem P4 530 (3.2GHz) und GF6600GT: Screenshot ziehen 16ms, Summenfarbe berechnen: 15 (in Worten: fünfzehn) ms. Nix Assembler, reines Pascal. Wer es selbst testen möchte: http://stlcd.curz.com/Ambi.exe

Zum Berechnen der Farbe kommt eine modifizierte Routine zum Einsatz, die ich mal für STGLCD gebastelt habe - ich wollte ja unbedingt 50fps auf dem GLCD haben...

Ergo habe ich somit das Errechnen der Zielfarbe auch auf langsamen Rechnern in bummelig 100ms erledigt. Wer bietet weniger ?

Wenn man das Zielfading auf eine halbe Sekunde stellt, dürfte die Systemlast kein einziges Prozent erreichen. Ich denke, die Frage nach fehlender CPU-Power ist damit hinlänglich beantwortet - wir brauchen sie schlicht nicht.

Bleibt nur noch die Frage, wie man Shots aus DirectX-Layern /OpenGL-Layern machen kann.

nur mal so auf 1600x1200 32bit, xp 2400+ (allerdings idle auf 1,6GHz) & gf4 laufen gelassen... ergebnis: shot 110 scan 40

finde allerdings die ergebnis-farben zu stark von der helligkeit abhaengig, bei einigen schwarz-anteilen im Bild (in Spielen ja nicht unueblich) wird das ergebnis imho sehr schnell sehr dunkel, und so nebenher beim browsen (mit relativ viel weiss) ist das ergebnis eher ein helles grau mit farbstich in die jeweilige richtung...

PS: finde den elektronischen Ansatz auch nicht verkehrt, bräuchte man mal jemanden mit Oszi, der sich hinsetzt und die Spannungen versucht zu visualisieren für ein paar rote, blaue und grüne testbilder...

Bin grad auf diesen Beitrag gestoßen und mir ist eingefallen, dass inner aktuellsten ELV n Bausatz für ein Selfmade Ambilight war. (N Freund erzählte mir davon, hab aber auf die schnelle keinen Link o. ä. gefunden.) Je nachdem wasdass dort halt is....

CyA Takeliner

PS: Für mich eh kaum interessant dank Beamer *G*

angeber *fg* aber guck mal pls nach dem link

Ich kann auch nichts finden. Nur das hier vielleicht:
http://www.elv.de/Main.asp?Menue=Shop&Artikel=625-51&Gruppe=BD-LL&Stufe=2&SessionId=00200756390402385890

Aber ist ja kein Ambilight :D

das was er meint, und in der aktuellen ausgabe drin ist, ist das hier: http://www.elv.de/Main.asp?Menue=Shop&Artikel=653-25&Gruppe=BD-LL&Stufe=2&SessionId=00200757040464702785

allerdings auch kein ambilight, im normalen sinne... aber ein schneller blick auf das werbe-bild könnte zu der annahme fuehren, das man damit sowas reissen kann...

ich hab den artikel nicht gelesen, kann also nicht sagen inwieweit das ganze im bereich der 'mauellen' ansteuerung zumindest moeglichkeiten bieten koennte ueber ein 'abgezweigtes' signal das gewuenschte ergebnis zu erzeugen...

dafuer gibt es im netz weitere interessante threads bzw. ansaetze zum gleichen thema:

http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=12700&postdays=0&postorder=asc&start=0
http://www.mikrocontroller.net/forum/read-1-260419.html

mhh die sind ja schon nen bissl weiter *g*

wenn ich nu wüsste wie man das verdrahtet:
Link zu einem riesigen Bild (http://www.mikrocontroller.net/attachment.php/264109/ambileihgt.JPG)

un ob des richtig funzt..weil die sind sich da ja noch ned ganz einig wenn ich das richtig gelesen habe

Edit by TzA: Monster-Bild entfernt
Warum fragst du dann nicht einfach dort nach?
Auf dem Schaltplan wird das Signal auch bloß ein bisschen verarbeitet und dann in einen µC eingespeisst, der Plan alleine hilft ohne die Software für den µC nichts

Erschwerend kommt hinzu, das man hier schon davon ausgeht, das R,G,B und V+H bereits auseinanderdividiert sind.

Selbst am Scart MIT RGB ist auf dem Grün-Signal das H+V-Sync aufmoduliert - das muß erstmal getrennt werden. Hier halten sich die Jungs dann raus ;)

nur so als kleinen vergleichswert. shot:765 scan:256
auf p2 266mhz mit einigen proggis am laufen.

*buddel buddel*

bin da gerade auf was gestoßen worden zu dem thema:

http://divxstation.com/article.asp?aId=151

der spaß sollte wohl auf jeden fall noch von ccfl auf led umgestellt werden um besser zu funktionieren

eventuell können sich die pros hier das mal näher anschauen/nachbauen/verbessern sowie demjenigen kontakte oder hilfe anbieten damit das ding vielleicht irgendwann mal als tut auf m-faq in deutsch zu sehen ist und wir alle unseren ambilight monitor rumstehen haben

eine weitere variante wäre wohl ähnlich wie philips ambibx sowas wie 2 boxen links und rechts hinzustellen als lichtquelle
z.b. zum fernsehen oder konsolen zocken
oder auch nur um die einzusetzenden lichtquellen zu reduzieren und damit den preis

Das ist durchaus ein interessantes Projekt, das Problem ist halt, dass man komplett auf dieses DirectShow-Plugin angewiesen ist. D. h. alles was nicht über DirectShow läuft (die DVD-Player nutzen dass glaub ich nicht, ebenso kann man es bei Spielen natürlich vergessen) hat auch keine Farbe dazu.
Außerdem setzt der Author nicht gerade auf offene Quelltexte, eigene Erweiterungen sind also nicht ohne weiteres möglich.
In Windows Vista wird es übrigens meines Wissens kein DirectShow mehr geben.

Hey,
nun kommt mal voll die Simple aber geniale Idee von mir, müsste mann noch perfektionieren aber gehen tut es!
Damit ihr mich versteht kommt ein Bild:

http://img140.imageshack.us/img140/9646/moddingforumambilightvz7.png

Ich hoffe ihr versteht es!

Wenn nicht fragt nach =D

MfG

Tammy

ich hab mir ähnliches auch schon überlegt

das problem dabei ist das erstens durch die spiegel vor der "röhre" das bild kleiner wird und auhc wenn sie halb  neben dem display montiert werden das bischen licht niemals ausreicht über 2 spiegel gelenkt und auf ne streuscheibe geworfen noch ansatzweise einen effekt bringen dürfte

außerdem ist das ambilight im original so ausgelegt nicht nur paar cm randbild zu verstärken sondern die gesammte bildschirmhälfte im vorherschenden farbton wiederzugeben

Ich wüsste aber eine Spiegel vorichtung:


MILCHGLASS
.........../    FERNSEHER LIEGEND GESEHEN
........../    |FERNSEHER LIEGEND GESEHEN
_________/.FERNSEHER LIEGEND GESEHEN

Die kommischen "/" und "_" sind Spiegel, hatte  keine Lust ein Bild zu malen

MfG

Tammy

Kann @StarGoose da nur zustimmen.

Erstens genügt das abgestrahlte Licht eines TV nie und nimmer, als das man auch nur annähernd einen Ambilight-Effekt erzeugen könnte. Die Streuscheiben schlucken ja nochmal an die 30% des Lichts - da bleibt nichts wirklich sichtbares von übrig.

Zweitens wird das ganze dann auch nur an Röhren-TV ansatzweise klappen. LCD-TV und Plasmaschirme "leuchten" in diese Winkel nicht mehr hinein, das ganze bliebe also eh dunkel - Beamer hätten erst recht keine Chance.

Grüße!

Nochmal zurück zu der Software-Lösung:

Also wenn ich mit dem Code von weiter vorn meinen ganzen Bildschirm abscanne (1280x960) brauch ich dafür max. 1430ms, sollte also auch bei 1280x1024 deutlich unter 2s bleiben.

Außerdem hab ich mir überlegt, wie man das noch perfektionieren könnte:
1. Möglichkeit
Nur jedes 2. Pixel scannen - spart in etwa die Hälfte der Rechenzeit und dürfte sich kaum merklich auf das Gesamtergebnis auswirken.

2. Möglichkeit
Ich hab mal fix ein Proggi gechrieben, welches sinnvollerweise(?) den Screen in 4 Bereiche aufteilt. Wenn man dann z.B. 14 RGB-LEDs verwendet (je 3 links und recht, je 4 oben und unten) könnte man damit ein schönes Ambilight basteln.
Wenn man nur oben/unten bzw. rechts/links will braucht man das Proggi nur entsprechend modifizieren (Quelltext wird nachgereicht). Dafür brauch ich max. 750ms.

Die Datei findet ihr hier (http://www.htwm.de/mmurath/Ambilight_Exe.zip).
Aufteilung des Screens: (http://www.htwm.de/mmurath/AmbiLight.bmp)
Die Mitte bleibt unangetastet. Weil entweder ist der Bereich ähnlich ausgeleuchtet oder es gäbe krasse Übergänge wenn die Farbe in der Mitte deutlich vom Rand abweicht und damit die Gesamtfarbe verfälscht. (Ich hoffe ihr wisst was ich meine)

Das Proggi ist u.U. nicht ganz ausgereift, also bitte keine vernichtenden Kritiken sondern nur Änderungsvorschläge.  :bestens:

MfG,
Lord Krachus

Das es ein wenig schneller geht (etwa Faktor 200), hab ich schon gezeigt. Und das ist auch nötig - will man den wirklichen Ambi-Effekt, dann muß man deutlich mehr als einen halben Farbwechsel pro Sekunde schaffen. Der Werbespot von Philips würde sicher nicht so kraß wirken, wenn da eine Blinkschaltung dran wäre.

Ich hab beim lokalen Mediamarkt mit seiner stark ausgebauten (LCD-und-Plasma-Only)-TV-Abteilung vorgestern mal das Ambi eine Weile beobachtet und auch versucht, da etwas mehr als nur farbiges Licht zu erkennen  ;)

Das ganze System besteht aus drei farbigen plus einer weißen Neonröhre, die höchstwahrscheinlich per DALI-Protokoll gedimmt werden. An jeder Kante des LCD/Plasmas ist so ein Satz angebracht, versteckt hinter einer Perlglas-Plastikabdeckung.

Nach den Demos dort zu urteilen, wird der Bildschirm in 4 sich überlappende Quadranten eingeteilt. Es gibt keine "Non-Scan-Zone", ein weißer Fleck in der Mitte produziert vier schwach glimmende weiße Neonröhren im Ambi-Light. Nach meinem Gefühl finden 5-10 "Neubewertungen" je Sekunde statt, die via Fader entsprechend langsam durch das Ambi visualisiert werden - das ist aber schwer zu erkennen und ich kann hier völlig falsch liegen (eigenes Bildmaterial ist, natürlich, nicht möglich einzuspielen).

Um das Rad nicht neu zu erfinden, mal ne kleine Linksammlung:

http://divxstation.com/article.asp?aId=151

http://www.vdr-portal.de/board/thread.php?threadid=51076&hilight=ambilight

http://shop.rightthing.nl/index.php?main_page=product_info&products_id=82&language=de

Ebay 130018594395

Gruss,
Bmalp

Prima Links, auch wenn ich der Meinung bin, das die hier schon gepostet wurden.

Alle Links haben aber eines gemeinsam: PC only. Wir wollen aber nicht nur am PC, auch am TV.

ich kannte die links noch nicht, kanns ein dass cih sie übersehen hab, aber ich denk dass cih vlt mal den ersten nachbauen werde. aber mit leds und nciht mit kathoden - die sind mir einfach zu teuer. aber kann mir jemand sagen, wass der in part2 mit "crystal" meint? das ist in der bestellliste.

danke
mfg Steffen

Das ist ein Quarz. Sieht man schon in der Bestelliste, weil da n Frequenz angegeben ist (11.059MHz)

Ich habe mal mit Interesse diesen Thread komplett durchgelesen.

Zum einen muss ich mal anmerken, dass der VB-Compiler nicht so S****ße ist, dass er auch nur annähernd 3 Minuten für 1280*1024 Bildpunkte bräuchte. Das muss hier ganz klar am Programmierer liegen. Der hat bestimmt das Bild einfach in eine Picturebox geladen und dann kann man halt bequem die Pixel auslesen. Dabei muss das Programm dann aber immer das gesamte Bild laden, sind auch wieder knapp 4 MB Ram (natürlich neuer Speicher, der Screenshot belegt nochmal knapp 4MB). Neenee, wenn man halbwegs geschickt auf APIs zugreift und auch mal einen anderen Treiber verwendet als nur die Standard-Runtime, dann sollte es ähnlich schnell wie mit den anderen Sprachen gehen.
ABER: Ich wäre ja ganz klar für eine Hardwarelösung, denn ich wäre nicht gewillt, meinen PC durchgängig mit soetwas zu belasten.

Da muss echt mal jemand mit nem Oszilloskop experimentieren, ich hab leider keins.

Zumindest für analoge Monitore dürfte das nicht so schwer sein, oder? Hab mir externe Links nicht angesehen. Aber es gibt doch schon je eine Farbleitung im VGA-Kabel und man muss doch dann "nur" eine Schaltung bauen, die mit eigener Frequenz die Leitungen abgreift und in einen Ringspeicher schreibt, der vielleicht so groß ist, dass man 2 bis 3 Sekunden lang die abgelesenen Daten reinschreiben kann. Eine weitere Schaltung ermittelt mit eigener oder der gleichen Frequenz regelmäßig einfach den Mittelwert jeder Farbe im Ringspeicher.

Hi
So da ich dieser Programmierer bin muss ich zugeben das du völlig recht hast ich hab das ganze in ne picturebox gelegt und dann 2 for anweisung ineinander geschachtelt alles nur auf die schnelle. Das mit der api wäre ne lösung aber ich bin im moment nicht gewillt des nochmal in angrif zu nehmen.

Ich hab den Thread nicht mehr ganz in erninnerung aber wie wärs wenn man (geht nur am TV) die leitungen für RGB (die sind ja immer im bereich von 0V - 0,7V einfach mit einem OP und einem P-Fet (nodrop2 prinzip) die ansteuerung der leds / röhren oder was auch immer realisiert.
Das war nur mal so ein Hirngespinst. Wäre eine sehr einfache / billige Lösung.

mfg hackspider

Die Idee, einfach die RGB-Leitungen anzuzapfen, hatten schon viele. Allein gibt es bisher nur ein Vollelektronisches Ambilight - das von Philips. Es ist also ganz und gar nicht so einfach, wie es sich darstellt.

So ein TV-Bild wird in zwei Zügen übertragen: Einmal die geradzahligen, dann die ungeradzahligen Linien (Kann auch umgekehrt sein, bin da nicht mehr sicher. Wie auch immer, PAL benutzt 50Hz im Halbbildverfahren - am PC-Monitor nennt sich das "Interlaced").

Das Problem: Wann genau beginnt denn nun ein neues Bild ? Und schon wird es lustig:
- Manche Geräte senden VSync/HSync getrennt über den Scart (Ich kenne keines)
- Manche Geräte senden V/H kombiniert über Scart (Kenne ich auch keines)
- Die allermeisten Geräte moduleren VSync auf das G-Signal. Und da liegen für diesen Impuls dann keine 0..0.7V an, sondern 5 oder 12V, je nach Sync-Signal und Gerät.

Diese Erkennerei und der gewaltige Pegelunterschied machen die Sache etwas komplizierter. Weiterhin möchte man das Fersehbild natülich nicht mehr als nötig verschlechtern, ergo sind da weitere Maßnahmen zu ergreifen.

Es folgen die A/D-Wandler. PAL arbeitet mit 15625Hz Zeilenfrequenz - daraus folgt, eine Zeile wird binnen 64µs übertragen. Der A/D hat also 32µs Zeit, so viele Samples wie möglich zu ziehen (Linke Hälfte), dann wieder 32µs für die rechte Hälfte. Das ganze 312 mal für die obere Hälfte, 312 mal für die untere Hälfte, jeweils für R,G und B. Ja, ich weiß, da fehlt eine Zeile  ;)

Nun hat man eine Austastlücke Zeit die Daten erstmal zu verarbeiten - wir sind aber noch nicht fertig, denn das war nur ein Halbbild, es folgt noch eine Hälfte.

Hat man auch das intus, hat man wieder eine Austastlücke Zeit, die Daten zu verarbeiten und sich mit seinen LED zu befassen.

Um es vorweg zu nehmen: Ja, es gibt Chips, die das sogenannte Burst-Signal erkennen und µC-tauglich weitergeben können. Alle, die ich bisher gefunden habe, sind abgekündigt bzw. werden nicht mehr produziert.

Ich persönlich denke, ein AD-Wandler im ATmega ist schnell genug, die Daten wandeln zu können. Mit 16MHz betrieben dürfte er auch in de Lage sein, das ganze abzuholen und zwischenzuspeichern.

Nur: Wo abspeichern und - schafft er das Postprocessing auch noch ?

Good luck !  ;D

Warum muss man das denn so kompliziert halten. Also erstens wollen wir unser Ambilight doch träge mitlaufen lassen, also ein völliger Farbwechsel sollte eine Sekunde  +/- dauern. Sonst blitzt es nur und macht einen kirre
Dann kam hier für die PC-Variante schon mehrfach der Vorschlag das Bild zu verkleinern, bzw. nur jedes x. Pixel abzugreifen, was ja das gleiche ist. Daher müssen wir doch eigentlich nicht die Frequenz vom TV-Signal erreichen und können ruhig etwas langsamer rechnen.
Wann ein Bild anfängt, bzw. eine Bildhälfte anfängt... Wen interessierts? Wenn wir mit eigener Frequenz (um das TV-Signal nicht zu belasten) abtasten und uns einfach einige Farben aus dem Bild merken, dann können wir doch den Mittelwert berechnen. Natürlich müssen schon genug Abtastungen in gleichmäßigen Zeitabständen stattfinden, damit man statistisch den Farbmittelwert annähernd erreicht.
Wenn wir einfach nur "hin und wieder" in das TV-Signal "reinschauen" und gucken, was zu dem Zeitpunkt gerade anliegt, dann müssten wir doch genügend Daten erhaschen, um damit ein Ambilight zu bauen. Zu welchem Bild das Augenblickssignal gehört ist egal. Außerdem bräuchten wir so viel weniger Speicher um einen Mittelwert zu bilden.
Ein kleiner ATTiny2313 oder sowas müsste damit klarkommen. Das TV-Signal tasten wir nur mit Optokopplern ab. Die Frequenz müssen wir ja nicht abnehmen.

Das Programm für den µC sollten nur wenige Zeilen sein: Endlosschleife - Zuerst die Farbwerte an drei Eingängen aufnehmen und drei Mittelwerte bilden und die in den Speicher schreiben. Wir wollen unser Signal träge mitlaufen lassen, also bilden wir einen Mittelwert aus so vielen Werten, wie wir in z.B. einer Sekunde abtasten. Ältere Werte können wir verfallen lassen (Ringspeicher). Ich weiß nicht, ob der Speicher da reicht, ansonsten muss ich mir was einfallen lassen  ;) . Mittelwerte an drei Ausgänge zur nachfolgenden Elektronik (einfach Verstärker und dann LEDs).

Trotzdem sage ich euch gleich: Ich kann es noch nicht bauen. Fange gerade erst mit µCs an.

Das wirst du später auch nicht "so einfach" bauen...

15625Hz Zeilenfrequenz mit Zeilensprüngen. D.h. Wenn du nur jede 4te (bzw. 8te) Zeile auslesen willst, und davon nur 100 Pixel, kommst du auf
15625Hz / 4 * 100 = ca. 400kHz. Wie gesagt, nur eine miese Abtastungsgenaugikeit.

Auf 3 Kanäle aufgeteilt wären das bei 8Bit Farbtiefe / Farbe 1,2MHz Byte-Takt. Mit 3 _externen_ Wandlern könnte das gerade so hinhauen.

3x IN + 9xADD (24Bit-Zähler) + SBIW + BRCC = 3 + 9 + 2 + 3 = 17 Takte
17 * 1,2 = 20,4MHz AVR-System-Takt.

In den Austastlücken kannste dann die Zählerstände auswerten und in zu den PWM-Kanälen schicken.

Wenn ich mich nicht verrechnet habe, dann könnte das mit dieser 78x100 Pixel-Auflösung hinhauen.

Optokoppler ist ne gute Idee, bringt nur hier garnix. Wenn, dann Impedanzwandler-OPVs mit kräftigem Eingangswiderstand und eine kleine SMD-Platine, wegen parasitären Induktivitäten/Kapazitäten.

Aufteilung in 3 AVRs wäre natürlich praktischer: jeder digitalisiert nur seine eigene Farbe und gibt diese auch gleich auf die LED-Farbe aus.

Wer eine höhere Auflösung haben will, sollte sich lieber mit Analoger-Elektronik anfreunden, denke ich.

Was sagt ihr zu meiner (Überschlags-)Rechnung?

b0nze