 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
C'est pas que ça me gène vraiment pour utiliser APP, mais enfin... Donc, disons que c'est plutôt un programmeur qui parle à d'autres programmeurs (en prenant toute la place qu'il faut pour donner des détails.)
Je voulais comparer l'utilisation du RAW et du JPEG, j'ai donc pris une série de photos en RAW+JPEG, lu les deux series de fichiers et pour chacune d'elles cliqué sur sur le bouton Détecter. La luminosité et les couleurs des deux apperçus ne sont pas identique: pas de surprise, c'est exactement ce genre de chose que je voulais savoir. Mais en regardant de plus près ce qui s'affiche en bas à gauche de chaque apperçu j'ai constaté que "Optim RMS" et les valeurs "FOV" n'étaient pas identiques. Comme ça n'est pas la première fois que j'ai l'impression que deux panoramas qui devraient être géométriquement identiques ne le sont pas vraiment j'ai fermé APP, l'ai relançé et:
- cliqué sur le bouton Nouveau Groupe
- lu les JPEG
- cliqué cinq fois de suite sur le (gros) bouton Détecter
Voilà ci-dessous le résultat, où l'on remarque que "Optim RMS" et les valeurs "FOV" varient à chaque fois et de manière non négligeable:
Bon, si j'avais écrit le programme ça m'enuierait beaucoup!
J'utilise la beta 1.2.0 mais j'avais déjà cru remarquer la même chose avec la version "non beta".
Pour plus de sureté j'ai refait un essai en relançant APP après avoir changé
- la taille du cache mémoire
- mis la qualité de détection à "maximum"
- diminué le nb de pts de contrôle à 30
- mis l'interpolateur et le mélangeur de l'aperçu aux valeurs par défaut
- et même mis celles du rendu final à bilinéaire et linéaire
Pour cette fois j'ai utilisé le bouton "Analyser des photos" deux fois de suite, me suis armé de patience (qualité maximum ça a l'air de de remuer des bits!):
Bon, avec qualité maximum je ne suis pas surpris d'avoir un résultat différent (le panorama a quand même vraiment beaucoup rétréci !)
et la différence entre [0] et [1] est plutôt faible mais disons que pour le moment, si APP semble précis il semble pas très fidèle.
... ou alors vous utilisez les valeurs précédemment calculèes pour les même photos comme point de départ, mais dans ce cas il est choquant que "Optim RMS" (c'est quoi exactement, au fait?) ne diminue pas
Last edited by GURL (2006-03-23 20:56:42)
Offline
Interessante étude georges !
Alors, oui, c'est vrai, les résultats varient un peu entre deux lancements de détection. Voici comment fonctionne en partie APP :
Etape 1 et 2 : L'algorithme sift détecte des points de controle par image et un autre algorithme, le BBF-Tree permet de faire correspondre ces points entre eux (c'est ce qui se passe dans les 1er 50% dans la fenetre des groupes).
Etape 3 : J'utilise un algorithme de validation des paires de points renvoyées par le BBF-Tree. Cet algorithme se base sur une sélection aléatoire. Son résultat est donc totalement dépendant d'un rand(). Que permet de faire cet algorithme ? Il permet de détecter les mauvais points de controle pour un couple d'image (par exemple entre l'image 1 et 2) (mauvais au sens d'une certaine norme). Ainsi, il arrive qu'à la sortie de cet algorithme, les points de controle varient pour un couple d'image.
Etape 4 : A partir de la liste de point de controle pour un couple d'image, je fais un tri (je ne rentre pas trop dans les details, mais c'est une étape déterministe et non aléatoire).
--- A ce niveau, le panorama est completement détecté et l'optimisation spatiale peut commencer.
Bilan : Effectivement, entre chaque lancement, le résultat peut être différent, car les points de controle peuvent avoir bougé un peu. Y-a des avantages et des inconvénients :
Avantages : si un panorama a été coupé en deux au 1er lancement, il se peut que de relancer la détection, il l'assemble completement.
Désavantage : l'inverse, évidement !
Je me suis longtemps demandé si je ne devais pas fixer le rand à chaque init d'un panorama par un srand() fixe, pour ne pas avoir ce caractère aléatoire. C'est encore maintenant une question ouverte.
--- A propos de l'optimisation et de "Optim RMS" :
Ca correspond à l'étape identique dans panotools d'optimisation du panorama. Neanmoins, il est fait de façon totalement différente dans APP. Comme tout algorithme de convergence dans un espace de grande dimension nonlinéaire, c'est toujours un peu délicat très proche de la solution. Pour information, APP résoud le problème général : chaque image a une position, une focale, et une distortion propre.
La sortie de cette algorithme est le panorama avec toutes les images positionnées. Le "Optim RMS" est une norme qui mesure la qualité de cette optimisation (correspond vaguement au "average control point distance" in panotools). Mais ce n'est pas cette norme loin de là. En étant pragmatique, sous 2.5 c'est parfait, entre 2.5 et 5.0, y-a peut-etre un peu de distortion forte ou une petite erreur de paralaxe, au-dessus de 5.0, y-a surement un problème.
Voila. J'espère avoir expliqué un peu de sujet. Je vais repasser sur Autopano Pro très vite, pour exposer tous ces parametres qui pour l'instant n'était pas réglables mais le seront très vite. Ainsi, des tests plus poussés sur ce sujet là pour facilement être fait.
Offline
Alexandre wrote:
APP résoud le problème général : chaque image a une position, une focale, et une distortion propre.
Pouvoir assembler des panoramas où la focale n'est pas identique pour toutes les photos me semble très utile, pour toute une série de raisons qui vont des plus ordinaires (appareils où l'on ne peut pas bloquer la mise au point et zooms qui ont tendance à "zoomer tout seuls" quand on les incline vers le haut ou vers le bas) aux plus ambitieuses (faire varier la mise au point pour augmenter la profondeur de champ, avoir une définition plus grande de l'image à des emplacements où il y a plus de choses à voir, ciels nuageux et vagues au bord de mer.)
Par ailleurs j'ai cru remarquer que la distortion peut elle aussi dépendre de l'orientation de l'appareil (la mécanique de précision coûte très cher mais les photographes veulent des zooms "impossibles" à des prix "acceptables"...)
Pourtant (Futur -->) j'aimerai bien:
- pouvoir dire que la focale et la distorsion sont à considérer comme identiques pour toutes les photos.
- pouvoir exploiter la base de données de PTlens (ou des valeurs issues de photos prises spécialement à cette effet, je crois que la méthode utilisée par Thomas Niemann n'est pas la plus simple possible.)
Pour ce qui est d'utiliser rand() sans init: chapeau! j'y ai pensé mais me suis dit "il a quand même pas osé faire ça!". Il a osé! (l'avantage est que la comparaison des différences entre les stitchs sucessifs d'une même série d'images - différence sur FOV par exemple - peut donner des informations intéressantes sur la manière de régler les options de détection ou même la manière de prendre les photos, etc.) Ceci dit j'en connais qui attachent une très (trop) grande importance à ACPD: ça les rassure, ils seront choqués si l'incertitude est exposée à leurs yeux: le type même de l'advanced option ?
Alexandre wrote:
Avantages : si un panorama a été coupé en deux au 1er lancement, il se peut que de relancer la détection, il l'assemble completement.
Ca suggére un mode "débrouilles toi pour me faire un et un seul pano avec ces photos, t'as le droit à autant d'essais que tu veux, je viendrai voir demain si tu y est arrivé"! Au besoin (ça a déjà été suggéré) on indiquerait que cette photo doit "à tout prix" être racordée avec telle autre. Au besoin en fournissant les points de contrôle uniquement pour le raccord difficile, savoir qu'il est prioritaire devrait aider.
Offline
Notes pour le futur :
- j'ai déjà un système complet et qui marche de détection à partir des exifs du fait que toutes les images ont été prises à la même focale (à un epsilon près). Il ne resterait plus qu'à cabler cela avec la routine d'optimisation spéciale pour ce cas et le tour est joué.
- l'exploitation de la base de donnée de PTLens est impossible : les models de lens sont différent. Sur ce point, j'ai un projet pour le futur.
Sur le rand() : je le met dans l'advanced option, sans soucis. Les seules variations restantes viendront de la partie optimisation.
Sur le mode "je veux tout dans le pano", c'est l'objet de mon éditeur de point de controle qui permettra de fixer les incohérences.
Oui, j'ose :-) !
Offline
Alexandre wrote:
- l'exploitation de la base de donnée de PTLens est impossible : les models de lens sont différent. Sur ce point, j'ai un projet pour le futur
En tous les cas la technique utilisée par Thomas Niemann qui nécessite de photographier un sujet contenant des lignes droites proches des bords et à mi-distance du centre ne me convainc pas vraiment (c'est pas toujours commode de trouver un sujet approprié et de grande dimension ...il y a quelqu'un qui demandait l'autre jour où aller à Paris pour trouver un immeuble moderne adéquat ;o) Il me semble qu'en prenant deux photos avec un recouvrement de 50% d'un sujet quelquonque ayant des détails bien répartis (y compris le long des bords) les résultats devraient être au moins aussi bons (l'important étant d'avoir beaucoup de points de contrôle et de bien utiliser un recouvrement de 50% de telle manière que les points près du bord sur une photo soient au milieu sur l'autre et inversement.
J'ai vu il y a pas longtemps un objectif ou la distorsion était placée au centre et pas sur les bords (pour tromper les testeurs?).
Avec avec les objectifs "kit économique" où on voit l'image bouger dans le viseur quand on utilise la mise au point manuelle et surtout avec les très grand angle rectilinéaires, il me semble que le décentrement (involontaire) rend la correction de distorsion aléatoire puisqu'on suppose qu'elle est symétrique (la méthode ci-dessus permettrait d'en tenir compte si on fait une calibration en vertical et une autre en horizontal?)
Quand aux fisheyes : ?
Offline
Si le fichier pano ne fige pas les positions des images,
et en cas d'option pour le rand (seed ou valeur finale)
il faudrait sauvegarder sa valeur dans le fichier pano
pour pouvoir refaire la meme image plus tard (changement de taille, HDR, etc),
SimDC
Offline
Dans le fichier .pano les positions sont evidement fixes. En l'ouvrant, on trouve alors le résultat donné par le seek de l'époque sans le connaitre. Je pense de plus en plus à oter ce seed ... Meme s'il n'est pas vraiment génant, c'est difficile à faire comprendre le concept de non reproductibilité.
Offline
Pages: 1