Une fois les 1 200 fichiers RAW « développés » et exporté en TIFF 16 bits, il faut encore les assembler pour réaliser les panoramas — autrement dit les « stitcher ». Trois logiciels sont spécialisés dans cette tâche bien spécifique : PTGui, que nous utiliserons, Kolor Autopano, et Hugin.

Rien de particulier là non plus en matière de traitements, excepté l’application de masques pour qu’un élément en mouvement et à cheval sur deux photos — piéton, véhicule, bateau… — ne se retrouve pas « coupé ». Compte tenu de la largeur du panorama, Arnaud conseille une projection cylindrique, plus naturelle.

Mais le plus dur reste à venir : aligner les six panoramas… idéalement au pixel près. En effet, la phase finale du travail va consister à mélanger les saisons. Non pas à les juxtaposer, à raison d’une bande verticale d’un quart de largeur pour chacune d’elles, mais à prendre un ou plusieurs « bouts » d’automne par-ici (notamment au niveau des arbres), un ou plusieurs « bouts » d’hiver par-là (notamment au niveau des sommets), etc. Autrement dit à réaliser un véritable travail de composition. Pour que ces « bouts » raccordent, nos panoramas, tout du moins dans ces zones de raccordement, doivent être parfaitement alignés. D’autant qu’a priori, ces raccords s’effectueront en fondu-enchainé en appliquant un dégradé au masque de fusion. La moindre erreur d’alignement engendrera donc des flous.

Comment aligne-t-on des images ? Deux possibilités : passer par un logiciel d’assemblage (comme PTGui, Autonano ou Hugin, donc) ou de retouche (comme Photoshop, Gimp…).

De prime abord, le logiciel d’assemblage — « stitching » — parait plus approprié. Plutôt que d’assembler plusieurs photos pour réaliser un panorama, on assemblera deux panoramas — partiels donc, d’environ 150 x 45 degrés. Quelque part, c’est le même travail que pour un 360 : faire coïncider des images à partir de points de contrôles placés au niveau des zones où elles se superposent (toute l’image dans le cas présent). Mais après plusieurs heures passées à tenter d’aligner deux images panoramiques à l’aide de PTGui et d’Hugin, après avoir essayé toutes les combinaisons de réglages possibles et inimaginables, force est de constater que cela ne fonctionne pas.

S’ensuivent divers échanges sur le sujet avec Arnaud pour parvenir à la conclusion, ce qu’un développeur du logiciel concurrent, Autopano lui confirmera, que ces applications de « stitching » ont pour but de réaliser des panoramas à partir de photos. De fait, leurs algorithmes sont conçus pour les analyser, corriger les déformation des objectifs, l’orientation, dans une certaine mesure des décalages de points de vue à la prise, etc. Autrement pour les assembler ces photos et en faire des panoramas. Pas pour aligner des images comme les nôtres, déjà « stitchées » et donc déformées de façon imprévisible par cette opération de « stich », là où les déformations de photos prises avec un appareil dépendent de l’objectif et peuvent ainsi être modélisées pour être corrigées mathématiquement. Méthode suivante…

Photoshop et GIMP proposent tous deux des fonctions d’alignement automatique des calques, qui fonctionnent plutôt bien. Les chances de succès de l’opération seront d’autant plus grandes que les panoramas à aligner seront géométriquement proches. Au niveau de leur échelle mais aussi de leur verticalité/horizontalité. Ainsi, lors de l’assemblage dans PTGui, on s’efforcera de placer les points de contrôle verticaux aux mêmes endroits sur tous les panoramas.
D’en placer assez peu : entre trois et cinq, par ailleurs répartis de façon aussi équidistante que possible afin de couvrir toute l’image. En effet, contrairement à ce qu’on pourrait supposer, placer plus de points ne permet d’obtenir un meilleur résultat… au contraire. Tout comme en matière de « stitching », trop de points compliquent la tâche des algorithmes qui finissent souvent par s’y perdre. Revenons sur la notion d’échelle, qui mérite que l’on s’y attarde…

Primo, nos six panoramas ne sont pas tout à fait cadrés de la même façon. En effet, on indique donc à la tête motorisée un point de départ, en haut à gauche, puis un point d’arrivée, en bas à droite. Pour ce faire, on la déplace au moyen de curseurs et l’on effectue un positionnement grossier, « à vue », via l’écran de l’appareil photo placé en mode « live view ». Conséquence : d’un panorama à l’autre, la position de ces points diffèrent forcément quelque peu.

Secundo, pour cette même raison, ils ne font pas tous la même taille. Si la plupart comportent 198 photos (22 rangées x 9 colonnes), d’autres n’en comptent que 189 (21 rangées x 9 colonnes). Une différence due au fait que nous ayons indiqué un point de départ un peu moins haut/un peu moins à gauche et/ou un point d’arrivé un peu moins bas/un peu moins à droite. Ces panoramas sont donc plus étroits. Mais cela n’a pas grande importance car ce qui compte avant tout, pour que les fonctions d’alignement automatique des calques donnent le meilleur d’elles-mêmes, c’est que les panoramas soient à la même échelle — exactement comme pour une carte routière. Autrement dit qu’un nombre « x » de pixels représente toujours une distance de « y » mètres.

Prenons les deux photos jointes. La première est plus large/plus haute que la seconde, par ailleurs légèrement décentrée (il en manque un bout à droite). Mais la distance en pixels, entre deux points la ligne rouge sur les images ci-contre —, ne change pas. C’est exactement ce que nous voulons.

ville1
ville2

Dans notre cas, les photos ayant été réalisés avec un même objectif, à focale fixe, et les panoramas assemblés à 100% (c’est-à-dire sans réduire ni agrandir ces photos), l’échelle est quasiment identique pour chacun d’eux. Quasiment… mais pas tout à fait ! Ceci pour diverses raisons. Notamment du fait que les points de contrôle n’aient pas été placés aux mêmes endroits d’un panorama à l’autre. Ou encore, toujours d’un panorama à l’autre, en raison de petites variations de mise au point — effectuée automatiquement avant la prise de vue en pointant l’appareil vers les immeubles les plus proches, puis « bloquée » afin qu’elle soit identique pour toute la série de photos. Au final, tout cela induit de légères différences d’assemblage.

À ce stade de nos réflexions, nous consultons un autre spécialiste et non des moindres, Erik Krause. C’est l’un des rares « photographes panoramistes » à posséder de solides connaissances « mathématiques » et à maitriser les fonctions de corrections de distorsion optiques des algorithmes d’assemblage. Lorsque nous lui avons exposé la problématique, il a rétorqué : « Well, that really sounds like a challenge… ». Sans rentrer trop loin dans la technique, voici les pistes qu’il nous a proposées :

  1. Assembler un premier panorama dans PTGui. Noter les valeurs des paramètres de correction des distorsions de l’objectif calculés par l’application — les paramètres a, b et c, qui correspondent respectivement aux corrections en barillet, en coussinet et en moustache —, puis les utiliser pour assembler les autres panoramas (les saisir « en dur » et demander à PTGui qu’il utilise ces valeurs plutôt que de les calculer à nouveau). Pour les plus curieux : https://wiki.panotools.org/Lens_correction_model.
  2. Charger dans PTGui les photos des six panoramas, à condition que ces photos, pour chacun de ces panoramas, partagent les mêmes valeurs d’exposition — de vitesse/d’ouverture — et que ces valeurs diffèrent d’un panorama à l’autre. Nous pourrons dés lors utiliser le mode HDR, qui classe les photos en fonction de leur exposition. Si cette condition n’est pas remplie, il reste la possibilité de modifier en conséquence leurs données EXIF à l’aide d’un logiciel de traitement par lot ou en écrivant un petit script « shell ». Après quoi, une fois les photos des six panoramas alignées au sein d’un même projet, on le dupliquera cinq fois pour ne conserver dans chacun de ces projets que les photos d’un seul panorama — d’une seule « couche » HDR si je suis dire — et ainsi pouvoir procéder à des rendus individuels.
  3. Une fois les panoramas « stichés », les charger dans PTGui pour mélanger les saisons au moyen des masques et utiliser l’un des algorithmes de « blending » proposé (celui de PTGui, Enblend ou Smartblend). Ou encore les charger dans Photoshop et exploiter la fonction « Auto Blend Layers » après avoir configuré des masques de fusion de façon à conserver une zone de chevauchement au niveau des transitions. Cette fonction « re-dessinera » les masques de sorte que leur « frontière » passe par des zones où les images raccordent le mieux.

Il serait fastidieux de narrer par le menu tous les tests effectués et autres expérimentations. Au final, voici la méthode qui s’est révélée la plus efficace :

  1. Assembler les panoramas dans PTGui en réglant le rendu sur 100% (même échelle).
  2. Les charger dans Photoshop sous forme de calques et les travailler deux à deux pour commencer par aligner grossièrement, en le déplaçant, le calque supérieur, dont on aura réglé l’opacité aux alentours de 50%, sur la calque inférieur (toujours le même panorama « référence » — celui bénéficiant du cadrage le plus large).
  3. Tenter d’affiner le résultat à l’aide de la fonction d’alignement automatique des calques (ne donne pas toujours de bons résultats).
  4. Affiner la mise à l’échelle en étirant le panorama supérieur, en hauteur et/ou en largeur, via l’outil « Transformation manuelle » pour éventuellement l’affiner encore via l’outil « Déformation » (malheureusement limité à neuf zones, ce dont se plaignent depuis des années de nombreux utilisateurs de Photoshop, frustrés de ne pouvoir augmenter le « pas de la grille »).
  5. Après avoir, comme mentionné précédemment, configuré des masques de fusion de façon à conserver une zone de chevauchement au niveau des transitions, utiliser l’outil « Auto Blend Layers ».

Si cette démarche demeure empirique, en l’absence de logiciel conçu pour aligner deux panoramas, nous n’avons pas d’alternative. Mais au final, grâce à la persévérance de Mathilde, l’objectif est atteint : les panoramas sont alignés au pixel près au niveau des zones de transition et cela s’avère donc suffisant pour la version imprimée. En théorie, nous aurions pu les aligner parfaitement sur toute leur « surface ». En pratique, cela aurait nécessité un temps de travail considérable… pour n’être utile qu’à la version interactive.

Or, elle peut parfaitement supporter cette imprécision : quelques pixels d’écart au passage d’une saison à l’autre, qui s’opère de surcroît en fondu-enchaîné, ne sera pas perceptible. Par ailleurs et après trois mois de post-production, il nous a semblé raisonnable d’arrêter là les frais !