GraphLCD Logo Update 3.0

  • Hallo,


    ich habe mal wieder ein paar neue Logos (Größe L) für glcd gepixelt.
    wbreu hat diese Logos wie auch schon die aus Update 2.0 in ein grooooßes Logo-Paket aufgenommen und eine aktualisierte channels.alias erstellt (DANKE!).


    neu in diesem Paket
    - alle HD+ Sender vorhanden (also jetzt auch SIXX, RTL2 und Sport1)
    - alle Sky Welt Extra Programme (Sky ist somit ebenfalls komplett)
    - Anixe SD


    überarbeitet:
    - viele Sky Logos verbessert
    - Eurosport, Sport1 verbessert


    Downloaden könnt ihr das Paket von wbreu's homepage
    http://wbreu.htpc-forum.de/vdr…rgraphlcdplugin/index.php


    Viel Spaß mit den Logos


    Gruß DaRookie


    PS: für Kritik und Vorschläge bezüglich neuer Logos bin ich immer offen ;-)

  • Quote

    Originally posted by DaRookie
    PS: für Kritik und Vorschläge bezüglich neuer Logos bin ich immer offen ;-)


    Vielen Dank für deine Arbeit.


    Und wenn du schon nach Vorschlägen fragst ;) Bei Nick/Comedy und Dr. Dish TV ist mein Display noch Logolos. Und mir fehlen da leider völlig irgendwelche GFX Talente.


    cu

  • ...was du heute kannst besorgen...


    muss man nur noch in glcd wandeln...

    Images

    • NICK_COMEDY_l.bmp

    Technotrend Rev. 1.6, CT-VDR 6.1; LIRC [Atric-Einschalter], GraphLCD [240x128], ACPI-WakeUp
    Board: Elitegroup Flex-ATX, CPU: Pentium III (Coppermine) 850MHz, RAM: 512MB, HDD: WD 160GB

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

  • Besten dank, macht sich gut auf dem Display.


    cu

  • Quote

    Besten dank, macht sich gut auf dem Display.


    hau die glcd doch gleich hier rein dann kann wbreu sie gleich mit aufnehmen
    wenn er das nächste Mal sein Paket aktualisiert.


    danke!

    Technotrend Rev. 1.6, CT-VDR 6.1; LIRC [Atric-Einschalter], GraphLCD [240x128], ACPI-WakeUp
    Board: Elitegroup Flex-ATX, CPU: Pentium III (Coppermine) 850MHz, RAM: 512MB, HDD: WD 160GB

  • Wenns die Sache vereinfacht. Bin mir nur nicht sicher obs so korrekt ist, das Orginal war IMHO invertiert. Ich habs mal zurückinvertiert (siehe PNG) und als NICK_COMEDY_l.glcd-invertiert.txt noch mit angehängt.
    (.txt entfernen)


    cu

  • ...das "invertierte" war Absicht...ich glaube das original-Logo ist
    weiße Schrift auf schwarzem Hintergrund...und ein orangener Klecks ;-)


    ist aber sicher geschmackssache was sich auf dem Display dann besser macht


    Gruß

    Technotrend Rev. 1.6, CT-VDR 6.1; LIRC [Atric-Einschalter], GraphLCD [240x128], ACPI-WakeUp
    Board: Elitegroup Flex-ATX, CPU: Pentium III (Coppermine) 850MHz, RAM: 512MB, HDD: WD 160GB

  • hallo,


    ich plane ja das format der bilder umzustellen, was waere euch denn recht? ich dachte an
    bmp und/oder jpg (2 und 256 farben). gibts sonst irgendwelche ideen?


    PS: werde in den kommenden tagen die skin patches von wastl in git/HEAD uebernehmen,
    und danach diese logo umstellung angehen.


    gruss,
    -- randy

  • Quote

    Originally posted by randy
    ich plane ja das format der bilder umzustellen, was waere euch denn recht? ich dachte an
    bmp und/oder jpg (2 und 256 farben). gibts sonst irgendwelche ideen?


    Die Skin Version kann ja jetzt schon pbm (binär). Jedenfalls sind die Logos bei mir alle in pbm und das funktioniert super.


    jpg halte ich für ungünstig, das Format ist für diese Art Bild ungeeignet. Das ist Verlustbehaftet und nur als True Color oder 256 Graustufen möglich. D.h. du müsstet bei jedem Bild die Farben zählen um zu entscheiden obs gültig ist ;)



    Was ist mit PNG? Kann 1 und 8 BPP, Transparenz und hat nen AlphaChannel.
    Und es gibt ne inoffizielle Erweiterung für animierte PNG ( http://de.wikipedia.org/wiki/A…Portable_Network_Graphics ). Ferner bekommt man dort Metainfos rein.


    cu

  • Quote

    hallo, ich plane ja das format der bilder umzustellen, was waere euch denn recht? ich dachte an bmp und/oder jpg (2 und 256 farben). gibts sonst irgendwelche ideen?


    Also ich bin zwar mit Grafikformaten nicht sooo arg vertraut, aber tendenziell schließ ich mich Keine_Ahnung an und würde in Richtung PNG denken.


    JPGs verlieren so gern an Schärfe...und werden durch die Kompression gern etwas verwaschen. Ich meine auch irgendwo gelesen zu haben dass bei Grafiken mit "scharfen Kanten" PNG gegenüber JPG vorzuziehen ist.
    Das wäre ja dann speziell bei Logos vorteilhaft.

    Technotrend Rev. 1.6, CT-VDR 6.1; LIRC [Atric-Einschalter], GraphLCD [240x128], ACPI-WakeUp
    Board: Elitegroup Flex-ATX, CPU: Pentium III (Coppermine) 850MHz, RAM: 512MB, HDD: WD 160GB

  • Quote

    Original von randy
    ich plane ja das format der bilder umzustellen, was waere euch denn recht?


    Meiner bescheidenen Meinung nach sollte man das Format verwenden, für das man nicht noch eine externe Library anflanschen muss.


    Beim Logo-Erstellen ist eine Wandlung kein Thema. Im Zweifelsfall wird vom "Wunschformat" des Logo-Erstellers einfach in einem Rutsch via imagemagick in das graphlcd-Format gewandelt. Da das glcd-Format aber doch ein Sonderfall ist, wäre eine Umstellung auf etwas gängiges sicher nicht falsch.


    AFAIK ist das Format, das im VDR-Bereich üblich ist, das XPM-Format, richtig? In diesem Fall sollte das auch für das graphlcd-Plugin genutzt werden.
    Nachtrag: Hab nachgesehen und kann jetzt bestätigen, dass im VDR-Bereich das XPM-Format das üblichste Format ist. Der VDR selber hat im Source XPM-Dateien:
    http://projects.vdr-developer.…=vdr.git;a=tree;f=symbols

  • Wobei das xpm so wie es skinenigma benutzt sehr mühselig und fummelig ist. Dort muss ich die Logos nach der Konvertierung mit ImageMagick immer mit nem Texteditor nachbearbeiten damit das funktioniert. Wenn dann graphlcd den selben Code nutzen sollte wäre es irgendwie ein Rückschritt.


    Also dann IMHO doch lieber ne vernünftige lib anflanschen anstatt mal schnell selber was zu basteln.


    Im Zweifel halt bmp, das ist sehr einfach aufgebaut und was anständig binäres.


    cu

  • Abhängigkeiten sind per Default erstmal immer dann schlecht, wenn man sie irgendwie vermeiden kann.


    xbm wurde auch schon erwähnt. Soll wohl schon gehen mit der 0.2.0pre. Wäre also wohl einfach zu portieren und allemal besser als eine zusätzliche Abhängigkeit.


    Was die Konvertierung angeht: Ich kenne skinenigma nicht. Keine Ahnung was da falsch läuft. Eventuell könnte man das Problem aber entweder via Fix am Skin oder mit anderen imagemagick-Parametern in den Griff bekommen.


    Und was "anständig binäres" angeht: Binär ist in der heutigen Zeit niemals anständig und gerade bmp ist proprietär. Bitte nicht sowas!

  • Quote

    Originally posted by Mreimer
    Abhängigkeiten sind per Default erstmal immer dann schlecht, wenn man sie irgendwie vermeiden kann.


    Das stimmt.
    Aber ab irgendeinen Punkt steht man vor der Entscheidung entweder irgendwas halbherzig hinzupfushen (anständigen Support für ein Grafikformat programmiert man mal nicht eben in 5 Minuten) oder ne Menge Zeit mit etwas zu verbringen was andere schon lange implementiert haben.


    Wobei ich eher der Pascal Typ bin, da ist so was anscheinend alles wesentlich einfacher. Deswegen wundert mich diese ganze Diskussion irgendwie auch sehr.


    Quote

    Originally posted by Mreimer
    xbm wurde auch schon erwähnt. Soll wohl schon gehen mit der 0.2.0pre.


    Läuft bei mir wunderbar.


    Quote

    Originally posted by Mreimer
    Was die Konvertierung angeht: Ich kenne skinenigma nicht. Keine Ahnung was da falsch läuft. Eventuell könnte man das Problem aber entweder via Fix am Skin oder mit anderen imagemagick-Parametern in den Griff bekommen.


    DAS ist das Problem, einmal schnell irgendwas seltsames genommen und JEDER User fummelt da stundenlang rum.
    Ein Problem ist z.B. das die Transparente Farbe an erster Stelle in der Farbliste stehen muss. Keine Ahnung obs dafür nen Parameter gibt, der Texteditor ist schneller als sich da reinzufummeln.


    Mach mal XPM mit nem Texteditor auf ;) Dann siehst du das es nur nen Workaround dafür ist, das ELF keine Resourcen kann. Und so was als Grafikformat nutzen... schon ne seltsame Idee.


    Quote

    Originally posted by Mreimer
    Und was "anständig binäres" angeht: Binär ist in der heutigen Zeit niemals anständig


    Jup, am besten gleich XML, natürlich in Unicode, dann kann man den Speicherbedarf nochmal verdoppeln ;) Dann brauchts aber natürlich nen DOM Parser im Code (natürlich mal schnell selbst programmiert damit man keine Abhängigkeiten hat ;) ) damit das auch anständig portabel ist.
    Und da wundern sich Leute doch tatsächlich warum die Rechner immer träger werden obwohl die Hardware immer leistungsfähiger wird. Ich glaube ich werde langsam zu alt für den ganzen Kram ;)


    Quote

    Originally posted by Mreimer
    und gerade bmp ist proprietär. Bitte nicht sowas!


    Da sind wir uns wieder einig (war nur nen Vorschlag für einfach, BMP ist ja im Prinzip das selbe wie GLCD, nur genormt). Deswegen auch mein erster Vorschlag mit PNG, das ist offen, etabliert und kann alles was gebraucht wird (sogar die Animationen) ohne irgendwelche Verrenkungen.


    cu

  • Quote

    Läuft bei mir wunderbar.


    Bestens. Dann also xbm als Alternative zum glcd Format. Schon weil der Code bereits existiert.


    Quote


    DAS ist das Problem, einmal schnell irgendwas seltsames genommen und JEDER User fummelt da stundenlang rum.
    Ein Problem ist z.B. das die Transparente Farbe an erster Stelle in der Farbliste stehen muss. Keine Ahnung obs dafür nen Parameter gibt, der Texteditor ist schneller als sich da reinzufummeln.


    http://www.imagemagick.org/scr…ons.php#transparent-color


    Quote


    Mach mal XPM mit nem Texteditor auf ;) Dann siehst du das es nur nen Workaround dafür ist, das ELF keine Resourcen kann. Und so was als Grafikformat nutzen... schon ne seltsame Idee.


    Finde ich ganz und garnicht seltsam, denn dieses Format kann, dank Plain-Text, sehr einfach in allen möglichen Programmiersprachen verarbeitet werden, ohne dafür eine Library oder ein Modul zu benötigen. Der Aufbau ist auf dem ersten Blick offensichtlich. Ich habe in der Vergangenheit schon öfters in Scripten als Zwischenschritt XPM-Dateien erzeugt (z.B. via "convert" aus ImageMagick) um diese Text-Files dann im Script-Code einlesen zu können.


    Quote


    Jup, am besten gleich XML, natürlich in Unicode, dann kann man den Speicherbedarf nochmal verdoppeln ;) Dann brauchts aber natürlich nen DOM Parser im Code (natürlich mal schnell selbst programmiert damit man keine Abhängigkeiten hat ;) ) damit das auch anständig portabel ist.


    UTF-8 benötigt nur für Nicht-Ascii-Zeichen mehr Speicher. Allerdings ist XML selbstverständlich nur für Vektorformate sinnig (SVG). Bei Pixelformaten wäre ein XML, das letztlich Zeilen und Spalten beschreibt, um für jede Zelle einen Farbwert zu merken, schon reichlich Overkill.

  • Quote

    Originally posted by Mreimer


    Bestens. Dann also xbm als Alternative zum glcd Format. Schon weil der Code bereits existiert.


    Da ist was durcheinander gekommen, graphlcd 0.2.0 unterstützt pbm (in der Binär Variante), und das läuft problemlos.


    xpm kam hier zusätzlich ins Gespräch (weil der VDR und skinenigma das nutzen), das läuft aber nicht so toll. Ist aber auch egal, weil wenn der pbm Code schon im 0.2.0er Plugin ist...


    OT:

    Quote


    Ne, es geht da wirklich nur darum an welcher Position in der Liste der Eintrag ist. Der Parser ist halt ein wenig seltsam.


    Quote

    Originally posted by Mreimer
    Finde ich ganz und garnicht seltsam, denn dieses Format kann, dank Plain-Text, sehr einfach in allen möglichen Programmiersprachen verarbeitet werden, ohne dafür eine Library oder ein Modul zu benötigen.


    Naja, man braucht schon Code dafür.


    Quote

    Originally posted by Mreimer
    UTF-8 benötigt nur für Nicht-Ascii-Zeichen mehr Speicher.


    War auch absichtlich einwenig überzogen formuliert ;)
    Ist halt eines meiner Lieblings Meckerthemen, nicht zu ernst nehmen, ich kanns mir nur nicht verkneifen da mal so was los zu werden ;) Bin halt nen Fan von sauberen Binärformaten.


    cu

  • mhm, ohne externe lib wirds schon schwierig. libjpeg benoetigt ja der vdr schon selber,
    d.h. die sollte es geben, aber ja, ich kenn die probleme mit der qualitaet/aliasing etc.. :)


    png8 wuerde mir gut gefallen, ich denke eine weitere -dev lib sollte kien problem sein?
    evtl. mit "nur" pbm support und wenn le lib gefunden ist png zusaetzlich? mit entsprechender
    fehlermeldung um logfile?


    geht ja nicht nur um die logos selber, sondern auch um die symbole in den skins.


    -- randy