sur un site "un peu" fréquenté, j'ai souvent des traitements d'images qui plantent silencieusement (pas de log php), et qui génèrent donc les pages dans un état "incomplet".
Grosso modo, dans le header, je traite un bandeau :
[(#GET{img}|image_recadre{1440:340,-,focus}|image_reduire{1440,340}|image_aplatir{jpg,ffffff,90})]
A la source, je peux avoir un PNG de 1500x500 de 1.2 Mo par exemple, dans le cas du dernier plantage.
Si ça plante, la page s'arrête au bandeau, mais avec un var_mode=images on peut la regénérer.
Mais comme c'est silencieux, c'est assez sournois.
Je pense que ça peut venir d'une limite de mémoire de PHP, qu'en pensez vous ?
Elle est à 348 Mo actuellement.
Sinon, par expérience, est ce que Convert serait plus efficace / plus fiable que GD ?
Ok, en lisant le code des filtres je comprends : convert passe par un appel à une commande système (exec), donc si ça plante ça n'empêche pas la suite du traitement PHP, contrairement à GD qui utilise des fonctions PHP.
J'ai bon ?
Ok, en lisant le code des filtres je comprends : convert passe par un appel à une commande système (exec), donc si ça plante ça n'empêche pas la suite du traitement PHP, contrairement à GD qui utilise des fonctions PHP.
J'ai bon ?
Oui, c'est justement tout l'intérêt d'utiliser convert
Mais du coup, concrètement, quelles sont les limites de convert, au niveau système ?
Sur debian c'est 256MB par défaut si je me souviens bien, et ça peut se régler dans le fichier /etc/ImageMagick-6/policy.xml
SPIP propose d’utiliser convert, mais ça ne concerne que les redimensionnements d’image (|image_reduire), le filtre historique, utilisé dans l’espace privé, et qui donc bénéficié d’une quintuple implémentation (gd/gd2/convert/netpbm/imagick).
Pour tous les autres filtres de traitement d’image (donc a commencer par |image_recadre), c’est uniquement GD2 qui est utilisé, quel que soit le réglage de l’espace privé.
Enfin là je perçois bien une idée qui serait de lancer un process spip-cli pour faire chaque traitement d’image dans un process indépendant au lieu de le faire dans le process principal, ce qui éviterait le process principal d’échouer brutalement.
Mais ça repose in fine sur la disponibilité d’exec, ce qui n’est pas universel, donc c’est un peu compliqué de passer du temps sur une solution qui ne serait que partielle, ou alors il faudrait le faire en http sur soit même si on a pas exec...
Bref le ration energie à depenser/emmerdements fait que pour le moment on traine toujours ce problème...
Merci pour la suggestion mais non, je peux avoir des PNG en entrée, et je ne veux compresser en jpeg (compression destructive) qu'à la fin.
Et puis les traitements en PHP bouffent de la mémoire en fonction de la résolution de l'image, pas de son poids, donc ça ne changerait rien.
