[gelöst] Unterstützung von 32 bit pngs seit dem Update vom 140313

  • Oh doch Fireworks und pngquant können das sehr wohl, vorausgesetzt man hat als Vorlage auch ein 32Bit PNG.
    Das korrekte Ergebnis kannst du in loomes seinem Beitrag begutachten...

    "From a little spark may burst a mighty flame." - Dante Alighieri

  • Oh doch Fireworks und pngquant können das sehr wohl, vorausgesetzt man hat als Vorlage auch ein 32Bit PNG.
    Das korrekte Ergebnis kannst du in loomes seinem Beitrag begutachten...


    Wie gesagt, ich habe die 32-bit Grafik aus meinem Post vor 2 Seiten mit pngquant konvertiert: pngquant 256 *.png und das Ergebnis ist deutlich schlechter als das Original. Und selbst wenn es mit Fireworks geht, was bringt das, wenn kaum jemand Fireworks besitzt? Gar nix!


    Es geht doch nur darum, dass möglichst viele Skin- und Pluginbauer tolle Grafiken einbauen können, ohne sich extra irgendwelche Programme zulegen zu müssen und das ist nun mit den 32-bit Grafiken möglich.

  • Nun pngquant ist kostenlos und hat auch eine tolle Stapelverarbeitung was sich zum Beispiel bei vielen Grafiken wie Picons als sehr nützlich erweisen kann.
    Wenn deine mit pngquant konvertierte Schwarz/Weiß Grafik mit AlphaKanal ein deutlichen Qualitätsunterschied zum Original auf weißt dann hast du mit ziemlich großer Sicherheit etwas falsch gemacht.


    Und naja ich würde den 32Bit PNG Support nun nicht gerade als Kompensation für irgend etwas verstehen - die Grafiken sind erheblich größer und auf einigen Geräten besteht absoluter Speichermangel.
    Viel besser wäre es wenn man den den Skinnern und Plugin-Entwicklern erklärt wie man schöne indizierte 8Bit Grafiken mit Semi-Transparenz erstellt, siehe hierzu meinen Beitrag auf Seite 3 : [gelöst] Unterstützung von 32 bit pngs seit dem Update vom 140313

    "From a little spark may burst a mighty flame." - Dante Alighieri

    Einmal editiert, zuletzt von sparksofinsanity ()

  • Wenn deine mit pngquant konvertierte Schwarz/Weiß Grafik mit AlphaKanal ein deutlichen Qualitätsunterschied zum Original auf weißt dann hast du mit ziemlich großer Sicherheit etwas falsch gemacht.

    Ich weiß nicht was man bei einem "pngquant 256 *.png" falsch machen kann, lasse mich aber gerne belehren.



    Und naja ich würde den 32Bit PNG Support nun nicht gerade als Kompensation für irgend etwas verstehen - die Grafiken sind erheblich größer und auf einigen Geräten besteht absoluter Speichermangel.

    Auch das stimmt so nicht. In meinem Beispiel ist die 32-bit Grafik gerade mal 3 kb größer und das ist bei diesem speziellen Problem - Transparenz und Alpa Channel bei 8-bit - immer so, da hier die Anzahl der in der Grafik benutzten Farben nicht erhöht wird. Die 32-bit Grafiken sind nur dann wesentlich größer, wenn diese auch eine entsprechend größere Farbtiefe als die 8-bit Grafiken haben.



    Viel besser wäre es wenn man den den Skinnern und Plugin-Entwicklern erklärt wie man schöne indizierte 8Bit Grafiken mit Semi-Transparenz erstellt, siehe hierzu meinen Beitrag auf Seite 3

    Halte ich für viele User für nicht praktikabel, da viel zu aufwendig und der Aufwand, den du da treibst, zeigt doch sehr gut, dass es ein Problem bei 8-bit indiziert und Transparenz mit Alpa Channel gibt :face_with_tongue:


    Wenn viele Grafik Programme ein Problem mit Transparenz und Alpha Cannel haben, warum soll man in diesem speziellen Fall keine 32-bit Grafik benutzen, zumal diese auch nicht viel größer als die 8-bit Grafiken werden, da die Anzahl der Farben nicht erhöht wird? Deine Argumente kann ich daher nicht nachvollziehen.

    • Offizieller Beitrag

    Hi,


    naja es hängt von der Auflösung des Bildes ab ob es viel größer wird oder nicht.


    Aber in der Regel sind Bilder mit pngquant bearbeitet deutlich kleiner.


    Auf der pngquant Webseite gibt es auch aktuellere Versionen von pngquant. Da sind die Ergebnisse dann nochmal deutlich besser.


    Viele Linux Distributionen benutzt noch sehr alte Versionen.. und auch die Version die viele Skinner benutzen ist noch eine alte.


    Aktuelles e2 kann nun ja jeden typ von PNG Dateien. Also auch mit weniger als 256 Farben.. was dann nochmals die PNGs kleiner macht. Vorher konnte e2 immer nur 8-Bit.. also exakt 256 Farben. So dass auch ein Bild mit nur 4 Farben dann eine Palette hatte mit 256 Einträgen.. was dann halt das Bild wieder etwas größer gemacht hatte.


    Nunja.. aktuell ist das nicht mehr so. Und man kann eine unveränderte pngquant Version verwenden. Abgesehen davon, dass die Bilder kleiner bleiben ist auch der Speicherverbrauch in e2 kleiner. Und Bilder mit Palette werden halt auch schneller geblittet. Also es müssen halt weniger Daten vom "Userspace" in den "Kernel" .. und letztendlich in den "Framebuffer" transportiert werden.


    Also meiner Meinung nach benötigt man (und sollte man auch nur nur 32-Bit verwenden), wenn die Bilder von den Abmessungen recht groß sind und sehr viele Farben benötigen.


    Ansonsten ist das nur Overhead der alles langsam und groß macht.


    cya

  • sie ist 75 Prozent größer.


    7 anstatt 4 kb ist ja fast das doppelte.


    Korrekt, und was willst du damit sagen? 3kb bleiben 3kb und deshalb sollte keiner Box der Platz ausgehen. Die 3kb mehr sind vermutlich die von Ghost erwähnte, größere Farbpalette bei 32-bit. Solange die Farbtiefe sich nicht ändert, wird eine vergleichbare 8-bit Grafik bei 32-bit nur wenig größer sein. Dass es in dem Beispiel 75% sind, hat wohl nur damit zu tun, dass die 8-bit Grafik mit 4kb sehr klein ist. Bei einer 100kb großen 8-bit Grafik wird die 32-bit Variante, ohne Änderung der Farbtiefe, sicher nicht ebenfalls 75% größer, also 175kb groß werden, sondern nur ein paar kb mehr für die größere Farbpalette.


    Ich benutze in meinen Plugins auch nur 8-bit Grafiken und sehe ebenfalls keinen Grund, das zu ändern - außer in dem speziellen Fall des Alpha Channel Problems bei transparenten Grafiken und nur darum ging es mir. Aber anscheinend wird hier aus dem Thema mal wieder wie bei so vielen anderen Themen auch eine Glaubensfrage pro/contra 8-bit gemacht, anstatt das Thema differenziert zu betrachten.