FLIF, un format d’image sans perte, intelligent et « performant », sous licence GPL

Posté par (page perso) . Édité par Davy Defaud, Benoît Sibaud, palm123, Xavier Claude et tankey. Modéré par tuiu pol. Licence CC by-sa
64
4
oct.
2015
Technologie

Pendant que les technologies en termes de compression vidéo continuent d’avancer, on attend toujours la relève en termes de compression d’images. JPEG2000, PNG et GIF sont des formats qui commencent à prendre de l’âge, et chaque format a sa cible d’utilisation. Peut‐être plus pour longtemps, un nouveau format entre dans l’arène, il est libre et répond au doux nom de FLIF.

Journal zpaq : backup incrémental avec déduplication

Posté par . Licence CC by-sa
44
2
mai
2016

Je m'intéressait aux techniques de déduplication quand je suis tombé sur cette petite perle.
http://mattmahoney.net/dc/zpaq.html

Un petit outil en ligne de commande qui n'a l'air de rien, écrit par un expert à la retraite dont c'est le passe temps entre deux courses d'ultrarunning…

La déduplication c'est quand on essaye de retrouver des bouts de fichiers communs pour éviter de les stocker à nouveau. zpaq permet de gérer la déduplication au sein de chaque fichier mais également entre les fichiers. Si (...)

Journal Découvrez la compression de données ! (et l'humour algorithmique)

34
6
août
2013

Hop, voici un journal bookmark dans lequel je présente une méthode de compression de données plutôt simple, mais utilisée par les plus grands.

L'article est ici : http://www.palkeo.com/code/compression.html

C'est le résultat de quelques jours à me poser des questions existentielles sur la compression de données (for fun and profit).
À la fin, vous avez un script de moins de 300 lignes qui arrive à faire de la compression/décompression avec un ratio qui s'approche pas mal des algos classiques, et (...)

Les nouvelles versions du noyau seront publiées en .xz

Posté par . Édité par Benoît Sibaud, ariasuni, Ontologia et Florent Zara. Modéré par Bruno Michel. Licence CC by-sa
24
31
déc.
2013
Noyau

La vieille blague de linuxfr.org IPOT prédisait que le noyau 3.2.24 ne serait plus publié au format bz2, rendant la décompression de l'archive impossible avec les moyens de 2001. Cela fait un moment que les noyaux sont publiés en tar.gz, tar.bz2 et tar.xz, on apprend maintenant que les prochaines versions du noyau seront publiées uniquement en tar.gz et tar.xz. La prochaine révision longterm 3.2.54 sera donc l'une des toutes premières affectées, la différence étant d'un seul caractère avec la prédiction d'IPOT.

Plus sérieusement, je me demande quelles options de compression seront utilisées. En effet dans le cas de la compression .xz, les besoins en mémoire augmentent considérablement pour les niveaux compressions les plus élevés (source man xz) :

(traduction) « L'utilisation de mémoire avec xz varie de quelques kilooctets à plusieurs gigaoctets, en fonction de paramètres de compressions. […] Le décompresseur aura typiquement besoin de 5% à 20% de la mémoire nécessaire au compresseur pour créer le fichier. […] Cependant, il arrive que des fichiers .xz requièrent plusieurs gigaoctets de mémoire pour être décompressés. »

(texte original) « The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. […] Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. […] Still, it is possible to have .xz files that require several gigabytes of memory to decompress. »

NdM : merci à JGO pour son journal.

Revue de presse de l'April pour la semaine 4 de l'année 2015

22
27
jan.
2015
Internet

La revue de presse de l'April est régulièrement éditée par les membres de l'association. Elle couvre l'actualité de la presse en ligne, liée au logiciel libre. Il s'agit donc d'une sélection d'articles de presse et non de prises de position de l'association de promotion et de défense du logiciel libre.

Sommaire

Journal 2 vulnérabilités découvertes dans LZ0 et LZ4

21
30
juin
2014

Les vulnérabilités découvertes pour LZ0 et pour LZ4 viennent d'un code datant de 1999.

En résumé, elles provoquent un dépassement du tas d'entier non-signé, ce qui conduit à une corruption locale de la mémoire.

Ce bogue n'est pas super pratique à utiliser, car il faut lancer la fonction incriminée avec assez de données pour dépasser la limite d'un entier non signé, ce qui dépend donc de l'architecture.

En pratique, cela signifie qu'une architecture 64 bits est plutôt à l'abri.

Le (...)

Journal Algo de compression JPEG waifu2x

Posté par . Licence CC by-sa
14
23
mai
2015

Salut les moules qui font du graphisme ou qui aiment les Anime.

Je suis tombé sur une info qui je l'espère pourra intéresser certains (d'où ce journal, parce que perso, je m'en bat le coquillart).

Disclaimer: Je ne m'y connais pas du tout dans le domaine. Mon coquillart non plus.

Il s'agit d'un algo pour compresser en JPEG, qui serait apparemment spécifiquement pensé pour mieux gérer les images issues du monde de l'Anime.

Ci-dessous l'exemple donné sur le github du (...)

Les journaux LinuxFr.org les mieux notés du mois d'août 2013

Posté par (page perso) . Édité par tankey. Modéré par Nÿco. Licence CC by-sa
12
2
sept.
2013
LinuxFr.org

LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l'équipe de modération avant publication. C'est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

Ce que l’on sait moins, c’est que LinuxFr.org vous propose également à tous de tenir vos propres articles directement publiables, sans validation a priori des modérateurs. Ceux-ci s'appellent des journaux. Voici un florilège d'une dizaine de ces journaux parmi les mieux notés par les utilisateurs… qui notent. Lumière sur ceux du mois d'août passé.

Forum général.général Recompresser un son (ou une image) venant d'une compression avec perte

0
7
fév.
2016

Bonjour,

Aujourd'hui, je viens vous demander votre avis après une recherche infructueuse sur ce sujet.

On sait qu'il vaut mieux, si on peut, ne pas compresser avec perte un flux audio (ou vidéo, d'ailleurs) qui a déjà déjà été compressé avec perte (par exemple PCM original → OGG Vorbis → MP3) : à chaque étape, on altère l'information.

Dans le cas qu'il me questionne, on est en possession d'un flux audio PCM (disons, un CD audio) dont l'origine est une (...)