Cerise sur le gâteau, nous déclinerons le projet en une version « visite virtuelle » gigapixels sur Internet, avec possibilité de zoomer et de commuter d’une saison à l’autre. Ces visites virtuelles seront réalisées grâce à l’application KRPano, qui les génère en HTML5 et en Flash.

On évolue en maintenant la souris enfoncée tout en la déplaçant, ou encore au moyen des touches du clavier (flèches haut/bas/droite/gauche), ou encore en cliquant sur celles qui s’affichent à l’écran. Accès plein écran conseillé… via le pictogramme en bas à droite — celui juste à gauche du copyright. Compatible smartphones/tablettes. Fonctionne également avec un casque de réalité virtuelle.

Les pastilles orange servent à zoomer sur des points précis : Ouchy, passage piétons, le Flon, télésiège sur les sommets juste en face, etc.

Un menu en haut à gauche permet de changer de saison.

Généralement, une visite virtuelle est de type sphérique. On peut ainsi se déplacer tout autour de soi : en haut, en bas, devant, derrière, à droite, à gauche. Autrement dit dans un univers à 360 x 180 degrés. Pour ce faire, on prend des photos de toute la sphère, on les charge dans PTGui et on génère un fichier dit « équirectangulaire » — projection géométrique aplatie de notre sphère. C’est à partir de ce fichier que l’on créé la visite virtuelle à l’aide d’un logiciel type KRPano ou assimilé.

La technique utilisée pour pouvoir naviguer au sein d’une visite virtuelle gigapixels fait appel à un système de tuile. En effet, même si les connexions Internet sont de plus en plus rapide, charger l’intégralité des panoramas, soit 4,8 Go de données — 1,2 Go par saison —, demanderait trop de temps. Sans parler des ressources Ram et CPU requises.

Pour éviter cela, le panorama sera généré à différents niveaux de zoom : huit dans notre cas.

  • Au premier niveau, il sera constitué d’une seule image.
  • Puis au deuxième niveau suivant, mettons de quatre images (de même taille et donc d’une définition quatre fois supérieure). Seule celle sur laquelle l’utilisateur « zoome » se chargera. S’il de déplace ensuite pour « sortir » de cette image, celle qui correspond à la nouvelle position se chargera à son tour.
  • Puis au troisième niveau, mettons de soixante-quatre images (de même taille et donc d’une définition seize fois supérieure aux images de second niveau). Même principe que précédemment.
  • Et ainsi de suite, jusqu’au zoom le plus élevé.

À cela s’ajoute un système prédictif qui, en fonction des déplacements de l’utilisateur au sein du panorama, va pré-charger les images qui ont le plus de chance d’être « demandées ».

À noter que la version HTML5 de la visite virtuelle, que nous souhaitons utiliser — Flash est en perte de vitesse, sans compter qu’il ne fonctionne plus sous iOS —, ne permet pas de générer un panorama partiel comme le nôtre (environ 160 x 60 degrés). Mais uniquement un panorama sphérique, à partir d’une projection équirectangulaire (ou cubique), comme expliqué à l’instant. C’est ainsi que nous avons donc du générer notre panorama… Il ne comporte donc qu’une petite zone utile — environ un quart de l’image de l’image équirectangulaire, grosso modo en son centre.

Dernière problématique et non des moindres : faire en sorte que notre travail ne puisse pas nous être « volé ». En effet, si cela requiert des compétences assez pointues, il n’est pas impossible de récupérer l’ensemble des images du niveau de zoom le plus élevé — environ 170 000 par saison dans notre cas —, et d’à partir de là reconstituer le panorama.

Face à l’impossibilité d’empêcher la récupération d’images sur Internet, nous nous orientons vers une solution côté serveur : mettre en place une mécanique qui limite l’accès à un nombre d’images par session/IP. Mettons mille. Amplement suffisant pour parcourir le panorama. Largement insuffisant pour récupérer l’ensemble des images au niveau de zoom le plus fin.