[1.4.0 RC1 Linux] Taille du répertoire temporaire pou projection plane  

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 !
User avatar
fma38
Member
 
Posts: 5827
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France

[1.4.0 RC1 Linux] Taille du répertoire temporaire pou projection plane

by fma38 » Thu Sep 27, 2007 7:52 am

Je le met dans les bugs, mais ça n'en est peut-être pas un...

J'ai assemblé 2 panos que je veux rendre à  la fois en projection sphérique (mode HDRI, rendu en .hdr) et en projection plane. J'ai donc tout mis en queue, et, ce matin, seules les projections sphériques étaient générées. Il y a avait un mesasge d'erreur pour chaque pano en projection plane me disant qu'il n'y avait pas assez de place sur le répertoire temporaire (en gros, j'ai 10Go dispo). Pour ces 2 panos, il me réclame 20 et 50Go d'espace libre.

Pourquoi a-t-il pu monter les versions sphériques, et pas les versions planes ?
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100

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

by AlexandreJ » Thu Sep 27, 2007 8:37 am

Ca, c'est des maths. Le calcul de la taille maximum en sphérique n'est pas le même qu'en planar. Si tu as par exemple un panorama de 140°, cela peut donner un rapport proche de 4x sur la planar ( 2000x1000 en spherique pour 8000x4000 en planar ). Regarde bien la dimension finale du panorama en planar, elle est enorme.
C'est quelque chose qui en fait m'ennuie depuis longtemps, mais je ne sais pas comment le traiter d'un point de vue utilisateur. En planar, je fais le même calcul de densite qu'en sphérique, ce qui fait qu'un pixel au centre ( à  l'origine des axes de points de vue ) sera projeté en un pixel de même dimension. Mais en planar, cela implique qu'au bord, les pixels sont vachement zoomé et peuvent prendre 4, 5, 6 pixels de large. Est-ce bien ? Est-ce mal ? Je n'ai pas la réponse actuellement.

User avatar
fma38
Member
 
Posts: 5827
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France

by fma38 » Thu Sep 27, 2007 8:59 am

Ah, effectivement, c'était tout bête... C'est vrai que ça pourrait être bien de limiter la résolution sur les bords, mais pour ça, on en revient à  ce que j'avais soulevé il y a quelques temps, à  savoir qu'il faudrait un type de fichier à  résolution variable...

Ne pourrais-tu pas faire quelque chose d'intermédiaire, comme un mode de Projection qui comprime un peu les bords (anamorphose à  pas variable, si tu vois ce que je veux dire ?) ? Il faut brancher Gurl là  dessus ;)

En attendant, je limiterai la taille de sortie !
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100

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

by GURL » Thu Sep 27, 2007 1:03 pm

fma38 wrote:Ne pourrais-tu pas faire quelque chose d'intermédiaire, comme un mode de Projection qui comprime un peu les bords (anamorphose à  pas variable, si tu vois ce que je veux dire ?) ? Il faut brancher Gurl là  dessus ;)

Ca fait un bon moment que je suis branché et que je galère pour convaincre. Je pense qu'il me faut miner lentement les certitudes et travailler pour le long terme ! Une autre idée est de trouver des endroits célèbres qu'on ne peut pas photographier parce qu'il n'y a pas assez de recul (mais un endroit peut-il être déjà  célèbre alors qu'il n'est pas photographiable ?)

AlexandreJ wrote:C'est quelque chose qui en fait m'ennuie depuis longtemps, mais je ne sais pas comment le traiter d'un point de vue utilisateur. En planar, je fais le même calcul de densite qu'en sphérique, ce qui fait qu'un pixel au centre ( à  l'origine des axes de points de vue ) sera projeté en un pixel de même dimension. Mais en planar, cela implique qu'au bord, les pixels sont vachement zoomé et peuvent prendre 4, 5, 6 pixels de large. Est-ce bien ? Est-ce mal ? Je n'ai pas la réponse actuellement.

En rectilinéaire, tant que l'angle de vue reste très raisonnable (moins de 90° horizontal et vertical) il vaut mieux que tu évites les protestations du genre "Scandale ! la qualité des mes images source n'est pas préservée par APP !"

A partir du moment ou l'étirement sur les bords fait que la qualité d'image y devient abominable ces protestations n'ont plus aucun sens. Comme les coins n'ont souvent que peu d'importance je suggère:
- prendre en compte le plus grand des deux entre H-FOV et V-FOV et le bord le plus éloigné du centre (attention, le crop n'est pas forcément centré)
- choisir une densité telle que sur ce bord l'étirement linéaire ne dépasse pas 200% (ou peut-être 300%) Ca voudrait dire que si on imprime l'image à  300 DPI les bords sont à  150 DPI (ou peut-être 100 DPI.) Vu la forme de la courbe de la tangente ça éviterait les situations où la surface de l'image devient des dizaines où des centaines de fois trop grande.

Idéalement il faudrait demander quel est le nombre minimum de pixels source par unité d'angle qu'on souhaite (c'est un critère de qualité qui s'applique à  tous les panoramas, il devrait être la base du choix de l'objectif) mais hélas ça ne serait pas compris (et d'ailleurs je serais fort embarassé pour décider s'il s'agit ou pas d'angle solide même si j'ai fini par admettre que l'utilisation d'un nombre de paires de lignes est fondée sur l'expérience [note].)

Sur l'écran Lancer le rendu, pour les rendus rectilinéaires, tu pourrais aussi ne pas positioner par défaut le curseur au maximum mais sur cette "valeur raisonnable" ou afficher le pourcentage en rouge quand il atteint des valeurs stupides ...

Note: la définition d'une image est-elle deux fois meilleure quand le nombre de pixels est doublé (la quantité d'information enregistrable est bien doublèe, un texte deux fois plus long peut être enregistré par exemple) ou quand le nombre de pixels est multiplié par quatre (le nombre de paires de lignes double.) C'est une question qui a l'air trop théorique mais vaut des millions de dollard. Le fait que pour la télivision le nombre de pixels entre "HD ready" et "full HD" soit multiplié par quatre et pas par deux m'a beaucoup impressionné. Ca revient à  dire que pour les capteurs l'étape qui compte après 6 MP c'est pas 12 MP mais 24 MP (et ça joue aussi pour les pano en giga pixels...)
Georges

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

by AlexandreJ » Thu Sep 27, 2007 4:22 pm

GURL wrote:A partir du moment ou l'étirement sur les bords fait que la qualité d'image y devient abominable ces protestations n'ont plus aucun sens. Comme les coins n'ont souvent que peu d'importance je suggère:
- prendre en compte le plus grand des deux entre H-FOV et V-FOV et le bord le plus éloigné du centre (attention, le crop n'est pas forcément centré)
- choisir une densité telle que sur ce bord l'étirement linéaire ne dépasse pas 200% (ou peut-être 300%) Ca voudrait dire que si on imprime l'image à  300 DPI les bords sont à  150 DPI (ou peut-être 100 DPI.) Vu la forme de la courbe de la tangente ça éviterait les situations où la surface de l'image devient des dizaines où des centaines de fois trop grande.

C'est ce que je fais. Par contre, pour l'instant, je ne restreint pas de limite au zoom possible max. C'est une bonne idée.

GURL wrote:Idéalement il faudrait demander quel est le nombre minimum de pixels source par unité d'angle qu'on souhaite (c'est un critère de qualité qui s'applique à  tous les panoramas, il devrait être la base du choix de l'objectif) mais hélas ça ne serait pas compris (et d'ailleurs je serais fort embarassé pour décider s'il s'agit ou pas d'angle solide même si j'ai fini par admettre que l'utilisation d'un nombre de paires de lignes est fondée sur l'expérience [note].)

Euh, là , je défi quiconque est capable de me donner une valeur de pixels source/angle solide ... Trop complexe à  comprendre et encore plus à  expliquer ( même si le principe est juste ). Il faut d'ailleurs pondérer cela par objectif et focal ...

GURL wrote:Sur l'écran Lancer le rendu, pour les rendus rectilinéaires, tu pourrais aussi ne pas positioner par défaut le curseur au maximum mais sur cette "valeur raisonnable" ou afficher le pourcentage en rouge quand il atteint des valeurs stupides ...

C'est l'idée que j'ai eu aussi : deux petits indicateurs : l'un qui se trouve à  100% et qui correspond au calcul actuel, l'autre correspondrait au 100% sur le pixel le plus loin. Sur la base de ta réflexion ci-dessous, il semblerait que 200% et 300% seraient le bienvenue aussi.

User avatar
fma38
Member
 
Posts: 5827
Joined: Wed Dec 07, 2005 6:21 pm
Location: Grenoble, France

by fma38 » Thu Sep 27, 2007 4:48 pm

Tiens, dans le même temps, ne te serait-il pas possible d'estimer la taille nécessaire pour le rendu au moment où on met le projet dans la file, plutôt qu'au moment où il commence à  être rendu ? Le calcul prendrait-il trop de temps ? Comme ça, on s'en apercevrait tout de suite.

Même si, j'imagine, l'espace libre risque d'être différent au moment du rendu, cela donnerait quand même une indication. à€ la limite, simplement afficher un warning en se basant sur l'espace dispo à  ce moment-là , et demander à  l'utilisateur s'il veut quand même le mettre en queue où pas.
Frédéric

Canon 20D + 17-40/f4 L USM + 70-200/f4 L USM + 50/f1.4 USM
Merlin/Orion panohead + Papywizard on Nokia N800 and HP TC-1100

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

by AlexandreJ » Thu Sep 27, 2007 5:06 pm

Pas bête, mais j'aurais à  refaire le calcul au moment où le rendu commence effectivement. Car il peut y avoir plein d'autres panoramas en attente dans la liste qui vont remplir le disque avant que celui-ci soit effectivement rendu.

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

by GURL » Thu Sep 27, 2007 6:58 pm

AlexandreJ wrote:
GURL wrote:Sur l'écran Lancer le rendu, pour les rendus rectilinéaires, tu pourrais aussi ne pas positioner par défaut le curseur au maximum mais sur cette "valeur raisonnable" ou afficher le pourcentage en rouge quand il atteint des valeurs stupides ...

C'est l'idée que j'ai eu aussi : deux petits indicateurs : l'un qui se trouve à  100% et qui correspond au calcul actuel, l'autre correspondrait au 100% sur le pixel le plus loin. Sur la base de ta réflexion ci-dessous, il semblerait que 200% et 300% seraient le bienvenue aussi.

200% et 300% : indiqueraient l'étirement sur les bords. Autre possibilité afficher cet étirement dans une petite fenêtre ou carrément utiliser celle qui existe déjà  en y affichant un pourcentage supérieur à  100%

Ton marqueur (qui me plait) va diviser la barre en deux:
- dans sa partie gauche aucune portion du panorama n'est à  la résolution optimale.
- dans sa partie droite on passe d'une taille (raisonnable) ou les bords sont à  100% (résolution optimale) à  une taille où c'est le centre qui est à  100% et les bords à  une résolution qui dépasse (de peu ou de baucoup trop selon les cas) les 100% (en pourcentage de la photo correspondante.)

L'essentiel est de faire comprendre que quand les pixels des photos du bord s'étalent sur plusieurs pixels le résultat sera flou sur les bords (donc en général moche) et que le rendu devient plus long, parfois ridiculement long!

La lisibilité de cette barre de réglage a toujours beaucoup d'importance: si on la lit mal on perd beaucoup de temps (en particulier en sortant des panoramas qu'on refait ensuite parce qu'on a pas vu les imperfections sur l'aperçu.)

Idéalement la barre devrait être graduée en minutes ou en heures d'un cotè, en cm ou en m de l'autre. La graduation en temps n'est pas possible, c'est dommage car le temps varie comme le carré de la distance à  l'origine (passer du millieu au bout multiplie le temps par 4, voire bien pire.)

L'affichage des dimensions de l'image est vraiment une très bonne idée mais je trouve le choix de 72 DPI contestable...
Georges

User avatar
taf
Member
 
Posts: 2680
Joined: Tue Dec 20, 2005 12:13 am
Location: Paaaaaaris !

by taf » Wed Oct 03, 2007 10:27 pm

Déplacé dans Futur, car il y a des elements intéressant ici... Mais plus de bug ;)
Look. There's a rhythmic ceremonial ritual coming up !


Return to Le futur d'autopano

Who is online

Users browsing this forum: No registered users and 2 guests

cron