GraphLCD Logo Update 3.0

Zitat

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

Auch von mir nochmal ein fettes Danke für Deinen unermüdlichen Einsatz!!!

Gruss Steve135

Besten dank, macht sich gut auf dem Display.

cu

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

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

Zitat

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

Zitat

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!

Zitat

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.

Zitat

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

Läuft bei mir wunderbar.

Zitat

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.

Zitat

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

Zitat

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

Zitat

Läuft bei mir wunderbar.

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

Zitat

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

Zitat

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.

Zitat

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.

Zitat

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:

Zitat

Originally posted by Mreimer
http://www.imagemagick.org/scr…ons.php#transparent-color

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

Zitat

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.

Zitat

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