Posts by christophmair

Hallo Samael,

weist du schon einen release Termin für die 0.0.7? Mit den darin enthaltenen Änderungen (calculations.c/.h) bin ich glücklich. Das letzte was mich noch "stört" sind die pluginspezifischen Methoden in der setup.h
Wenn diese noch in einer anderen Klasse wären (cVdrSetup?) und in der eigentlichen setup.h nur mehr die Klasse mit den public-Variablen übrig bleibt ist auch die letzte zur Berechnung wichtige Klasse VDR-unabhängig. setDefault() und SetStatic() können natürlich in der Klasse verbleiben. Die restlichen notwendigen Klassen kann ich für MythTV zuschneidern ohne was vom Plugin zu ändern.

Wenn du das noch ändern könntest wäre ich mit der bestehenden API zufrieden

Grüße,
Christoph

Hallo Samael,

Quote

tut mir leid, aber Deinen Vorschlag kann und werde ich so nicht akzeptieren.

Das sollte auch ein erster Vorschlag sein, keine fertige Lösung.

Quote

Diese Klasse berechnet aus den Eingangsdaten (welcher Art auch immer)
Farbwerte, die eigentlich auch direkt an den Controller geschickt werden
könnten (tColorPacket-Typ).

Ist klar, soll auch so bleiben, nur hätte ich den Code für die eigentliche Berechnung ausgelagert, damit bei verschiedenen Input-Klassen (welche alle Bilder bearbeiten) der Berechnungscode nur an einer Stelle gewartet werden muss.
Bei Musik dasselbe Prinzip, nur andere Berechnungen (Analyzer). wenn z.B. der Musik-Analyzer nur wav-samples verarbeiten kann, konvertieren die Input-Klassen ihre Quelldaten entsprechend.

Quote

Außerdem: was ist mit anderen Input-Klassen
und mit Input-Klassen, die keinen Thread benötigen?

Bei den Input Klassen muss ich mir noch was besseres überlegen. Da hab ich nicht weit genug gedacht. Wenn Du hierzu eine gute Idee hast, bitte posten.

Quote

Und als Parameter dann den Setup-Wert? Man kann sich auch "tot-kapseln".

Dies liefert gleich die gesamte Klasse, nicht einzelne Werte. Tot-kapseln muss nicht sein.

Quote

Diesen ganzen Aufwand nur damit man das so kompilieren kann?

Was ich erreichen möchte ist folgendes: Die Analyzer, Filter, Setup und die Atmolight Klasse sollten unabhängig vom VDR nutzbar sein.
Die Input-Klasse ist sowiso an die jeweiligen Gegebenheiten anzupassen. Die Output's evtl. auch.
Die gesamte Steuerung des Atmolight(ein, aus, Setup usw.) sollte durch Zugriff auf die Atmolight-Klasse und (über getSetup()) auf die Setup-Klasse möglich sein. Die Schnittstelle zum VDR hat also nicht komplett in einer Klasse zu sein, sondern kann sich natürlich auf mehrere Klassen verteilen. Nur die Schnittstelle zum Atmolight sollte sich auf die Atmolight-Klasse beschränken. Diese muss eben über entsprechende Methoden verfügen um auf alle relevanten internen Prameter zugreifen zu können (Input, Output, und Setup)

Quote

Wie oben schon gesagt und nur noch mal zur Verdeutlichung: Im VDR
gibt es keinen Anzeige-Thread in Deinem Sinne.

Das ist mir schon klar. Wie gesagt muss das noch überarbeitet werden.

Ich hoffe jetzt ist es etwas besser verständlich wie ich mir das vorgestellt habe.

Gruß,
Christoph

Hallo,

da ich das Atmolight gerne in MythTV integrieren möchte hab mir mal eine allgemeine API überlegt. Hier mein Vorschlag:

• Input
  Es gibt eine abstrakte ImageInput-Klasse, welche als einzig nötige Methoden getHSVImage(), getHeight() und getWidth() fordert. Die Umrechnung von YUV, RGB usw. die von den verschiedenen Bildquellen kommen übernimmt die Input-Klasse.
  Für andere Anwendungen (z.B. Audio) gibt es Klassen die ebenfalls die Eingabedaten (z.B. mp3-Stream) in ein für die Analyzer verständliches Format umwandeln (z.B. wav).
• Analyzer
  Für die Bild- (oder Ton) Analyse gibt es Analyzer-Klassen welche z.B. das HSV-Bild mit getHSVImage() vom Input lesen und daraus die Farben berechnen. Die einzig notwendige Schnittstelle ist die Methode tRGBColor analyze(Input* input) welche die berechneten Farben zurückgibt.
• Atmolight
  Die Atmolight-Klasse verwaltet die Input und Analyzer Klassen sowie die noch notwendigen Klassen zur Farbkorrektur (Filter, Gamma, Brightness, ..). Auch die Output-Klassen werden von hier aus verwaltet.
• Output
  Die Output-Klassen sollten sich so wie bereits vorhanden integrieren lassen.

Um den für die FFDVBInput-Klasse notwendigen Thread einzubauen würde ich das gesamte Konstrukt in eine übergeordnete Thread-Klasse einbauen (z.B. cVdrAtmo). Diese Klasse soll auch die restlichen für den VDR und dessen OSD notwendige Klassen verwalten. Auf das Setup kann aus der Atmolight-Klasse mit getSetup() zugegriffen werden. Wenn die gesamte Schnittstelle zum VDR in dieser Klasse realisiert wird, kann das Atmolight auch ohne VDR-Header verwendet und kompiliert werden.
Den Zugriff auf die Setup-Klasse würde ich über die bestehenden String-basierten Methoden set(variablenname, wert) und get(variablenname) realisieren, da ich diese auch in MythTV gut verwenden kann.
Noch eine Bemerkung, warum ein Input-Device kein Thread sein sollte: bei MythTV (vielleicht auch beim Softdevice?) schicke ich jedes Bild via setImageRGBA() vor der Anzeige zum Analysieren. Da sorgt also der Anzeige-Thread für den Nachschub an Bildmaterial.

Soweit mein Vorschlag. Wenn ich was übersehen habe oder jemand Verbesserungsvorschläge hat, immer her damit. Wenn noch was unklar ist einfach fragen.

Grüße,
Christoph

Hallo Samael,

ich bin begeistert vom Atmolight und arbeite gerade an einer Integration in MythTV. Bis jetzt bin ich soweit dass die Berechnung der Farben funktioniert. Allerdings habe ich dazu das Plugin ziemlich "verwüstet", da ich das Plugin ja ohne VDR kompilieren muss. Dazu hab ich eine Kopie der inputffdvb.c (inputmythtv.c) so angepasst dass das Quellbild als Parameter an die Funktion CalcColors() übergeben wird. Die Setup-klasse wird ebenfalls benötigt; von der hab ich nur die Referenzen zum VDR (u.a. das OSD) auskommentiert.
Um künftige Updates leichter integrieren zu könen wäre es toll wenn die Berechnung in eine extra Klasse mit entsprechender API verschoben werden könnte und die Setup-Klasse vom VDR unabhängig wäre. Das eigentliche VDR-Plugin würde dann das Setup über eine OSD-Klasse ansteuern.
Soweit meine Vorstellung..
Glaubst du sowas wäre machbar? Damit wäre das Atmolight jedenfalls universeller einsetzbar, da auch als stand-alone Applikation lauffähig.
Und vielleicht hilfts ja auch bei der Unterstützung vom Softdevice, aber da bist du der Experte.

Grüße,
Christoph

Hallo samc,

Quote

Mein Plan wäre schon das ganze "surround" aufzubauen, obs nun bestückt wird oder nicht, also 3x4 = 12 Kanäle, der DM163 kann ja sogar 24.

Würde ich auch machen, bzwl. zumindest die Möglichkeit dazu vorsehen.

Laut dieser Seite ist der MBI5030 noch besser als der TLC5940. Bleibt das alte Problem: wo kaufen? Habe bis jetzt noch nichts gefunden. Vielleicht müsste man beim Hersteller nach Händlern fragen, weil dieser auf seiner Homepage keine Händler listet, sondern nur Länder in denen welche sein sollen..

Vom SiTI hab ich leider noch nichts neues..

Gruß,
Christoph

P.S. der TLC5941 hat im Gegensatz zum TLC5940 kein EEPROM zum Speichern der Helligkeitskorrektur, ist dafür aber ein bischen günstiger.

Hallo,

Quote

Nachteil: die Dotkorrektur ist in unserer Applikation wohl soeinfach nicht nutzbar, weil hinter den Baustein noch MOSFET Endstufen müssten um viele LEDs anzusteuern, soll ja nicht jede ein eigener Kanal werden (außer das ist billiger :-))

Die Stromsteuerung könnte man mit "Stromspiegeln" auch mit mehreren LEDs nutzen z.B. FET SOT143 BCV61C bei RS-Components. Billiger wird das so natürlich nicht..

Den TLC5940 gibts bei Farnell, ein Beispielprojekt unter http://si-light.sourceforge.net/

Alternativ gibts auch den STP16C596 mit 16-Bit
Da müsste ich jedoch das Datenblatt nochmals genauer lesen. Zu kaufen bei Spoerle
[EDIT] Scheinbar lassen sich mit dem die LEDs nur ein oder ausschalten.. Dann wäre er für uns nicht geeignet. [/EDIT]

Distributoren von SiTI (z.B. DM163) sind hier gelistet: http://siti.com.tw/product/distribution.html. Allerdings konnte ich die Chips bei niemandem finden bzw. die Anbieter haben keinen "normalen" Onlineshop.

Gruß,
Christoph

Hallo samc,

du meinst sowas: TLC5940
16 x 12 Bit PWM, über SPI programmierbar, mit zusätzlicher 6 Bit Helligkeitskalibrierung pro Kanal.
Der Takt muss im Gegensatz zum PCA9633 selbst erzeugt werden. Ausserdem muss alle 4096-Takte der interne Counter resettiert werden. Das sollte jedoch kein allzu großes Problem darstellen.

Gruß,
Christoph

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