Image-stitching and virtual tour solutions My account Updates
It is currently Thu Oct 02, 2014 3:30 am

All times are UTC + 1 hour




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Thu Oct 25, 2007 12:24 pm 
Offline
Member

Joined: Mon Jun 25, 2007 6:14 pm
Posts: 150
Location: Annecy
Je souhaite que la fonction du redressement des lignes verticales soit plus précise. La méthode actuelle par laquelle on indique les lignes qui doivent être redressées est facile, rapide et efficace, mais elle n'est pas précise à  cause d'une image prévisualisée approximative car grossièrement pixelisée. Le zoom n'apporte pas grand-chose car il augmente simultanément les pixels. J'en suis las de recommencer à  plusieurs reprises le même rendu, à  faire des corrections à  tâton (ayant en mémoire le dernier résultat obtenu). J'estime à  2 degrés la tolérence des écarts courants provenants du dispositif actuel. Pour les paysages naturels, ceci ne présente aucun inconvénient. Il en est tout autrement pour l'architecture. Qu'en penses-tu, Alexandre?
Hub


Top
 Profile  
 
 Post subject:
PostPosted: Thu Oct 25, 2007 1:20 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
Tu peux déjà  changer de résolution de l'aperçu. Par défaut, c'est vrai qu'il est plutot petit (800x400), mais rien ne t'empeche de le faire nettement plus grand ( 1600x800 par exemple ).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 26, 2007 1:52 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
AlexandreJ wrote:
Tu peux déjà  changer de résolution de l'aperçu. Par défaut, c'est vrai qu'il est plutot petit (800x400), mais rien ne t'empeche de le faire nettement plus grand ( 1600x800 par exemple ).

Le scrolling est tout à  fait compatible avec l'outil Verticales.

On peut (hmmm: voir Bug Splat...) choisir pour l'aperçu un format ayant une forte défintion verticale (et malheureusement une définition horizontale exagérée) et utiliser les barres de défilement.

Par ailleurs, pour mieux voir ce qui ne va pas on peut utiliser Crop/Tailler et Uncrop/Auto-Ajustement (ou revenir en arrière avec l'historique)

Bien sur c'est à  faire avec la définition d'affichage de l'aperçu qui correspond au moins à  celle de l'écran.

Cette utilisation détournée de Crop est plus générale. Elle permet "d'observer de près" les régions du panorama qui posent un problème. Elle est d'autant plus utile qu'on à  tendance à  n'utiliser le rendu que pour l'ensemble du panorama et à  100%.

Il faudra un jour trouver une manière efficace de compenser l'absence d'outil correspondant à  l'onglet "Preview" des stitchers Panotools (en attendant stocker dans l'historique la derniére version de l'aperçu et la réutiliser si on revient en arrière d'un cran pourrait aider.)

:P Que le premier qui n'a jamais renoncé à  corriger une erreur facile à  corriger parce qu'il est passé directement de l'aperçu par défaut d'APP au rendu à  100% me lance le premier sarcasme!







_________________
Georges


Last edited by GURL on Fri Oct 26, 2007 1:49 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 26, 2007 2:22 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
Note pour Alexandre

C'est en faisant des essais pour ce fil que j'ai eu les 2 Bug Splat de cet après-midi

Pour 2400x1200 l'utilisation mémoire est de 1 724 140 Ko, pour 2800x1400 ...j'ai pas pu savoir!

Paramètres - Editeur - Qualité de l'aperçu:
Melangeur: linéaire
Interpolation: au plus proche

_________________
Georges


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 26, 2007 4:02 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
J'ai fait des mesures sur l'utilisation mémoire de l'éditeur. C'est vrai que c'est chaud ! Evidemment, ca dépend du type de panorama ( genre si tu as 50 images au zenith, tu utilises beaucoup plus de mémoire que juste des images au niveau de l'équateur ).
Bref, pour un 360x180 de 19 images :
Code:
  800 x  400 :  150 Mo
 1600 x  800 :  387 Mo
 3200 x 1600 : 1110 Mo


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 26, 2007 6:00 pm 
Offline
Member

Joined: Fri May 05, 2006 6:20 pm
Posts: 62
Location: Limoges - France
c'est kolossal, comme taille mémoire consommée...

est ce que l'utilisation d'OpenGL ou DX9 ne permettrait pas d'améliorer ça?
une image=une texture; plaquée sur une surface que l'on déforme pour corriger la correction de lentilles. l'application des corrections de couleurs pourrait se faire au travers des effets de la carte graphique --> grande amélioration de la réactivité de l'interface.

_________________
http://www.bdphotos.fr


Top
 Profile  
 
 Post subject:
PostPosted: Fri Oct 26, 2007 6:09 pm 
Offline
Administrator
User avatar

Joined: Mon Nov 14, 2005 4:56 pm
Posts: 5901
Location: Francin, France
C'est comme cela que c'est prévu pour plus tard.
Note en passant, que nous n'utilisons pas des textures simples car tous les calculs sont fait sur 32bits / composantes. C'est ca qui utilise la mémoire.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 27, 2007 11:19 am 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
J'en déduis qu'en utilisant la meilleure définition possible pour l'affichage de l'aperçu, le zoom à  200% et les barres d'ascensseur on pourrait placer les verticales avec une très bonne précision (je viens de faire un essais convaincant avec la définition maxi.)

Par contre la chose à  savoir (en attendant que ça s'arrange...) est que pour ça il faut absolument augmenter la définition en suveillant soi-même la quantité de mémoire vive utilisée par APP (mon essai c'est avec seulement 2 photos au lieu des 6 contenant le zenith et des 6 autres contenant presque le nadir que le panorama comporte normalement !)

_________________
Georges


Top
 Profile  
 
 Post subject:
PostPosted: Sat Oct 27, 2007 1:28 pm 
Offline
Member

Joined: Tue Dec 06, 2005 1:57 pm
Posts: 2946
Location: Grenoble
Proposition audacieuse mais qui me séduit beaucoup: un mode d'affichage avec "beaucoup moins de bits", voire en noir et blanc (mais dans ce cas en option seulement, ça fait trop rétro !), pour tout ce qui ne se préoccupe pas de la couleur, ça serait Vaâachment bien.

Dans l'éditeur de CP j'ai l'impression de passer la moitié de mon temps à  attendre le re-calcul pour l'affichage de l'aperçu (aperçu que je regarde même pas, d'ailleurs, puisqu'il il est tout tordu :lol:)

_________________
Georges


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group