Benutzer Diskussion:Redeemer/IconCheck

Nur mal für mein Verständnis: z.B. diese Datei, warum genau wird die jetzt als "falsch" markiert? In meinen Augen ist ein irgendwie gearteter Qualitätsverlust nicht erkennbar, und sieht mir doch bei über 90% der Stichproben die ich jetzt genommen habe, doch sehr weit hergeholt aus. Ein einziges Icon habe ich gefunden, was wirklich schlechte Qualität hatte, obwohl es 64x64 war, während hier mehr als nur ein bisschen wirkliche Arbeit wartet. Im übrigen heißt der Namensraum für Dateien seit etwa zwei Jahren "Datei:" und nicht Bild, was wir auch jedem neuen Benutzer hier ausgiebig predigen. --Think 08:42, 14. Mär. 2013 (CET)

Was der Bot macht, ist dass er die Farben pro 4x4-Texel zählt. Mehr als vier Farben sind bei DXT nicht möglich und da alle Icons aus dem in ihrem Leben mal DXT waren, erwarte ich diese Eigenschaft bei den PNG-Dateien. Die genannte Beispieldatei sieht hier auf dem Handy in der Tat korrekt aus, ich schau zu Hause nochmal nach. Aber die Abmessungen werden ja auch bewertet und da wiegt der Qualitätsverlust schwerer. Durch Bild statt Datei haben wir immerhin über 7KiB Seitengröße gespart. -- 18:29, 14. Mär. 2013 (CET)

Bist du schon dazu gekommen dir das nochmal genauer anzuschauen? --Hraun 13:43, 17. Mär. 2013 (CET)

Das ist eine Eigenart von U-Mod. Jeder 4×4-Block kann ja vier Farben haben: Zwei davon sind als RGB565 in der Datei angegeben und die anderen zwei äquidistant dazwischen verteilt (d.h. bei der Konvexkombination der beiden Farben an TV 1/3 und 2/3). Bei der Umrechnung der angegebenen Farben vom RGB565- ins übliche RGB888-Modell (mit 8 Bits pro Farbkanal) gibt es bei beim Grün-Kanal bereits Kommawerte durch die Multiplikation mit 8,225806451612903=255/31 (blau und rot werden mit 15 multipliziert). Bei der Interpolation der zwei Zwischenfarben ergeben sich weitere Kommawerte. Beim Speichern in anderen Formaten als PPM-ASCII (da hier die Anzahl der Farbabstufungen beliebig gesetzt werden kann, in diesem Fall auf kgV(15,31)*3=15*31*3) gibt es durch die Rundung auf die bekannten 256 Stufen je Kanal Rundungsfehler. Diese versucht U-Mod zu verringern, indem es bei jedem Pixel und für jeden Farbkanal nach einem bestimmten Dithering-Verfahren entscheidet, ob es auf- oder abrundet. Dies ist nicht standardkonform und sinnlos, da der Verlust durch die Komprimierung (im ungünstigten Fall 128 Farbabstufungen pro Pixel) deutlich höher ist als beim Runden (maximal 1,5 Farbabstufungen pro Pixel). Durch das Rundungsschema kann dieselbe Farbe auf 8 verschiedene Arten ausgegeben werden (jeder Kanal einmal auf- und einmal abgerundet, wobei ich vermute, dass rot und grün auf gleiche Weise gerundet werden), was den Bot irritiert. Ich werde den Bot so verändern, dass er dies ignoriert. -- 23:27, 29. Mär. 2013 (CET)