Liens à  l'intérieur des stacks contre liens entre les stacks  

Une bonne idée? envie de demander un nouvel outil ? Les utilisateurs ont une réelle influence sur l'évolution d'Autopano et c'est ici qu'on en discute !
no avatar
GURL
Member
 
Posts: 2946
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble

Liens à  l'intérieur des stacks contre liens entre les stacks

by GURL » Tue Jan 25, 2011 5:57 pm

Ce que je raconte ici repose sur un ou deux essais alors qu'il en faudrait plus (par exemple faire des essais avec des panos plats alors que je n'ai remarqué le problème que pour des panos sphériques.)

Quand on utilise:
- des tas (stacks) parce qu'on a fait du bracketing
- l'option "For a stack detect control points" (parce que l'alignement dans les stacks n'est pas impeccable)
- l'option "Detect links in one stack level" (pour éviter les centaines de liens souvent foireux qui en cas de bracketing peuvent être créés près du zénith et du nadir d'un pano sphérique à  cause du recouvrement inévitable de nombreuses photos dans ces deux régions)
...il se produit un déséquilibre entre le grand nombre de liens qui lient les layers (ou "couches") correspondant à  chaque niveau de bracketing (on peut les appeler "liens de bracketing") et le petit nombre de liens qui lient les stacks entre eux (on peut les appeler "liens normaux")

Par exemple avec 9 niveaux de bracketing on aura des dizaines de liens (des milliers de CP) pour relier les niveaux de bracketing entre eux dans un seul des stacks contre deux pauvres liens (100 CP) reliant un stack à  ses voisins.

Une solution (manuelle) est alors d'effacer la plupart des liens de bracketing en ne gardant par exemple que le lien qui relie une photo à  celle un peu moins exposée et à  celle un peu plus exposée. Ca semble marcher plutôt bien mais c'est très fastidieux.

Je propose de remplacer l'option "For a stack detect control points" par l'option "For a stack detect control points between next and previous exposure level ONLY"

Au lieu du fouillis actuel dans le sens vertical ça permettrait de respecter vraiment le shéma:

Code: Select all
[ ]  [ ]  [ ]  [ ]  [ ]
 |    |    |    |    |   
 |    |    |    |    |   
[ ]  [ ]  [ ]  [ ]  [ ]
 |    |    |    |    |   
 |    |    |    |    |   
[ ]--[ ]--[ ]--[ ]--[ ]
 |    |    |    |    |   
 |    |    |    |    |   
[ ]  [ ]  [ ]  [ ]  [ ]
 |    |    |    |    |   
 |    |    |    |    |   
[ ]  [ ]  [ ]  [ ]  [ ]

Une autre solution serait bien sur de pouvoir optimiser indépendamment les photos à  l'intérieur de chaque pile et la position des piles entre elle mais j'ai peur que ça soit plus difficile à  implémenter, plus difficile à  expliquer et plus difficile à  utiliser...

On peut aussi imaginer de commencer avec "For a stack detect control points" puis de passer ensuite à  "For a stack use hard links" pour ne plus optimiser que les liens qui relient les stacks: c'est peut-être déjà  possible ?
Georges

User avatar
AlexandreJ
Kolor Team
 
Posts: 5911
Joined: Mon Nov 14, 2005 4:56 pm
Location: Francin, France

by AlexandreJ » Wed Jan 26, 2011 9:10 am

J'ai compris l'idée. C'était en fait mon intension de faire comme tu décris mais j'ai utilisé une autre façon de le coder qui donnait gratuitement tous les liens internes au sein d'une stack ( et pas que ceux entre voisins d'exposition ).

Ah oui, je me rappelle pourquoi j'ai procédé ainsi. Si on admet qu'il faut des liens que pour voisins d'expo, il nous faut la notion d'ordre dans une pile ( pour connaitre les voisins ). Cet ordre peut être classiquement donné par les expo si on les as, mais dans la création manuelle de pile, il faudra alors aussi coder un système qui permet d'ordonner manuellement ( genre par drag'n'drop, etc ).

no avatar
GURL
Member
 
Posts: 2946
Joined: Tue Dec 06, 2005 1:57 pm
Location: Grenoble

by GURL » Wed Jan 26, 2011 3:08 pm

C'est une question qui me semble concerner d'abord les panos sphériques parce que le bracketing est souvent indispensable pour les panos 360° et que recouvrement d'un grand nombre de photos au zénith et au nadir provoque un nombre de liens et de CP tellement élevé que:
- l'optimisation favorise ces deux régions au dépend de la zone proche de l'horizon
- le nombre élevé de liens et CP rend très difficile d'intervenir manuellement quand on est pas satisfait du résultat automatique.

Une chose qui se produit peut-être aussi c'est que la correction des distorsions n'est pas bonne parce qu'il y a trop de photos qui sont cadrées de la même façon, j'ai des doutes sur la qualité de cette correction pour les panos avec bracketing mais tu es beaucoup mieux placé que moi puisque tu sais comment les choses se passent...

Avec l'option où les liens entre les stacks sont dans un seul niveau de bracketing, l'optimisation de la répartition des photos sur la sphère et l'alignement des photos à  l'intérieur des stacks sont devenues (en théorie) deux choses indépendantes. C'est pas encore vrai dans la pratique mais forcément, un jour où l'autre, elles deviendront réellemnt indépendantes !

Une solution qui me paraîtrait à  priori élégante serait d’homogénéiser la fenêtre des groupes et la fenêtre des layers, mais hélas ça donnerait un tableau à  trois dimensions!
- chaque stack dans une colonne
- chaque layer sur une ligne
- dans chaque case les différentes propriétés de la photo (exposition, focale, etc.) et ça c'est pas très satifaisant.

L'ordre des layers (qu'on peut modifier par drag and drop) indiquerait quels liens doivent être créés à  l'intérieur des stacks. Il faudrait pouvoir indiquer dans lequel des layer on veut les liens qui relient les photos sur la sphère.

En attendant, s'il était possible une fois qu'on est dans l'éditeur de point de contrôle de bloquer les liens internes au sein des stacks (avec une option supplémentaire dans les settings de l'éditeur de points de contrôle!) on pourrait n'optimiser que les liens qui relient les photos sur la sphère.

Une version simple d'Autopano sans stacks ni layers ni HDR ni fusion et une version avec toutes ces choses compliquées et vraiment liées les unes aux autres, ça me semblerait assez logique...
Last edited by GURL on Wed Jan 26, 2011 3:14 pm, edited 1 time in total.
Georges


Return to Le futur d'autopano

Who is online

Users browsing this forum: No registered users and 2 guests