J'ai implémenté le tramage Floyd-Steinberg dans le passé, mais cela n'en valait pas la peine.
Je pense que nous avons besoin d'un tramage adapté à la compression. Connaissez-vous quelqu'un qui pourrait nous aider?
pngquant utilise Floyd-Steinberg modifié pour une meilleure gestion des couleurs.
Je pense que le dithering augmentera toujours la taille du fichier en raison de sa nature aléatoire.
Le seul but de cette particularité — faire plaisir à nos yeux.
Le tramage peut être masqué sous drapeau, tout comme dans Ps. Les utilisateurs décideront.
Je pense que nous avons besoin d'un tramage adapté à la compression. Connaissez-vous quelqu'un qui pourrait nous aider?
Je pense que nous pouvons demander à @kornelski.
Je veux dire, j'ai fait trois versions d'image :
B avait l'air aussi joli que C, mais était légèrement plus grand, alors j'ai pensé qu'il valait mieux autoriser plus de couleurs que le tramage (les deux augmentent la taille du fichier).
Je pense que nous avons besoin d'un dithering, qui consiste en des motifs répétitifs, c'est-à-dire qu'il devrait être "convivial" pour l'algorithme Deflate - faire en sorte que B n'ait que 20 Ko (il est donc toujours aussi agréable que C, mais plus petit).
D'AILLEURS. Je pense également que pngquant effectue un meilleur Deflate (qui prend également environ 100 fois plus de temps que UPNG.js : par exemple 30 ms contre 3000 ms), il peut donc faire en sorte que B n'ait que 20 Ko, tout en utilisant le même tramage que moi.
Oh je vois.
Je ne connais pas l'algorithme de tramage, qui peut gérer ce cas.
pngquant calcule l'erreur mse, a des paramètres de qualité min et max et n'écrit pas le fichier si sa taille est trop grande ou si la qualité se dégrade considérablement.
Peut-être que vous trouvez ce fil utile
https://encode.ru/threads/1757-Lossy-DEFLATE-lossy-PNG
Et ce projet en particulier
https://github.com/foobaz/lossypng
Oui, pngquant calcule l'erreur quadratique moyenne et n'applique le tramage que dans les zones avec une erreur élevée. De cette façon, les zones qui n'ont pas besoin de tramage ne reçoivent pas le bruit supplémentaire.
pngquant effectue également la détection des contours (similaire à l'algorithme de Prewitt) et désactive le tramage sur les contours. Cela empêche l'anti-aliasing de ressembler à de la fourrure.
Dans pngquant 90% du temps est consacré à des séries supplémentaires de K-means. Si vous utilisez --speed 10
toute la recompression (sur i7 2.3Ghz) prend environ 80 ms avec tramage, 50 ms sans tramage.
(BTW, TinyPNG n'a pas son propre algorithme. C'est juste une interface graphique pour pngquant).
Commentaire le plus utile
Oui, pngquant calcule l'erreur quadratique moyenne et n'applique le tramage que dans les zones avec une erreur élevée. De cette façon, les zones qui n'ont pas besoin de tramage ne reçoivent pas le bruit supplémentaire.
pngquant effectue également la détection des contours (similaire à l'algorithme de Prewitt) et désactive le tramage sur les contours. Cela empêche l'anti-aliasing de ressembler à de la fourrure.
Dans pngquant 90% du temps est consacré à des séries supplémentaires de K-means. Si vous utilisez
--speed 10
toute la recompression (sur i7 2.3Ghz) prend environ 80 ms avec tramage, 50 ms sans tramage.(BTW, TinyPNG n'a pas son propre algorithme. C'est juste une interface graphique pour pngquant).