 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1
J'ai donc lancé le rendu de mon premier Gigapixel, et ce matin, j'ai découvert le programme planté avec l'erreur :
Write image...
terminate called after throwing an instance of 'std::runtime_error'
what(): Failed lseek: Errror, filename : /tmp/SB_FKhjwP
/usr/bin/autopanopro: line 4: 23420 Abandon /usr/lib/autopanopro/autopanopro
Visiblement, c'est smartblend qui gueule. Or, comme il utilise /tmp au lieu de ma partition temporaire spéciale APP, je me demande s'il ne lui manque pas de la place. Ce matin, il reste 1,5Go de libre dans /tmp, mais je vois qu'il y a un fichier de plus de 2Go. Est-ce que si cela avait été un problème de place il aurait laissé la partition pleine à 100% avant de crasher ? Ou bien, a-t-il effacé une partie de ses fichiers temporaires avant de vautrer ?
Offline
En fait, je viens de m'apercevoir que le fichier /tmp/SB_FKhjwP est présent sur /tmp, mais fait 0 octets... Peut-être un soucis avec mon disque externe (USB)... Je relancerai le rendu pour être sûr.
Offline
Fred : 15 go au total, ca me parait pas assez pour calculer un pano gigapixel...
Pour info, le calcul du pano fait avec 24 images du 40D (10mp) a fait monter le répertoire TMP à 1,42go !
Offline
dans TMP, tu vas avoir un fichier par image de ton pano + un énorme fichier TIF qui représente le pano entier. C'est lui qui doit te faire exploser ton rep TMP.
Offline
Dans toutes les version 1.4*, Smartblend a ce soucis de mettre le repertoire temporaire où il ne devrait pas (en tout cas, pas ou on lui a dit).
Sous linux, c'est /tmp/ par en dur.
C'est evidement corrigé. De plus, on a trouvé deux autres bugs qui peuvent causer des plantages avec smartblend.
Le seul truc qui reste encore ouvert, c'est ces histoires de blocs carrés dans les zones proches de 255 en 8bits. C'est un problème complexe d'arrondi d'octet.
Offline
Taf, j'utilise bien une partition spéciale qui dispose de 30Go pour les tiff de APP, mais c'est juste smartblend qui force dans /tmp. Je relancerai le pano cette nuit avec un mouchard sur la taille de /tmp pour voir si elle sature au moment du plantage...
Tien, à ce propos, après qu'APP a planté, les tiff étaient toujours là. Super, me dis-je, comme ça, APP n'aura pas à les refaire (c'est long !). Et bien si ! Il les a viré au lancement suivant, le bougre... Dans le cas d'un plantage, ce serait bien qu'il ne fasse pas le ménage. D'ailleurs, je croyais qu'il ne le faisais qu'en quittant le soft... Le faire en entrant peut avoir des effets néfastes. Faudrait poser la question à l'utilisateur, non ?
Offline
En théorie c'est impossible de redémarer après un plantage puisque l'état des lieux est imprévisible...
Du temps où il était habituel qu'un ordinateur tombe en panne plusieurs fois par jour (ou par semaine) on faisait un "check point" susceptible d'être utilisé pour faire un "restart". Avant de lancer le rendu je suppose que tu as sauvegardé le projet: c'est à peu près la même idée. Si je réinterpréte ta demande de cette manière ça donne: serait-il possible de faire un checkpoint juste avant de lancer Smartblend.
En fait les OS de l'époque était tellement simples qu'il suffisait de faire un appel à l'OS pour qu'il s'occupe de tout (par ex. prévenir l'opérateur de monter une bande magnétique pour enregistrer l'état des choses et lui coller une étiquette.) Sur Unix ça a forcément existé. Sur Linux? 
Remarque: dans le même esprit, avant de venir faire les choses en vraie grandeur un week-end on aurait fait des essais en réduction. Normalement on peut déjà vérifier beaucoup de choses sur un panot au 1/4 (16 fois plus rapide) ou au 1/3 (9 fois plus rapide.)
Last edited by GURL (2007-09-09 10:11:29)
Offline
Ca, c'est corrigé, je le passe en archive
Offline
Pages: 1
