🌍
Français
@Mtxr : post:188487
Bonjour,
J'ai le même type de pb sur un hébergeur payant ;) avec les photos préalablement chargées avec ploader et d'un poids moyen de 6 à 8 Mo... (en 5100x 3400 environ)
La gestion par lot refuse tt simplement de les traiter : le compteur défile à tte vitesse et résultat néant.
Un pano en 4000x1500 passe, mais un en 9700x3700 non...
Comment est fixé ce paramètre, et que puis-je faire sans avoir à effacer les photos pour les remettre avec une taille inférieure ?
Sinon au bilan, je continuerai en ftp formaté à l'avance, et n'utiliserai pas une part intéressante de la 2.4 ....
Du moins chez cet hébergeur, car je viens de passer chez OVH, où j'espère ne pas avoir les mêmes soucis... enfin j'espère... mais je tenterai la mutation plus tard car la galerie a des visiteurs ces derniers temps pour cause de photos de mariage.
amade a écrit:
Peut-on avoir une doc minimale indiquant :
- les noms des fichiers caches selon la taille
- la dimension en pixels correspondant à chaque taille
l'objectif étant de le générer sur PC avant de le télécharger dans le cache.
les dimensions sont celles paramétrées dans l'admin : il faut regarder pour les connaitres.
le cache est généré dans le répertoire _data/i/galleries ou _data/i/upload en fonction de la méthode (FTP ou ploader par exemple).
après, ça reprends l'arboresence de fichier.
L'image /galleries/toto/01/photoA.jpeg aura pour correspondances :
- /galleries/toto/01/photoA-th.jpeg => miniature
- /galleries/toto/01/photoA-sq.jpeg => format carré
- /galleries/toto/01/photoA-sm.jpeg => small
- /galleries/toto/01/photoA-me.jpeg => medium
- /galleries/toto/01/photoA-la.jpeg => large
- /galleries/toto/01/photoA-xl.jpeg => xl
- /galleries/toto/01/photoA-xs.jpeg => xs
Gotcha a écrit:
Le problème à la base c'est... l'hébergeur. Gratuit certes mais avec des restrictions qui sont de plus en plus insupportables
oui et non
Par exemple chez moi, j'ai ce genre de problèmes. Et pourtant, pour exécuter le script le processus dispose de 120s et 256Mo de mémoire lui sont alloué.
C'est juste lié aux dimensions de la photo (et non pas à la taille en Mo qu'elle peut faire, pour un jpeg ça ne veut pas dire grand chose).
Je suppose que c'est lié à l'utilisation de GD : GD est lent et pompe ses ressources sur celles du script...
Après, vu les paramétrages de mon serveur, seules quelques photos ont ce type de problème.
Avec ImageMagick je pense que ce type de soucis est moins probable.
La solution : uploader des photos aux dimensions un peu plus réduites...
amade a écrit:
Peut-on avoir une doc minimale indiquant :
- les noms des fichiers caches selon la taille
- la dimension en pixels correspondant à chaque taille
Difficile de répondre à la question les test d'un jour sont pas toujours vrais le lendemain ou l'heure d'après :-(
Il y a 3 jours j'ai envoyé une photo sur un site free cette même photo n'est pas passé aujourd'hui :-(
Le problème à la base c'est... l'hébergeur. Gratuit certes mais avec des restrictions qui sont de plus en plus insupportables.
D'autres hébergeurs moins gratuits existent et surtout bien plus performants.
Bref, vous pouvez toujours lire : post:174929
Bonjour,
J'ai bien les mêmes symptômes.
Les photos anciennes sont bien générées à la volée. Celles faites avec des appareils récents ne passent pas.
Peut-on avoir une doc minimale indiquant :
- les noms des fichiers caches selon la taille
- la dimension en pixels correspondant à chaque taille
l'objectif étant de le générer sur PC avant de le télécharger dans le cache.
Merci
Alain
je ne pense pas que free redimensionne des photos supérieur à 2/3 mégas (la résolution compte aussi)
Peux tu faire l'essaie de créer le cache pour 1 photo avec la gestion par lots
et éventuellement sur une photo de 2Mo
Ce sont des Jpeg de 5-6Mo.
Quel est la taille de tes HD ?
En suivant les retours fait sur le forum, j'ai réussi la migration (création du fichier de conf. et suppr. de certaines parties du .htaccess).
Par contre, la génération des images à la volée ne fonctionne pas chez moi (i.php):
Warning: set_time_limit() [function.set-time-limit]: Cannot set time limit in safe mode in /mnt/149/sdb/d/a/roche.mathieu/piwigo/i.php on line 504
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 13824 bytes) in /mnt/149/sdb/d/a/roche.mathieu/piwigo/admin/include/image.class.php on line 653
Je vais sans doute travailler sur un truc pour faire le boulot en local.
Merci.
les tailles de cet écrans sont des tailles maximales, donc les ratios sont conservés (sauf si vous cochez "Crop" évidement)
Ok. Merci pour le retour.
En fait, est-ce que ce n'est pas comme avant c'est à dire un répertoire par taille ?
Dans ce cas, je pourrais créer les n répertoires qui vont bien avec les tailles désirées. Non ?
Par contre, j'ai vu ici http://piwigo.org/forum/showimage.php?p … screen.png qu'on pouvait choisir les tailles.
Quand, je mets en ligne des photos, elles viennent souvent d'appareils différents et donc ont parfois aussi des ratios différents.
Comment peut-on adresser ces cas ?
Merci.
Comme vous le dites, à la limite vous le faite en local sur une copie de votre galerie et vous retransférez le tout...
Disons que c'est faisable, mais franchement fastidieux. Il est facile de désactiver des tailles pour limiter le travail de Free.fr, mais préremplir le cache, c'est un boulot assez lourd.
