plant

plante avec une règle de forte croissance verticale.

Les premiers essais de dessins complet on fonctionné, à basse résolution (4 = grandes tiges, grandes feuilles). Lorsque nous avons voulu passer à la résolution finale (0.25) soit un facteur 16, ça a mangé toute la mémoire vive pour finir par planter. Zut.

Pour résoudre ce problème d’accroissement de la mémoire (chaque nouvelle tige ou feuille est stockée en mémoire), il a fallu faire preuve de créativité: purger chaque tige dès qu’elle a terminé sa croissance. Les premiers essais n’étaient pas très concluants (j’avais de la peine à détecter la fin de croissance). Ça m’a donné de jolis dessins japonisants avec des feuilles sans tiges. Ensuite ça a été le bonheur: utilisation mémoire en , ou presque.

Ensuite, après 8h de calcul (croissance de la ram jusqu’à 1.2Go pour les points d’impact et les tiges en cours de croissance), on a obtenu un fichier svg de 474Mo. C’est gigantesque. Impossible de l’ouvrir dans Adobe Illustrator (il commence le chargement, bouffe toute la mémoire et plante). Si cette dernière application était écrite en 64bits, ça aurait peut-être fonctionné, mais là, non.

Bon on a un gros fichier avec plein de description de courbes et on ne peut… rien en faire. On essaye de faire la conversion avec la commande “convert” d’ImageMagick. Pareil: la mémoire augmente et .. boum.

Que faire ?

simple

Test de rendu pour vérifier l’algorithme de purge.

Diviser pour régner: j’ai écrit un script qui analyse chaque courbe svg et la range dans une ou plusieurs des 16 bandes verticales en fonction des bandes qu’elle traverse. J’en profite pour modifier la résolution (2.5dpi c’est pas top) en multipliant les coordonnées. Avec beaucoup de stress pour ne pas se planter dans ce traitement, on obtient 16 fichiers de 31Mo.

La conversion de ces fichiers en png se fait sans problème. Ne reste plus qu’à les assembler dans Adobe Photoshop. Bang ! c’est super lent (500Mo par fichier ouvert) et… impossible pour la totalité.

Recalcul du filtre pour générer directement les fichiers pour l’imprimeur (j’espère ne pas avoir fait d’erreur dans les calculs de distance). Ça fonctionne enfin.

Tout ça sans mentionner les essais de redimensionement avec des commandes “transform” de svg, les attentes pour l’ouverture des fichiers ou l’exécution d’une commande (min. 10 minutes chaque fois). Dur dur.

moralité

Les langages de script, même si ils sont lents nous permettent plus de souplesse que les gros programmes de traitement d’image lorsqu’il s’agit de créer des images hors normes.

[màj 14h] Les fichiers png ne peuvent pas être ouverts chez l’imprimeur. Conversion en jpg depuis le svg. Essais à différents taux de compression. 85% = 14Mo, moche. 90% = mieux. 100% = super, 88Mo. 95% = bien, 40Mo. Envoi par internet (heureusement que je viens de changer la ligne adsl pour du 13000kbps effectif).

Les fichiers sont convertis en parallèle sur mon MacBook Pro (2×2.5Ghz) et sur le G5 (2×2.3Ghz). Le portable met 2 minutes pour traiter un fichier, le G5 en met 10 ! C’est délirant comme écart.