Re: Plantage traitement d'images

Merci de la précision pour les filtres.

Effectivement c'est assez difficile à démerder.
J'ai tenté un truc dans dd pour essayer de choper ces erreurs, mais j'ai 
un doute, vu que chez moi elles n'apparaissent pas du tout dans le log 
d'erreur PHP.
https://git.spip.net/spip-contrib-extensions/dd/commit/0a8672221f32d9c753c2e38ad6900ba6b38a8383


Le 02/02/2021 à 15:29, Cerdic a écrit :
> Oui enfin achtung hein.
> 
> 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é.
> 
> Ce plantage brutal et silencieux de GD est une plaie depuis mathusalem, 
> et il y a pas vraiment de solution
> https://stackoverflow.com/questions/1117344/a-fail-safe-way-to-prevent-gd-image-library-from-running-out-of-memory-php 
> <https://stackoverflow.com/questions/1117344/a-fail-safe-way-to-prevent-gd-image-library-from-running-out-of-memory-php>
> 
> 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...
> 
> -- 
> Cédric

-- 
nicod_