CONVERSION D'UNE IMAGE À UN CODE PICWIN
cs_ReMi34
Messages postés
1025
Date d'inscription
vendredi 29 août 2003
Statut
Membre
Dernière intervention
28 mars 2005
-
30 juil. 2004 à 12:43
cs_SornDrixer Messages postés 2084 Date d'inscription jeudi 12 décembre 2002 Statut Membre Dernière intervention 30 janvier 2011 - 27 mai 2005 à 22:40
cs_SornDrixer Messages postés 2084 Date d'inscription jeudi 12 décembre 2002 Statut Membre Dernière intervention 30 janvier 2011 - 27 mai 2005 à 22:40
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/25026-conversion-d-une-image-a-un-code-picwin
https://codes-sources.commentcamarche.net/source/25026-conversion-d-une-image-a-un-code-picwin
27 mai 2005 à 22:40
Le file handling permet d'écrire directement le fichier, tandis que la hashtable, il faut d'abord la créer, ajouter les items, puis seulement une fois celle-ci terminée, "l'exporter" (pour avoir notre fichier.txt contenant le "code source" de l'image pixel par pixel)
27 mai 2005 à 21:41
(dsl du double post)
27 mai 2005 à 21:39
Pas mal malgré tout !
24 août 2004 à 19:46
2 août 2004 à 09:36
- il faut bien afficher l'image de base quelque part si on veut lui faire des $getdot pour en extraire sa couleur pixel par pixel, et je n'ai pas trouvé d'autre solution que /drawpic.
- Lors de la 1ère version de mon code, j'utilisais le file handling, que j'ai peu à peu remplacé par le buffer @window pour l'alias drawimg. (gain de vitesse intéréssant)
- fichier.txt ne supporte pas les espaces, je le sais, et je n'ai jamais voulu le faire autrement. C'est juste un petit snippet, pas un addon tout fait.
- le fichier txt ne contient aucune commande /drawdot pour diminuer un petit peu sa taille, et je vois mal quelqu'un inclure une image générée par des drawdot dans son script, une vraie image est plus pratique.
Pour une prochaine update si il y a, j'essayerai de tenir compte de se que tu as dis.
1 août 2004 à 17:29
Totalement inutile !
L'idée est bonne mais la conception est vraiment grossière:
-Tu utilises /drawpic
- /remove, $exists(), $read(), buffer @window alors que tu peux utiliser $fopen() (car version 6.12+ exigée)
-"fichier.txt" ne supporte pas les espaces
-Que du /drawdot, aucun /drawtext, /drawrect, etc.
-Le fichier txt sortie ne contient aucune commande /drawdot (donc on ne peux pas l'inclure dans un script)
-Comme il ne contient aucune commande /drawdot, on peut se dire qu'il est peut-être compressé mais il n'en est rien.
Bref si tu veux rendre ton code correct, penses à $bvar, /draw*, $compress, /fopen car pour l'heure il n'a vraiment rien qui mérite qu'on y prenne attention.
3/10.
1 août 2004 à 09:38
31 juil. 2004 à 23:03
30 juil. 2004 à 20:49
Niveau utilité, je l'ai précisé, il est nul. C'est juste une façon de voir jusqu'où mIRC peut aller. (par rapport à son cpu)
Niveau scripting, oui c'est basique, c'est un code sans prétention, mais qui est original.
30 juil. 2004 à 19:17
Niveau scripting mouais, Ia rien de tres compliqué ca reste de l'utilisation absique du $getdot et du drawdot
30 juil. 2004 à 17:42
30 juil. 2004 à 14:27
Je soumets différent point X Y à un drawdot. (
Un drawdot = une couleur précise.
Mais le problème, il aurait fallut que je 'scan' toute l'image pour chaque couleur, ca risquerait de prendre encore + de temps, enfin je dis ca, mais je n'ai pas testé. Je verrai ca ce soir :)
Ton idée de drawline n'est pas mal, mais je préfère tout faire avec drawdot dans ce code.
Qui sait, peut-être un jour j'inventerai mon propre format d'image :P
30 juil. 2004 à 14:15
Et si ton avec ton code on faisait un format de compression ? je m'explique
quand tu scanne point par point, verifie si le pixel d'apres est de la meme couleur que le précédent. Si c'est le cas au lieu de faire deux drawdot tu ferais juste un drawline.
Mais on pourrait encore augmenter la puissance du code et ctte foi, le code attend de trouver une couleur différente pour tracer une droite complete.
De cette façon on transformerait une image en une suite de fonctions et si l'image est assez simple je me demande si le format codé, serait pas plus léger que l'image de départ.
pour des dévéloppement futur, on pourrait meme envisager de replacer alors, certain drawline successif de la meme couleur par des drawrect -f
affaire a suivre ...
30 juil. 2004 à 13:52
30 juil. 2004 à 13:39
30 juil. 2004 à 12:43