User:Esby/hugin

Traitement d'images en mode panoramique sous linux, au moyen d'hugin.

Moyens

 * un appareil photo numérique.
 * (option) un trépied.
 * (option) une rotule panoramique.

 * de la RAM: au minimum 2go à  4 go, plus pour le confort est possible.
 En fait, tout va dépendre du nombre d'images et des résolutions que vous allez utiliser.
 Selon le nombre d'images, le temps requis va être augmenté.
 Pour un panorama à 360 en 28mm, il faut prévoir 32 images à 36° (10 *(0°) + 10*(45°) + 10*(-45°) + 1*(-90°) + 1*(90°)
 L'utilisation d'un fisheye va permettre de réduire le nombre d'image et les problèmes sur les objets mobiles. On pourra utiliser théoriquement entre 6 et 8 images.
 Par contre, la résolution possible ne sera pas la même.
 Si du bracketing est fait avec plusieurs expositions, il est préférable créer des tifs depuis les brackets et de ne travailler qu'avec ces tifs.

 * de la puissance de calcul, si possible plusieurs cores.

Notes sur la prise de vue

Avant tout autre chose plusieurs facteurs sont à considérer au niveau de la prise de vue:

• On préféra le mode d'exposition manuel: cela permettra de réduire le banding: qui est généralement visible dans le ciel présentant des bandes de couleurs différentes suite à des changements de réglage de l'appareil photo lorsqu'il est dans un mode automatique ou semi automatique (A / S / P ).
• sur la Mise Au Point: MAP manuelle pendant tout le procédé. Sur de la photo avec courte focale, cela ne gênera pas trop, mais sur de la longue focale, l'incidence pourra ne pas être négligeable voire fatale pour assembler le panorama.
• sur la balance des blancs: la fixer une bonne fois pour toute et ne pas la changer, au besoin on peut toujours procéder à partir des raws et les décoder selon le même profile.

Logiciels

 * une version récente de ubuntu, en version 64bits, si le processeur ou les processeurs le supporte

 * (option) Un logiciel pour décoder les raws, si on souhaite travailler à partir des raws. 
 ** dcraw
 ** rawtherapy 
 ** Bible (payant)
 Le but étant de décoder vers du tiff.

 Je n'utilise plus cette fonctionnalité pour l'instant: en théorie cela permet d'obtenir de meilleurs résultats, en pratique, cela va dépendre des appareils photos:
 sur un appareil récent, le raw ne sera pas corrigé par l'appareil alors que la version jpeg le sera: cela fait du travail en plus pour un résultat pas forcément meilleur en qualité. 

 * Un logiciel pour trier les images et les visualiser:
 Le but étant de trier les images par répertoire. La méthode proposée étant de mettre toutes les images concernant un même panorama dans le même répertoire.
 Sous ubuntu, l'utilisation de Nautilus pour cela peut suffire, il suffit de bien repérer ou et quand commence vos panoramas et de déplacer vos fichiers.

 Au niveau logiciels de visualisation disponibles sous ubuntu on trouve:
 *fspot
 *gqview
 *gwenview
 *gthumb
 *gimp, au sens ou il peut être pratique pour regarder en détail une image.

 * Des logiciels pour assembler le panorama: L'installation est décrite sur le wiki de panotool, voir lien plus loin.
 ** Hugin - interface graphique pour manipuler les panoramas.
 ** enblend/enfuse - outil en ligne de commande pour assember les panoramas.
 ** libpano - la librairie permettant de lier l'ensemble.
 * Des générateurs de points de contrôle: (potentiellement couvert par des brevets, selon l'endroit ou vous vous trouvez.)
 ** autopano-swift-C
 ** panomatic. 

 * Un logiciel pour retailler le panorama, faire des corrections et convertir en format final:
 ** Gimp.

 Pour le HDR:
 * Un logiciel de tonemapping si on souhaite faire du HDR sans passer par la fusion interne des expositions d'Hugin. ex: Picturenaut (Windows), Photomatrix HDR(Windows), qtpfsgui (linux et windows).
 Attention, je trouve qfpfsgui lent par rapport à Picturenaut, je ne l'ai pas testé sous Linux, mais c'est la seule alternative que je connaisse, maintenant je ne suis pas expert dans ce domaine (linux/HDR).
 Sous Windows, je conseillerai Picturenaut, en utilisant le mode logarithmique, et l'autre si le mode logarithmique foire ou donne un rendu trop exotique.
 
 Je ne fais plus de HDR à ce jour.

 Pour du rendu réaliste, on pourra aussi utiliser le mode fusion des expositions d'hugin/enfuse.
 Dans ce cas la, il ne sera pas nécessaire d'utiliser l'optimisation photométrique.

Compilation de hugin

 Hugin ayant migré sous mercurial, cette partie de la doc n'est plus forcément à jour, il vaut mieux suivre les infos sur le wiki de panotools.org

 hugin doit être compilé pour les raisons suivantes:
 **l'utilisation du trunk du svn de hugin permet d'avoir une une version de hugin à jour incluant les dernières fonctionnalités. 
 **les binaires sont compilés pour l'architecture et logiquement optimisés.

 la compilation est décrite en détail sur le wiki de panotools: http://wiki.panotools.org/Hugin_Compiling_Ubuntu

 Il est parfois nécessaire de compiler une version stable du trunk, avec l'option -r de svn.
 svn update -r <numero de revision>
 On peut se réferer ici pour les versions stables du trunk:  http://wiki.panotools.org/Development_of_Open_Source_tools#Specific_revisions

Méthodologie

Préliminaire - Extraire les images par répertoire

 Attention: Mon objectif est rectilinéaire, donc ce que je dis n'est pas forcément vrai pour du traitement avec des objectifs non rectilinéaires (ex: Objectif FishEye).

 Les étapes longues sont:
 * la création des points de contrôle,
 * la prévisualisation quand on a un grand nombre d'image. Toujours penser à sauvegarder le profil avant de travailler avec un grand nombre d'image.
 * l'assemblage qui demande de la charge CPU, de la mémoire et de l'espace disque. Une fois l'assemblage lancé, on peut fermer le GUI de hugin si nécessaire, l'interface d'assemblage (avec les batchs étant indépendante)

 On évitera d'utiliser le bouton en première page pour aligner les images. Simplement parce qu'il n'offre aucun contrôle. 

 On le réservera uniquement pour les cas triviaux on l'on sait que hugin ne va pas se vautrer.

Création des points de contrôle

 Cette étape n'est nécessaire que si on prend des photos sans rotule panoramique.
 Avec une rotule, les photos sont espacées du même écart. Il n'y pas besoin a priori de créer des points de contrôle.
 Il suffit de rentrer les intervalles à la main, si on automatise la procédure et qu'on la réalise toujours de la même manière, en prenant les prises de vues dans un sens donné, on peut alors appliqué un profile au niveau du GUI de hugin.

 On choisira de créer entre 8 et 15 points, de manière automatique.
 L'alignement manuel est possible mais plus long.
 J'ai constaté à l'usage que panomatic était mieux au niveau des resultats que autopano-sift-C, c'est évidemment un avis subjectif, il se base sur les points aberrants que va laisser parfois autopano-sift-C.
 Dans certains cas, il se peut que des images ne soient pas reliées entre elle, alors qu'elles devraient, on peut tenter d'utiliser un autre outil de création de point de contrôle, ou alors le faire à la main.

 Depuis les versions récentes de hugin, il est possible d'utiliser des outils de création de points de contrôle différents, avec des réglages spécifiques pour chaque outil. Les installeurs récents les configurent par défaut.

 On compilera et configurera (au moins) donc:
 * autopano-SIFT-C
 * panomatic
 Il existe une variante de panomatic, que je n'ai pas eu l'occasion de tester à ce jour.

Alignement des points

 On commence par l'alignement de base. (le plus simple.)
 On augmente le nombre de paramètres à chaque nouvel alignement.
 En principe , avec y p r v, les images sont en général bien alignées, on peut vérifier que ce soit le cas visuellement.
 Le paramètre v est surtout utile pour des panoramas sphériques ou cylindriques, il est surtout utile quand on sait que la valeur de v (angle de champs) entrée est aberrante.

 Si des lignes sont brisées, on peut tenter un ré-alignement après avoir ajouté suffisamment de point pour tenter de rétablir les lignes en question.
 On peut décider du meilleur rendu via le choix de la projection, suivant le cas, on pourra utiliser les diverses projections.
 En général, rectilinéaire, equi-rectangulaire, circulaire sont les seuls projections qu'on a à utiliser.
 Les autres projections correspondent soit à des usages artistiques, soit à des cas très particulier. J'aime bien Miller Cylindrical pour les intérieurs. 

 A noter qu'actuellement Hugin fait l'ajustement des points de contrôle par rapport à une projection equi-rectangulaire, donc il se peut que des lignes soient brisées hors de ce mode.
 Note: ce n'est plus forcément vrai, à vérifier.
 

Élimination d'Éléments présents en double à divers position sur une photo

 On peut facilement créer des masques au niveau d'hugin, pour éliminer les effets de fantôme ou mieux contrôler l'intégration. Il est possible aussi de ne sortir que les images remappées, et d'assembler ces dernières sous Gimp ou Photoshop.
 Il est toujours possible de cropper certaines parties d'une ou plusieurs images au niveau d'hugin, mais cela reste moins puissant que l'outil de masque maintenant intégré.

Optimisation colorimétrique

 D'une manière générale, si les images ne présentent pas de différences visibles, on ne devrait pas lancer l'optimisation colorimétrique.

 Dans le cas d'assemblage de HDR non panoramique (brackets), on doit faire attention à ne *jamais* utiliser la correction du vignettage. 
 Elle a tendance à produire des halos indésirables. 
 (windows) Dans le cas de stack simple, il est possible d'utiliser picturenaut.

 En cas de fusion des expositions, l'optimisation est ignorée, donc elle n'est pas à réaliser.
 Le nombre de points importent peu, 50 à 100 points peuvent suffire.
 Il y a des cas ou on ne parviendra pas ) obtenir une correction colorimétrique convenable.
 On peut aussi la recommencer si nécessaire, parfois on tombe sur un meilleur résultat ainsi. 
 Il est à noter la présence de des flèches d'annulation dans l'interface du GUI permettant de revenir en arrière...

 Toujours sauvegarder le profil avant une optimisation...

 Il est parfois préférable de traiter les images sous Gimp au préalable, au moyen de l'outil courbe, lorsque l'optimisation échoue ou ne donne pas de résultats satisfaisant.

Assemblage

 Avant l'assemblage, ajuster les histoires d'assiette et de centre du panorama. On peut au pire générer un panorama en miniature et vérifier que les images sont correctement assemblées.

 Toujours cropper le panorama résultant, si il y a de grandes bandes noires, cela réduit le temps de calcul.
 Note: Il y a une fonction d'autocrop dans les dernières version d'hugin.

 Pour un rendu normal, choisir assemblage du panorama.

 * Fusion des expositions. 
 Je ne conseille pas la fusion des expositions, je pense qu'il est mieux de travailler avec des tiffs issues de bracket via enfuse (j'ai un programme maison limagefuser, fait avec lazarus pour genre de truc, je mettrai le code source en ligne quand j'aurai le temps.)

 Pour un rendu de type HDR:
 * création d'un fichier EXR pouvant être utilisé avec un logiciel de tonemapping.  (1ere option troisième colonne.)
 Je n'aime pas le rendu HDR, c'est tout sauf naturel. Il y avait aussi des bugs, j'ignore si cela a été corrigé, c'était un bug lié au format d'openEXR.

Recadrage et traitement final

 On peut décider ou non d'enlever les bords noirs, dans ce cas la, on doit recaddrer le panorama, possiblement ajuster la luminosité.
 Il est possible de cropper l'image résultante avec Gimp ou un autre outil d'édition graphique.
 Le format final sera en général au format jpeg , qualité entre 90 et 100%.

Dans le cas de panorama cylindrique ou sphérique, il est possible d'apposer le modèle {{Pano360}} dans la description de l'image permettant l'ouverture d'un lien vers un outil de visualisation 3D du panorama (nécessite java).

Autres outils

• Panini.
• Freepv.
• Imagefuser. Pour merger des jpgs ou des tifs via enfuse en batch.