L'algorithme qui génère ces images est basé sur un phénomène très simple, et son origine provient d'ailleurs d'une erreur.
Alors que je voulais créer un algorithme détectant les bords d'une image, j'ai créé un algorithme effectuant la
transformation suivante :
Après quelques petits ajustements, j'obtenais ce genre d'images :
Après avoir étudié le comportement de l'algorithme et compris le phénomène responsable de tels résultats, j'ai décidé d'écrire un nouvel algorithme réalisant explicitement ce qui se passait par erreur dans l'algorithme initial.
Ce nouvel algorithme, ranimg, ne prend plus d'images en entrée, mais part à l'origine d'une image générée
aléatoirement et de petite taille.
La suite du traitement n'est qu'une suite d'itérations des mêmes opérations :
Mais qu'est ce qui est vraiment responsable de ces jolies courbes traversant les images ?
Ces lignes sont le résultat de la multiplication des couleurs modulo 256. Si l'on ne réalisait que des flous gaussiens,
on obtiendrait une grosse image brouillée sans aucun sens.
Le fait de multiplier les couleurs sur une image un peu floutée (donc présentant des petites zones de couleurs similaires
mais fades) va avoir trois effets dessus :
A partir de cet algorithme traitant des images aléatoires, on peut imaginer un algorithme appliquant systématiquement
l'algo précédent à des images relativement proches.
On observerait ainsi l'évolution fluide de zones colorées. On peut générer ces vidéos directement avec ranimg (on
observerait les courbes se déplacer et changer de forme au cours du temps). La difficulté de ce type d'approche est que
comme ranimg est chaotique, modifier même un seul pixel d'une image va totalement transformer l'image.
J'ai donc dans un premier temps choisi une autre approche.
Je génère un certain nombre d'images "pilier", sans aucun lien entre elles, et ensuite je les relie par un certain
nombre d'images intermédiaires permettant d'effectuer une transition en douceur.
Pour que la différence entre les images "pilier" et les images intermédiaires soit la moins reconnaissable possible,
je travaille sur des images provenant de ranimg mais ayant subi une étape de floutage supplémentaire.
Voici le résultat :
Donc je génère en premier lieu une image aléatoire de 80x45 pixels.
Ensuite, il faut ajouter des images une par une en modifiant quelques pixels, de telle manière que l'application
de ranimg produira des images proches.
Il faut donc chercher la bonne proportion de pixels à modifier d'une image sur l'autre afin de voir de la continuité. Sur une image de 80x45 pixels, modifier un seul pixel en lui ajoutant 1 permet de voir des images successives se ressemblant. Mais ce n'est pas suffisant pour avoir de la continuité. On descend donc dans les flottants.
Après de multiples tests s'apparentant à une recherche dichotomique, il s'est avéré que la bonne valeur pour avoir de la continuité était de 2 x 10-12.
Voici la vidéo obtenue avec 300 frames, 10 fps. Chaque frame est l'application de ranimg à une des 300 images de base. Chaque image de base est dérivée de la précédente en choisissant un pixel au hasard et en lui ajoutant 2 x 10-12.
Cette première idée ne donne pas de très bon résultats, à cause de la précision nécessaire lors des calculs.
Il n'est pas raisonnable de manipuler des nombres aussi petits que 10-12.
On va donc dans un premier temps calculer une image de base commune à toutes les frames, et ensuite
effectuer quelques itérations finales à partir de cette image qui aura été dérivée pour chaque frame.
La différence avec la méthode précédente est qu'ici, on dérive une image un peu travaillée, ce qui nous permet
d'avoir ensuite moins d'itérations à faire, et donc d'avoir un processus moins chaotique.
Après quelques petits ajustements, voici deux vidéos obtenues grâce à l'algorithme :
• 30 secondes, 320x180, 16 fps
• 15 secondes, 640x360, 16 fps
Ceci est une idée, elle n'a pas été implémentée.
Ce qu'on pourrait faire afin d'obtenir une vidéo à partir d'un algorithme qui donne des images, c'est demander à l'algorithme de nous générer des images en 3 dimensions (donc il faudrait faires des flous gaussiens en 3D, et adapter le reste des opérations), mais dans l'idée c'est parfaitement réalisable.
Ensuite, on prélève une des trois dimensions, et on dit que c'est la dimension du temps.
Cette idée permet de voir le processus de création de la vidéo exactement comme le processus de création d'image.
Le résultat pourrait être un peu différent de ce que l'on fait ici, mais serait probablement aussi, voire plus
intéressant.
Ici, on vient d'établir un lien entre l'ajout d'une dimension dans le calcul des images et le fait de calculer
successivement l'algorithme de base sur des images dérivées petit à petit.
On peut donc à l'inverse réfléchir à calculer nos images en deux dimensions à l'aide de ce principe.
On part d'une image en 1 dimension (une ligne de pixels), et on applique à cette ligne de pixels les procédés que
l'on applique aux images ici pour obtenir nos vidéos.
On calculerait ligne par ligne les lignes de l'image à partir de la première, et ça nous donnerait une image
complète.
Si l'analogie entre la création de la vidéo comme c'est réalisé ici et l'ajout de dimension se révèle pertinente,
alors il sera également possible de calculer des images ligne par ligne au lieu de le faire de manière globale
comme ce qu'on fait depuis le début ici.
Pour une image finale donnée, il est impossible de deviner la valeur initiale de chaque pixel. En effet, cet
algorithme extrait des couleurs globales à partir d'un amas aléatoire de pixels, donc chaque pixel final
dépend de tous les autres pixels de l'image. En revanche, la valeur de chaque
pixel entre fortement en compte dans le calcul de l'image finale.
Des tests ont démontré que changer la valeur de ne serait-ce que 0.03% des pixels avait pour
effet de modifier totalement l'image finale.
Cet algorithme a donc également des propriétés chaotiques.
Toutes ces propriétés sont intéressantes pour une fonction de hachage cryptographique.
Mais on pourrait exploiter le fait que cet algorithme travaille sur des images pour en faire une fonction
de hachage d'un nouveau genre.
En effet, quand on télécharge un fichier sur Internet et qu'on veut comparer les hash, il faut comparer une suite
de 50 caractères alpha-numériques, et il serait plus facile de n'avoir qu'à comparer des images, représentant
l'empreinte de ces fichiers ; c'est plus visuel.
Pour hacher un fichier, on le transformerait en image (on trouve la forme rectangulaire qui fait ajouter le moins
de pixels, et on complète par périodicité).
On applique ensuite ranimg à cette image, et ça nous donne une image avec des formes simples faciles à retenir.
Ceci est une simple idée, probablement mauvaise, illustrant les propriétés intéressantes que peut avoir cet algorithme.
