La nouvelle fonctionnalité de la version 1.1 est l'ajout d'un lecteur d'image compressé par fractale au sein de l'application qui est compatible avec ImageIO.

Par conséquent, vous pouvez lire une image compressée (.dfc) avec l'application comme suit:

BufferedImage image = ImageIO.read("image.dfc");

En comparant l'image au format.jpg et au format.dfc de l'application, vous pouvez voir que la qualité est un peu pire que dans.jpg et qu'il prend un fichier légèrement plus grand (comme prévu).

Mais le résultat n'est pas mauvais du tout.

Cependant, compte tenu du temps de traitement long nécessaire à la compression, ce type de compression et sa mise en oeuvre dans l'application n'ont qu'un intérêt académique.

04/05/2026 – 04/12/2026 . Après avoir récupéré l'évolution de cette application, je propose de faire des tests avec des images réelles, et je l'essaie avec un des pixels "4000 x 3000".

Je rencontre de nombreux problèmes :

• Le processus prend une éternité dans les itérations fractionnées (en raison des triangulations étendues de jusqu'à 400 000 triangles, et que la vérification de condition fractionnée a été répétée pour tous les triangles de chaque itération)
• La mémoire s'épuise après avoir atteint la limite de 23 Go que j'avais sur mon système. Parce que:
  • Le résultat des itérations fractionnées et fusionnées a été stocké dans une liste booléenne (environ 16 itérations x 2 types de triangulation x 3 canaux x 400 000 éléments!!!). Cela fait un total d'environ 40 000 000 éléments, ce qui est toujours acceptable)
  • De plus, la sélection du livre des triangles les plus représentatifs (fixé à 256) a été effectuée avec un K-médoïde (plus de 400 000 éléments) (je pense que la mémoire utilisée par cet algorithme est O(n2).
  • Et, pour plus d'INRI, ces calculs ont été effectués en parallèle pour les trois canaux (rgb)!!
• Une fois ces problèmes résolus, je parviens à compresser l'image (4000 x 3000), mais je vois qu'il faut entre 6 et 8 heures pour terminer le travail.

Et je propose de les résoudre :

• Pour l'éternité des splits. Solution :
  • J'augmente la taille minimale des triangles à diviser, d'une manière proportionnelle au nombre de pixels dans l'image. Il en résulte une réduction du nombre de triangles dans les triangulations. Dans l'image utilisée de (4000 x 3000) le nombre de triangles est divisé par plus de 4 (nous sommes passés d'environ 400 000 triangles à environ 100 000 triangles).
  • En outre, je crée un ensemble avec les triangles qui ne répondent pas au critère de division (par rapport à la variance des valeurs de leurs pixels), afin de ne pas les répéter à chaque itération. Maintenant, volez!!
• Le système est à court de mémoire. Solution :
  • Résultat des scissions et fusions enregistrées dans les listes booléennes. Solution :
    • Au fur et à mesure que les itérations fractionnées progressent, le nombre de triangles qui se divisent est radicalement plus petit, la mémoire utilisée est sauvegardée en stockant les indices des triangles qui se divisent dans un ensemble.
  • Mémoire des K-médoïdes (probablement O(n2)). Solution:
    • Comme nous avons divisé le nombre de triangles par 4..., la mémoire nécessaire pour cet algorithme, cette réduction des triangles implique de diviser la mémoire utilisée par un facteur d'environ 16.
    • Trois K-médoïdes en parallèle (un pour chaque canal). Solution :
      • Nous séquençons les calculs des triangulations et la sélection des triangles les plus représentatifs pour le code-livre (avec K-medoids).
    • Nous avons divisé la mémoire nécessaire pour les K-Medoids de 48!!
• Le temps de traitement avec des images "réelles" prend une éternité (la compression de l'exemple d'image prend entre 6 et 8 heures) avec 3 threads, un pour chaque canal.
  • Rendre le nombre de threads configurable (en le configurant à 23 threads (mon système a 24 cœurs), le temps de traitement est réduit à trois heures et demie).
• Effets de la solution :
  • L'effet de diviser le nombre de triangles par 4 entraîne évidemment une perte notable de la qualité de l'image compressée. Mais avec tant de résolution, ce n'est pas si important.
  • En divisant le nombre de triangles par 4, il provoque également la taille du fichier compressé à diviser, soi-disant aussi de l'ordre de 4.

Je vise également à essayer de minimiser la taille du fichier compressé, en réorganisant les informations à stocker.

L'idée est d'indiquer avant tout dans le codage des listes d'index des triangles qui se sont scindés dans chacune des itérations, dont le codage trivial original était d'utiliser un bit par triangle, indiquant s'il s'est scindé ou non.

Je conçois un algorithme pour essayer de minimiser la taille nécessaire pour stocker chacun de ces ensembles d'index.

Je pense que ce n'est pas gaspillé... si vous êtes curieux Sur ce site, je dis les points clés sur lesquels je me suis appuyé.

Bien qu'il aurait peut-être été plus intéressant de chercher un compresseur sans perte général comme zip ou 7z et de l'appliquer à la globalité du fichier compressé... Peut-être pour la prochaine fois.

Dans la dernière version de la livraison, une application d'interface de commande est incluse, qui traduit une archive créée avec des versions moins optimisées du codeur, vers la dernière version du codeur, qui prend probablement moins de place.

En utilisant cette petite nouvelle application sur une paire de fichiers avec l'encodage d'origine (un de 143x143 et un autre de 4000x3000), c'est que la taille du fichier compressé est réduite d'environ 4% en eux.