Voici donc quelques uns de mes premiers résultats…

Pour certaines photos, j’ai un peu raté le développement et le tirage, ce qui laisse de belles marques toutes laides… Chacune a été exposée différemment, de 1 à 32 minutes.

Bref, ce fut une expérience intéressante que je compte bien continuer… Je suis encore loin d’être satisfait des résultats, même si certains avantages du sténopé ressortent clairement (la profondeur infinie, le bruit inexistant, les zones de pénombres propres, des aberrations chromatiques à tout va…).

Pour ceux que ça intéresse, quelques liens (principalement axés débutants) :

• http://www.galerie-photo.com/stenope.html
• http://www.matchboxpinhole.com/
• http://www.kodak.com/[...]/pinholeCanBox.shtml
• http://stenope.artblog.fr/263115/Comment-fabriquer-un-appareil-stenope/
• http://pinhole.stanford.edu/ph.html

Edit : les curieux trouveront les négatifs et d’autres photos ici. Mis à jour à chaque nouvelle photo intéressante.

(21.04.09) Edit : mise à jour des liens.

En vidéo (h264 / 405×720) : flame.mov. Pas de fumée, je me suis concentré sur la flamme en elle-même, son comportement et son shader. Le jittering au niveau de la sphère émettrice est dût au fait que je n’ai pas voulu perdre trop de temps avec la simulation et le rendu (sacrifice visuel, comme on dit).

Prochaine étape : gestion physique et destruction massive.

Jusqu’à présent je m’étais restreint aux simulations de fluide type liquide, comme le montrent certains exemples de mon site vieillissant. Aujourd’hui, le feu et la fumée sont à l’honneur. J’ai retenu deux cas intéressants sur la dizaines de tests réalisés.

En vidéo (h264 / 1280×720) : cig_fume.mov & donut_on_fire.mov. Evidemment, comme il s’agit purement de R&D, le rendu est brut et sans aucune prétention artistique.

Le premier joue avec la densité et la vorticité du fluide pour un résultat comparable à celui d’une fumée de cigarette. Le second, quant à lui, fut plus compliqué à mettre en place : combustion, gestion de l’expansion de la chaleur, sub-scattering sur le feu et la fumée, map d’illumination produite par les fluides et intéractions avec un corps solide.

Reste à trouver une utilité concrète à tout ça.

-march=core2 -fomit-frame-pointer -O3 -pipe -Wall -m64

Quant à l’image…

J’ai cherché un moment une solution pour afficher une image haute définition sans passer par l’api Google Maps ou un serveur de traitement d’image (IIPImage aurait été parfait dans le cas contraire). Je suis tombé sur plusieurs projets plus ou moins aboutis, quelques modules flash peu pratiques, pour finalement tomber sur Seadragon de… Microsoft. Non-libre, simplement gratuit pour le moment (bien qu’ayant croisé quelques threads sur le forum du lab concernant un passage à l’une de leurs licenses open source) mais il fait son boulot et le fait bien ! Ou presque… Comme vous le verrez, c’est assez lent en plein écran.

Seadragon est la technologie de traitement d’image de masse développée chez Microsoft qui fait beaucoup parler d’elle en ce moment. On la retrouve sur Surface (leur table multi-touch) et sur l’iPhone (!) sous le nom de Seadragon Mobile, disponible gratuitement sur l’Appstore. Petite note concernant la version iPhone, elle est tout bonnement impressionnante et d’une fluidité exemplaire, à tel point que Maps semble se trainer à côté.

Une version javascript est donc disponible pour afficher ses propres images hautes-defs sur son site. Sans plus attendre et en guise d’exemple, la buddhabrot (déplacement à la souris et zoom à l’aide de la molette) :

Note pour les impatients : si l’image semble de basse qualité lors d’un zoom violent, attendez quelques secondes qu’elle se charge correctement.

Son intégration au sein d’un site est très aisée et se résume à quelques lignes de javascript que l’on trouve dans la doc. Le problème se pose lors de la génération des tiles. Microsoft fournit un outil nommé Deep Zoom Composer. Dans l’absolu, c’est de la merde. Impossible de charger correctement une image de quelques dizaines de megabytes, quelque soit le format… Une petite recherche Google a finalement abouti sur un script Python automatisant toute la procédure. Alors évidemment, pour des images de plusieurs centaines de Mpix, mieux vaut s’équiper en ram et utiliser la version 64bits de Python.

Concernant mon morceau de code, il est possible de l’optimiser de différentes façons. Par exemple, pour générer une image en noir et blanc, il suffit de se contenter d’un seul canal de couleur, ce qui, au passage, permet de diviser par trois l’usage en ram. En parlant de mémoire, générer une image de 400Mpix sera impossible avec 4Gb de ram sans swapper énormément. Pour cela, il est préférable de calculer chaque canal séparément et de les merger à la main sous Photoshop ou Gimp. Pour les geeks qui veulent s’amuser avec le code, pensez à modifier les valeurs suivantes :

const uint width = 14000, height = 14000;
const ullong iterations = 50000000;

const int red_threshold = 50;
const int green_threshold = 600;
const int blue_threshold = 5500;

Oh, et bonne année à ceux que je n’ai pas déjà vu.

(10.01.09) Edit : Pour ceux qui veulent, voilà un jpeg de la buddhabrot complète. Je conseille de faire un clique-droit/sauvegarder, l’image étant excessivement lourde.

C’est en faisant joujou avec les matrices de convolution, filtres et autres méthodes de traitement d’image que j’en suis arrivé à m’intéresser à deux choses en particulier : les attracteurs chaotiques et les fractales.

Les premiers sont des systèmes dynamiques simples à implémenter (une fois la formule connue) et donnent des résultats visuels assez intéressants. Prenons l’équation de Peter De Jong définit de la manière suivante :

Où , , et sont des constantes décimales. Le point (,) va alors se déplacer de façon chaotique au cours du temps. L’image obtenue sera en fait une carte de probabilité pour que le point se trouve dans la zone définie par chaque pixel.

Il existe une variante de Clifford Pickover :

On trouve dans la même catégorie l’attracteur de Tinkerbell :

Ou encore la Hénon map qui ne dépend que deux paramètres et qui a pour particularité de n’être purement chaotique pour les valeurs et . Ne me demandez pas de l’expliquer, cela sort de mes compétences.

Histoire d’illustrer le tout, voici quelques rendus obtenus à l’aide d’un script Python bien lent (disponible ci-dessous) :

Code source : ChaoticMaps.py

Passons maintenant à quelque chose de visuellement plus stimulant. Toute personne connaissant de prêt ou de loin le terme « fractal » pensera immédiatement à l’ensemble de Mandelbrot. Il en existe une variante nommée Buddhabrot permettant d’obtenir, comme son nom l’indique, un visuel relativement proche de certaines représentations de Buddha. L’ensemble de base de Mandelbrot est définit de la façon suivante :

Soit un nombre complexe et une fonction définie par :

Si , on peut alors définir une suite récurrente par :

L’ensemble de Mandelbrot est alors l’ensemble des tels que la suite ne tende pas vers l’infini.

Plutôt que d’expliquer en détail le fonctionnement de la Buddhabrot, je vais me contenter de citer un très bon résumé de wikipedia :

Pour obtenir le Buddhabrot, on utilise un tableau à deux dimensions, chaque case représentant un pixel. Pour des points choisis au hasard (ou, alternativement, régulièrement espacés) dans le plan, si ces points s’échappent après un certain nombre d’itérations (donc n’appartiennent pas à l’ensemble de Mandelbrot), on incrémente le tableau aux points correspondant aux valeurs successives de prises par la suite (on « suit » le parcours des points). Après un certain nombre d’itérations, l’image obtenue en affectant une couleur à chaque point du tableau se stabilise sur le Buddhabrot.

Voici le résultat de deux rendus (tolérances de couleurs différentes) effectués dans la nuit. La sortie d’origine est de 4096×4096 pixels mais a évidemment été réduite pour un affichage web. Les versions haute-définitions sont toujours en cours de calcul, je les posterai à l’occasion pour ceux qui veulent zoomer et apprécier le niveau de détail (croyez-moi, les deux petites images ci-dessous ne rendent pas honneur à la beauté de la chose).

Code source : buddhabrot.tar

Les sources contiennent une version Python et une version C. Si vous le pouvez, favorisez évidemment la version C qui est 30 à 40 fois plus rapide.