Seiten: 1 2 3 [4] 
|
 |
|
Autor
|
Thema: Ambilight (Gelesen 36628 mal)
|
Lord Krachus
Stichsägenquäler
Karma: +0/-0
 Offline
Geschlecht: 
Beiträge: 58
Wer später bremst ist länger schnell
|
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.
Aufteilung des Screens: 
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. 
MfG,
Lord Krachus
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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).
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
|
|
|
|
|
|
|
|
Movergan
Lötkolbenfreak
Karma: +1/-0
Offline
Geschlecht:
Beiträge: 150
Ich liebe dieses Forum mehr als alle anderen!
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
hackspider
Wakü-Poseidon
Karma: +4/-0
Offline
Geschlecht:
Beiträge: 412
|
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
|
|
|
|
|
Gespeichert
|
|
|
|
OlafSt
Global Moderator
Karma: +13/-0
Offline
Geschlecht:
Beiträge: 2138
Master of STLCD and LISA III
|
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 ! 
|
|
|
|
|
Gespeichert
|
Erstens: Lies was da steht. Zweitens: Denk drüber nach. Drittens: Dann erst fragen
|
|
|
Movergan
Lötkolbenfreak
Karma: +1/-0
Offline
Geschlecht:
Beiträge: 150
Ich liebe dieses Forum mehr als alle anderen!
|
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.
|
|
|
|
|
Gespeichert
|
|
|
|
b0nze
Gast
|
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
|
|
|
|
|
Gespeichert
|
|
|
|
Seiten: 1 2 3 [4] 
|
|
|
|
|
