[ANNOUNCE] Atmolight - Release 0.0.6

  • Guten Abend,


    es gibt wieder eine neue Version des Atmolight-Plugins:


    Download hier.


    Die Änderungsauflistung befindet sich in der History-Datei.


    Achtung:
    Die Namen zur Speicherung der Parameter in "setup.conf" wurden geändert.
    Wer seine Einstellungen behalten möchte, sollte sich diese notieren.
    Auf jeden Fall sollte der VDR beendet werden und alle Einträge mit
    "atmo." aus der Datei entfernt werden (damit keine unnötigen
    Log-Einträge entstehen).


    Zudem suche ich immer noch Mitstreiter, die helfen,
    weitere Input-Devices (z.B. über Softdevice, etc.) zu entwickeln.
    Ich besitze nur eine FFDVB-Karte und benutze keine weiteren
    Ausgabemittel (kann somit auch nicht testen). Außerdem ist meine
    Motivation für etwas, was ich nicht testen kann bzw. nicht einsetze
    nicht gerade groß :whatever.
    Fragen dazu können gerne hier im Forum an mich gestellt werden.


    Bei Fragen, Anregungen, etc. bitte hier posten.


    Viel Spaß beim Testen
    Samael


    P.S.: Diesen Thread bitte NUR zur Diskussion der Software verwenden.
    Es soll hier nicht um irgendwelche Sets gehen.

    Für Heilige gibts 'nen Heiligenschein - für Fernseher das Solarstorm.

    The post was edited 2 times, last by Samael ().

  • Tja wie gesagt, als Tester bin ich gern bereit alles in meiner Macht mögliche beizutragen damit auch andere Input-Devices wie z.B. Softdevice laufen.


    Wäre schade wenn man diese Option nicht einbauen würde, da dies die Beliebtheit des Atmolight sicher steigern würde und ich es endlich auch unter Linux nutzen könnte :lovevdr


    Grüß
    DKVT

  • Quote

    Tja wie gesagt, als Tester bin ich gern bereit alles in meiner Macht mögliche beizutragen damit auch andere Input-Devices wie z.B. Softdevice laufen.


    Ich weiß, ich weiß. Und ich habe Dich nicht vergessen.
    Aber es kann bestimmt jeder nachvollziehen, daß man bei einer Sache,
    die einem persönlich erstmal so nichts wirklich bringt, nicht mit richtigem
    Herzblut dabei ist.
    Ich werde aber trotzdem versuchen, in dieser Richtung zu gucken,
    was da geht.


    Grüße Samael

  • Das wäre echt super, wäre nämlich echt schade wenn ich meinen Plasma-TV über RGB einer FF-Karte anschliessen müsste... die Qualität ist sicherlich schlechter als mit Softdevice über DVI

  • Quote

    Original von Samael
    ...Auf jeden Fall sollte der VDR beendet werden und alle Einträge mit
    "atmo." aus der Datei entfernt werden (damit keine unnötigen
    Log-Einträge entstehen)...


    Hallo Samael,


    danke für die neue Version.
    Beim inbetriebnehmen ist mir folgendes aufgefallen:
    Die Einstellung "atmo.Startmode =" wird nicht neu eingetragen.
    Nach einem Neustart war bei mir das Atmo-Light immer an obwohl
    "immer aus" eingestellt war.


    Gruß Kail

    VDR: ASUS P4P800-VM, Celeron 2.5 GHz, 256 MB-RAM, 2 x 160 GB Samsung SV1604N, TT 1.5 (4MB), TT-Budget, Extension-Board (TBE)
    LinVDR0.7 + Dr.Seltsam 2.6.18 + vdr-1.4.7 + BP + diverse Plugins
    Betatester v. steini-Paketen
    Test-VDR: ASUS P5QL Pro, E7500, 4 GB RAM, 1TB WD EADS, Media-Pointer S2, Ubuntu10.10 + vdr-1.7.16

  • Hallo Kail,


    kann es sein, daß Du nach der Änderung im Setup-Menü das Menü
    nicht mit der Taste "OK" verläßt?
    Wenn Du statt dessen z.B. "Abbrechen" drückst, wird zwar die Einstellung
    beibehalten, aber nicht in die setup.conf übernommen.
    Ist für alle anderen Einstellungen genauso. Sie müssen alle mit "OK"
    quittiert werden.
    Gefällt mir auch nicht so ganz, ich hatte aber noch keine Lust, in den
    einzelnen Setup-Menü-Klassen für die angezeigten Werte temporäre
    Variablen einzufügen deren Wert angezeigt wird und bei Druck auf "OK"
    in die echten Setup-Variablen umkopiert werden. Nächste Version
    vielleicht ...


    Gruß Samael

  • Hallo Samael,


    werde das morgen noch einmal überprüfen und berichten.


    Gruß Kail

    VDR: ASUS P4P800-VM, Celeron 2.5 GHz, 256 MB-RAM, 2 x 160 GB Samsung SV1604N, TT 1.5 (4MB), TT-Budget, Extension-Board (TBE)
    LinVDR0.7 + Dr.Seltsam 2.6.18 + vdr-1.4.7 + BP + diverse Plugins
    Betatester v. steini-Paketen
    Test-VDR: ASUS P5QL Pro, E7500, 4 GB RAM, 1TB WD EADS, Media-Pointer S2, Ubuntu10.10 + vdr-1.7.16

  • 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 Christoph,


    tut mir leid, aber Deinen Vorschlag kann und werde ich so nicht akzeptieren.
    Ich werde nicht aufgrund eines Wunsches eines Einzelnen ein
    funktionierendes Plugin umbauen (Never change a running system!).
    Zumal es in meinen Augen mit dem Einbau der Softdevice-Funktionalität
    erstmal "fertig" ist und ich das Plugin auch nicht einfach nur so codiert
    habe, sondern mir über die einzelnen Klassen auch Gedanken gemacht habe.


    Input:
    Diese Klasse berechnet aus den Eingangsdaten (welcher Art auch immer)
    Farbwerte, die eigentlich auch direkt an den Controller geschickt werden
    könnten (tColorPacket-Typ). Diese werden über die Methode
    GetColorPacket() zur Verfügung gestellt. Die zwischenzeitliche Umrechung
    in den HSV-Raum ist nur Mittel zum Zweck (würde z.B. bei Musikdaten
    überhaupt keine Verwendung finden). Der Controller versteht nur RGB.


    Analyzer:
    Geschieht abhängig von den Eingangsdaten; erfolgt also in der Input-Klasse.


    Atmolight:
    Wie gehandhabt und auch geschrieben.


    Output:
    Wie gehandhabt und auch geschrieben.


    Quote

    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).


    Nein, das hatten wir schon mal. Außerdem: was ist mit anderen Input-Klassen
    und mit Input-Klassen, die keinen Thread benötigen?


    Quote

    Auf das Setup kann aus der Atmolight-Klasse mit getSetup() zugegriffen werden.


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


    Quote

    Wenn die gesamte Schnittstelle zum VDR in dieser Klasse realisiert wird, kann das Atmolight auch ohne VDR-Header verwendet und kompiliert werden.


    Diesen ganzen Aufwand nur damit man das so kompilieren kann? Und
    damit evtl. den Code auch noch unleserlicher und unverständlicher machen?
    Nein, das Ganze ist schließlich ein VDR-Plugin.


    Quote

    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.


    Bestehend? Es gibt keine set- und get-Methoden auf die Setup-Klasse.


    Quote

    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.


    Kann schon sein, das MythTV das so macht. Der VDR arbeitet aber
    normalerweise mit Full-Featured-DVB-Karten. Die berechnen und zeigen
    das Bild an. Der VDR hat im Normalfall aber keine Kenntnis vom Bildinhalt.
    Also muß man sich das Bild aus dem Framebuffer holen (Holen! Da wird
    einem nichts geschickt.).
    Beim Softdevice ist es genauso. Da wird sich die Input-Klasse das
    Bild aus dem Softdevice-Plugin besorgen müssen.
    Und um das Ganze nun in definierten zeitlichen Abständen durchzuführen
    ist die Thread-Notwendigkeit sehr wohl gegeben.


    Quote

    Da sorgt also der Anzeige-Thread für den Nachschub an Bildmaterial.


    Wie oben schon gesagt und nur noch mal zur Verdeutlichung: Im VDR
    gibt es keinen Anzeige-Thread in Deinem Sinne. Der Nachschub an
    Bildmaterial (erstmal nur zur Ausgabe an den TV) erfolgt im
    Normalfall in Hardware.


    Grüße Samael

  • 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 Christoph,


    Quote

    nur hätte ich den Code für die eigentliche Berechnung ausgelagert,


    für 0.0.7 habe ich das gemacht. Es gibt nun eine calculations.c/.h, die
    die Funktionen
    tColorPacket CalcColorsAnalyzeHSV(tHSVColor *HSV_Img);
    tHSVColor RGB2HSV(tRGBColor color);
    tRGBColor HSV2RGB(tHSVColor color);
    enthält. Die Auslagerung habe ich durchgeführt, weil die Funktionen
    nun auch von inputsoftdevice benötigt werden.
    Vorher führe ich im Normalfall solche Umstrukturierungen nicht durch,
    da man schlecht beurteilen kann, ob sie Sinn ergeben.


    Quote

    Bei den Input Klassen muss ich mir noch was besseres überlegen.


    Ich würde die Input-Klassen an MythTV anpassen. Das Prinzip scheint ja
    dort eh ein anderes zu sein (VDR: Bilddaten abholen, MythTV: Bilddaten
    werden geliefert), wenn ich Dich richtig verstanden habe.


    Quote

    Dies liefert gleich die gesamte Klasse, nicht einzelne Werte.


    Dann kann man auch gleich, so wie jetzt auch, direkt auf die Setup-Klasse
    zugreifen.


    Quote

    Die Analyzer, Filter, Setup und die Atmolight Klasse sollten unabhängig vom VDR nutzbar sein.


    Analyzer wirds nicht geben. Das macht die Input-Klasse.
    Filter und Setup sind schon VDR unabhängig.
    Die Atmolight-Klasse kann nicht VDR-unabhängig sein, da diese direkt vom
    VDR eingebunden wird. Solltest Du die AtmoThread-Klasse meinen:
    da wird es auch schwierig. Es muß auf jeden Fall von Thread abgeleitet
    werden.


    Quote

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


    Das war eigentlich vorher schon klar. Und nochmal: ich werde nicht
    mehr großartig an der Struktur rumbrechen (sorry :) ).
    Außerdem sehe ich noch nicht, daß der Großteil VDR- oder
    MythTV-unabhängig werden könnte. Atmolight ist eben ein Plugin für
    den VDR und Du willst ein Plugin für MythTV schreiben. Da muß man sich
    an das entsprechende Hauptprogramm anpassen.
    Versuch doch mal meine Struktur für MythTV nachzubauen:
    Es gibt Input-Klassen, die sich das Bild holen oder anderweitig
    bekommen und fertig zur Ausgabe an den Controller berechnen.
    Dann eine Klasse, die Input und Output verbindet und noch
    entsprechende Änderungen am Bild durchführt (Filter, etc.).
    Und dann die Output-Klassen: Sie schicken einfach die berechneten
    Farbdaten an den Controller über die entsprechende Schnittstelle.


    Grüße Samael

  • 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 Christoph,


    Du hast eine PN.


    Quote

    weist du schon einen release Termin für die 0.0.7?


    wenn das Softdevice als Input funktioniert :).


    Quote

    Mit den darin enthaltenen Änderungen (calculations.c/.h) bin ich glücklich.


    Fein.


    Quote

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


    Ich werde mir da mal unter der Woche was einfallen lassen.


    Grüße
    Samael

    Für Heilige gibts 'nen Heiligenschein - für Fernseher das Solarstorm.

    The post was edited 1 time, last by Samael ().