• [^] # Re: Comparatif

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Sortie de YOGA Image Optimizer 1.0. Évalué à 4. Dernière modification le 09 août 2021 à 05:02.

    YOGA Image Optimizer m’intéresse parce que pour le moment j’utilise un ensemble de scripts vite-fait et il est vrai que me reposer sur un outil éprouvé auquel je pourrais éventuellement contribuer est intéressant en mutualisant le développement, plutôt que réinventer la roue...

    Note: dans la compression PNG à perte, il est possible de mettre à plat les pixels RGB quand le canal alpha est entièrement transparent, mais il y a des usages qui nécessitent de conserver ces données invisibles (voir mon commentaire)

    J’utilise pour le moment FileOptimizer pour recompresser les fichiers audio flac. J’ai vu que cet outil est assez efficace pour les PDFs, aussi. Je ne sais pas s’il utilise zopfli. J’aimerai bien un optimiseur PDF qui utilise zopfli =). Je me souviens d’un autre optimizer de PDF (peut-être pdfsizeopt ?) qui avait un fork implémentant zopfli mais qui était non-maintenu (le fork implémentant zopfli).

    Bref, je cherche un outil existant pour par réinventer la roue, mais ça implique pour mon usage de pouvoir lancer les optimisations en ligne de commande.

    Par ailleurs, vu que je fais grand usage de zopfli pour les PNG et que c’est très lent, j’ai implémenté un cache. Dans mon cas précis, je recompresse des dépôts git de données. Je convertis par exemple tous les TGA non-compressés vers PNG avec une commande git qui parcourt tous les commit et fait la conversion, puis ensuite, je parcours à nouveau tous les commits et je copie tous les PNG dans un dossier temporaire avec un nom unique, puis je fait appel à mon outil de compression PNG sur tous ces fichiers. Ainsi le cache se remplit avec les fichiers "optimaux". Puis je vide le dossier temporaire et je parcours à nouveau tous les commits et je lance lance mon outil de compression PNG sur tous les fichiers PNG du dépôt à la date du commit, grâce au système de cache la compression se limite à copier le fichier optimal depuis le cache, ce qui est alors très rapide, plutôt que de repasser par l’étape lente de compression et d’optimisation pour chaque fichier à chaque commit (plusieurs fois le même fichiers).

    À noter que mon outil est adapté à un besoin spécifique et supprime toute métadonnée du fichier PNG originale, ce qui signifie que plusieurs images PNG avec des métadonnées différentes mais produisant le même flux RGBA seront remplacées par le même fichier optimal sans métadonnée. Pour le cache je fais simplement une somme de contrôle du flux RGBA produit, si une image produit un flux RGBA connu, l’outil prend le fichier du cache, sinon compresse et met en cache.

    À propos de PNG et Zopfli, j’ai remarqué qu’optimiser avec oxipng sans zopfli puis avec pngwolf-zopfli produit des fichiers plus petit qu’avec seulement oxipng en mode zopfli. Une personne vient de me dire la même chose sur Phoronix. Peut-être que advpng (de advancecomp) pourrait remplacer pngwolf-zopfli si au delà de zopfli les optimisations PNG servent à rien et perdent du temps, j’utilise advzip pour recompresser les zip et j’en suis très content. Il fut un temps ou advzip avec zopfli produisait des fichiers plus gros que les zip de 7zip en mode -mx=9 mais ça devait être un bug, maintenant advzip avec zopfli peut réduire un zip plus que 7zip.

    Ah aussi, je fais les opérations dans un dossier temporaire respectant la variable d’environnement ${TEMPDIR}, variable que j’assigne à un ramdisk.

    ce commentaire est sous licence cc by 4 et précédentes