Discussion :

[ToTo13]

Bonjour,

je travaille sur une GRANDe quantité de volumes. Pour être précis, j'ai 2 000 000 de volumes, de dimensions 19 x 19 x19. J'ai donc potentiellement à travailler avec un NumPy nbarray de dimensions [2 000 000, 1, 19, 19, 19] (le 1 étant pour le nombre de couleurs, car ces volumes sont en fait des portions d'images 3D).

Actuellement, pour récupérer les informations afin de remplir un tel tableau, j'ai 2 000 000 de dossiers, chacun contenant 19 images de taille 19 x 19.
Or pour pouvoir charger ces images et ainsi commencer à faire le vrai boulot, cela prend plusieurs heures (presque une journée me semble t-il) et je trouve cela trop long. D'autant plus, que je lance beaucoup de script et que chaque script doit faire ce même travaille de lecture chargement.

Ma question est donc : est ce qu'il existe un moyen en python de sauver toutes mes images (dans un format différent) afin qu'elles puissent être lues beaucoup plus rapidement ?

Merci par avance...

PS : petite/grosse précision... il arrive que je n'ai besoin QUE de 500 000 volumes. Donc j'aimerai ne pas avoir à charger les 2 000 000 volumes pour n'en garder qu'un quart à la fin.

[wiztricks]

Salut,

Ma question est donc : est ce qu'il existe un moyen en python de sauver toutes mes images (dans un format différent) afin qu'elles puissent être lues beaucoup plus rapidement ?

Si une telle chose existait, ce serait plutôt une bibliothèque C accessible au programmeur Python via un wrapper.
Pour le reste, la vitesse de la mémoire étant 1000 X plus rapide que celle des disques, on pourra paralléliser avec des threads mais çà restera "IO bound": pour améliorer le temps de chargement, il faudra ajouter (plein) des disques (pour distribuer les IO tout en s'assurant qu'on ne sature pas la mémoire, les bus d'entrée-sortie,...).
note: on peut dire aussi qu'en liisant 13 images de 13x13, on a un overhead d'opérations côté file system qu'on pourra réduire en mettant les 13 images dans un seul fichier mais il faut s'assurer des capacités physiques pour supporter la charge avant de modifier la structure sur disque.

- W

[ToTo13]

Merci pour la réponse !

note: on peut dire aussi qu'en liisant 13 images de 13x13, on a un overhead d'opérations côté file system qu'on pourra réduire en mettant les 13 images dans un seul fichier mais il faut s'assurer des capacités physiques pour supporter la charge

Comment est ce que cela fonctionnerait ?

Je travaille sur un cluster, tout est assez solide !

avant de modifier la structure sur disque.

Que faudrait il que je fasse exactement ?

[shell13010]

Bonjour,

Un système de sprite serait plutôt intéressant dans ce cas précis pour gagner en rapidité et limité le nombre d'opération.

étant donner que tout les images ont les même dimensions, j'aurais regrouper x nombre d'image dans une image, sauvegarder la position des images

dans un fichier index pour pouvoir appeler les images que j'ai besoin suivant leur positions dans l'image principal.

Sa limiterais considérablement le nombre d'opération.

un exemple pour générer des sprite avec PIL.

[ToTo13]

Merci pour la réponse.
Ta solution est en fait de regrouper les images en une grosse image, afin d'avoir à lire un gros fichier plutôt que plusieurs petits.

[shell13010]

Merci pour la réponse.
Ta solution est en fait de regrouper les images en une grosse image, afin d'avoir à lire un gros fichier plutôt que plusieurs petits.

Oui exactement,

actuellement de tête, je peux me tromper il a 38 000 000 d'images, alors que si les 19 images d'un dossier regrouper en 1 image le résultat serait de 2 000 000.

Comme ce sont des petites images 19x19 , on pourrait largement regrouper plus d'images pour réduire le nombre d'opération sur fichier.

L'image sera charger qu'une fois en mémoire au lieu de n fois donc le gain de rapidité sera plus importante et le traitement des données moins lourd.

A la base, le système de sprite et beaucoup utiliser en CSS pour limiter le nombre de requête/bande passante.

le rendu peut-être dans ce style ou a la verticale 19px de Large et x en Hauteur, ou a l'horizontal 19px de Hauteur et x de Largeur.

[ToTo13]

Sur la même idée, n'ai je pas intérêt à utiliser des Pickle/cPickle ?
L'inconvénient majeur serait que je doive lire la totalité du fichier, mais comme c'est "une même string", cela devrait être vraiment plus rapide. Non ?
Si oui, le fait que je perde du temps à lire trop d'information, devrait être compensé par le fait que ça aille beaucoup plus vite.