 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
Pages: 1 2
Je vais rapidement passer au plugin merlin qui parse le fichier xml de configuration de papywizard.
Alors ce qu'il faudrait rapidement mettre en place, c'est une page wiki qui explique le but du fichier, son format, pour qu'on puisse ensuite pousser d'autres tête à utiliser ce format. Comme cela, on en fait un standard et ca marchera avec toutes les têtes pareils ( et avec toutes les futures version de papywizard différentes aussi ... si jamais il y a des portages sur d'autres languages, plateformes ).
Fred, pourrais-tu te charger de faire une petite doc du fichier sur le wiki ?
Offline
Oui, sans soucis. Par contre, cela voudra-t-il dire que tout est figé ? Pour le moment, je pense que la structure est correcte, mais bon, je serai peut-être amener à modifier des petits trucs, en fonction de ce que fera Papywizard dans le futur... C'est gênant ? Faut que je mette une version, au moins.
Sous quel forme présenter ça ? Sur un simple exemple, ou carrément avec une feuille XML schéma ? Je n'ai jamais fait ça, mais ça pourrait être l'occase, et ça ferait plus sérieux 
Offline
Non, c'est pas figé, c'est une proposition de standard : ensuite, il y aura v1, v1.1, etc.
Je vois bien cela en trois parties :
- 1. But de cela : avoir un format standard, ouvert pour les têtes,
- 2. Présentation des choix fait et pourquoi : format texte, xml,
- 3. Structure du fichier, avec ses 2 grandes parties : entête et partie photo ( 2 exemples commentés suffisent je pense, pas la peine de s'em...er avec un XML schéma ).
Offline
Ok, pigé. Je planche là dessus rapidement.
Offline
Alexandre, si c'est possible (license ?), pourrais-tu poster les fichiers générés par les autres têtes motorisée que tu as ?
Si on veut pondre une sorte de standard (avant normalisation ), je pense qu'il faut prendre en compte les spécificité de chacun, et faire en sorte que tout le monde puisse facilement utiliser le format XML. Ça passera certainement par un certain nombre de champs optionnels, plus un ou plusieurs champs de description du hardware...
Offline
OUi, je te prepare cela pour fin de semaine (je suis en déplacement pendant 4 jours là ).
Offline
Pas de problème. En attendant, j'ai commencé la page :
http://www.autopano.fr/wiki/action/view … e_données
Au fait, c'est APP ou APG qui sera capable d'exploiter ce genre de fichier ?
Offline
Alexandre, que penses-tu de l'idée de GURL d'ajouter le paramètre roll aux positions des images ? Certains APN n'ont pas de capteur d'orientation, et, dans les positions extrèmes, ceux qui en ont ne marchent pas toujours correctement. Est-ce qu'il est envisageable, lorsque tu utilises le plugin Merlin, d'utiliser les infos de ce paramètre plutôt que les EXIF ?
Actuellement, on a un paramètre 'cameraOrientation' (pour le moment, portrait/paysage, mais qui pourrait être étendu à n'importe quel angle, car certains montent leur boîtier incliné). Mais on pourrait dire que c'est roll:
Paysage -> roll=0°
Portrait -> roll=+-90° suivant sens (le signe n'a peut-être pas beaucoup d'importance ?)
Autre -> roll=xx°
D'autre part, il est possible d'utiliser la tête dans n'importe quelle position (Trekker l'a prouvé ). Je propose de conserver les angles yaw, pitch et roll dans le repère de la tête, comme si elle était verticale (cas le plus fréquent), et d'ajouter un paramètre d'orientation de la tête elle-même; la transformation vers les vrais angles yaw/pitch/roll serait alors possible en utilisant le paramètre 'headOrientation'.
Qu'en dis-tu ?
Offline
Je dis go ! Bonne idée
Offline
J'avance tout doucement. Que dites-vous de la version actuelle (je ne met à jour que la page en anglais) :
http://www.autopano.net/wiki/action/vie … escription
(et même là, les exemples ne sont pas à jour non plus)
Offline
Ca m'a l'air très bien.
Offline
Bon, si tu veux un projet utilisant la version actuelle ("a") du fichier xml, je peux t'envoyer ça ce soir...
Offline
Oui, j'aimerais bien un projet avec les images qui vont avec. Je suis entrain de coder tout cela est les xml que j'ai sont outdatés.
Offline
Ok, je m'occupe de ça rapidement.
Offline
Je vais traduire cela et mettre ce format bien en évidence sur le wiki anglais.
Offline
Traduction déjà faite ... je l'ai trouvé sur la partie française. J'ai fait un petit move pour mettre tout cela d'équerre avec la version anglaise.
Je profite pour mettre une nouvelle entête : specification ( y-aura l'unique lensID, panohead xml specification et un autre truc qui vient bientot ! )
Offline
Ah, oui, tiens, je m'étais trompé ! Est-ce qu'on peut détruire la page du wiki en anglais sur la partie française ? Je n'ai jamais trouvé comment faire ça... Sinon, je vide la page, et je met juste un lien sur la bonne.
Offline
Un petit screenshot du plugin papywizard
Offline
Cooool 
2 questions :
1) Pourquoi un curseur overlaping ?
2) Les images seront-elle orientées dans le bon sens pour la prévisualisation ? Est-ce ici un soucis avec la détection de mon objectif ?
Offline
Les deux curseurs du bas sont juste là pour avoir un aperçu plus propre (note, avec un calcul interne que je fais, je dois pouvoir les virer maintenant, ils sont obsolètes ).
Oui, la thumb de ton boitier est pas droite. Pourtant, il le détecte bien. Ca doit un petit bug à corriger dans l'orientation exif.
Offline
Tu n'envisages pas d'utiliser l'info roll du fichier XML ? Vu que j'ai ajouté aussi l'orientation de la tête, on peut retrouver l'orientation exacte des photos, même pour des boîtiers ne possédant pas de capteur. Ça pourra aussi être utilisé pour des appareils inclinés, car il y a la possibilité de donner le roll exact si cameraOrientation est sur custom (j'envisage de le faire avec mon fisheye pour passer de 8 à 6 photos pour la sphère complète).
Peut-être proposer les 2 méthodes, avec un switch lors de l'import ?
Offline
AlexandreJ wrote:
Les deux curseurs du bas sont juste là pour avoir un aperçu plus propre (note, avec un calcul interne que je fais, je dois pouvoir les virer maintenant, ils sont obsolètes ).
Est-ce que tu peux carrément prévisualiserr les images quasi comme elle apparaîtront au final, c'est à dire en les faisant se chevaucher en fonction de leur coordonnées ?
Offline
AlexandreJ wrote:
Un petit screenshot du plugin papywizard
How would/does it look with hundreds of images in a pano?
Do the thumbnails scale depending on number of images in the array/matrix?
Can the user choose the size of the thumbnails?
Is there any value in having a gap between the rows and columns?
Do we need to see the Y/P values in a title 'bar' on each image?
I think you've said you will fix the orientation of the images?
Most importantly - using this data does APP now manage to place (and stitch) correctly relatively featureless images that previously would have been 'orphans'?
Last edited by mediavets (2008-11-19 15:09:58)
Offline
Le roll est parsé dans le fichier et sera utilisé dans autopano.
L'aperçu complet ... Belle idée, mais revient à recoder l'éditeur dans un plugin. Je voulais un truc rapide de prévisualisation, pas de simulation.
Offline
Oui, tout à fait. L'idée n'était pas de lancer les points de contrôle et tout, mais juste positionner les images en utilisant leurs coordonnées et leur fov, sans même s'emm.. à gérer une quelconque fusion (la suivante écrase la précédente)... C'est la même chose que ce que tu as fait, mais au lieu de mettre chaque image dans un cadre, on les met toutes sur le même canvas, à sa coordonnée théorique codée dans le fichier.
Ceci-dit, va se poser le problème du bracketing, ou de certaines positions reshootées (prochaine fonctionalité de Papywizard)... Finalement, en utilisant la méthode ci-dessus, ça permet plus facilement de faire des piles, comme avec des cartes, en décalant chaque nouvelle image un poil...
Offline
Pages: 1 2
