Limitations memoire et imagecreatetruecolor

Bonjour,

J'ecris un script qui genere des images de taille variable, pouvant etre tres grandes.
Lorsque mes images sont trop grandes, imagecreatetruecolor() genere une "Fatal Error" PHP que je n'arrive pas a intercepter.

Est-ce que quelqu'un connaitrait une facon de (au choix):
- Recuperer cette erreur
- Calculer la taille memoire necessaire pour une image de taille donnee

J'ai essaye la deuxieme approche, mais d'apres ce que j'ai trouve sur google, ca depend beaucoup de la plateforme du serveur.

J'ai augmente la taille memoire disponible sous PHP avec un ini_set('memory_limit', '384M') mais comme l'algorithme qui calcule les largeurs et hauteurs de l'image n'a pas de bornes superieures, ca plantera toujours a un moment ou a un autre...

J'avoue etre un peu a court d'idees... alors si vous en avez, n'hesitez pas !
Toute piste pour resoudre ce probleme est la bienvenue !

Eric

de toute facon, ca plantera forcement si tu depasses la limite...

tu peux t'imaginer qu'en gros, une image prend width*height*bpp/8 (bpp= bits par pixels) octets

"Protégez les arbres, mangez du castor."

ok

Cool, meme le forum s'y met en me bouffant mon poste
(Desole pour le poste precedent, j'ai entre mon texte, mais en validant ca a envoye un post vide...Je recommence donc : )

Merci de ta reponse Coucou747, mais mon but est justement d'empecher que ca plante, par exemple en affichant un message disant que cette fonction n'est pas disponible pour un objet de cette complexite ou bien en le simplifiant jusqu'a ca que ca genere une image qui ne pose pas de probleme.

Je pensais comme toi pour la fonction d'approximation mais lorsque je mesure de maniere empirique sur mon serveur de dev (windows), je trouve des valeurs de bpp entre 60 et 88, ce qui me parait beaucoup (a moins que les canneaux soient geres en float???).

Et surtout, les differents posts que j'ai croise sur le sujet me laissent penser que ce resultat depend beaucoup de l'OS du serveur (Linux a l'air moins gourmand).

J'ai donc utilise cette solution qui marche sur mon sserveur de dev, mais ca me gene un peu d'empecher un utilisateur d'obtenir son image sous pretexte que sur certains OS il n'y aurait pas assez de memoire (ou pire, de planter si l'application tourne sous un OS qui consomme plus...).

C'est quand meme un peu bancal que imagecreatetruecolor() fasse une Fatal Error quand elle n'a pas assez de memoire, non ? Pourquoi ne pas simplement renvoyer false ou lever une exception ?

Est-ce qu'il n'y a vraiment aucun moyen "propre" de traiter ce cas ?

Eric
"Protégez les arbres, mangez du castor."

Hello,

d'autant plus que ce n'est pas imagecreatetruecolor() qui provoque cette erreur, pas réellement : c'est une erreur générique, dès qu'un traitement php dépasse la limite de mémoire qui lui est allouée.
Il est normal que cela génère une erreur fatale : php n'a PLUS de mémoire pour faire quoi que ce soit, donc pas même t'autoriser à intercepter une exception.
Maintenant, il est clair que PHP et la gestion de la mémoire, c'est un problème. Mais PHP est un langage de script, pas un langage applicatif, ne l'oublions pas.
Quant à l'OS...de tte manière, ton appli web tournera sur l'OS de TON serveur, quel que soit l'utilisateur. Donc si tu trouves une parade sur l'OS de ton serveur, tu n'as pas à t'en faire pour tes utilisateurs.
Maintenant, non, je ne pense pas non plus qu'il y ait de solution miracle. A toi de déterminer si la taille d'une image permettra à ton appli web de travailler ou pas, et d'en avertir ton utilisateur. Le but est d'agir AVANT l'erreur fatale, afin d'avoir quelque chose de propre. Mais tu ne pourras pas permettre à tes utilisateurs de faire n'importe quoi : en informatique, ça, ça n'existe pas de toute manière. Essaye de travailler une image pesant  1 To avec Photoshop sur ton dual core ayant 2Go de RAM et un DD de 320 Go...tu peux toujours courir. Il y aura toujours des limitations.
Simplement, elles reculeront au fil du temps. Comme tjrs en informatique depuis des 10aines d'années.

"Mais PHP est un langage de script, pas un langage applicatif, ne l'oublions pas."
quand tu fais ton site en php, t'aimes bien pouvoir faire ton script cron en php aussi...

ça reste un cron qui lan,ce un script, et non un cron qui lance une application; je ne vois pas où tu veux en venir?

sur un site, generalement, tu peux consomer beaucoup de memoire, vu que tu la rends tout de suite, c'est pas trop trop grave... sur un script (ou application, sous linux, on ne fait pas trop la difference...), c'est different...

la recommandation GNU indique qu'on doit preferer consommer de la ram que du CPU, mais si tu bouffes 4 go de ram, alors ca commence a "sucer a mort"... je crois qu'on peut meme dire que tu tues ton script...

et pourtant, faire un cron qui liste tout les comptes d'un site pour faire un calcul, et updater une table en faisant 100 000 requetes, ca se fait... alors la question c'est : est-ce-que c'est accessible en php ? ou doit-on faire du perl (pour rester dans la meme gamme de code), ou doit-on pousser jusqu'au code C ou ocaml ?

pour un langage qui se compile en bytecode, je crois qu'on peut dire que php suce clairement... il n'implemente pas le tail rec, il consome trois fois trop de ram (qu'il en consomme plus, vu son ramasse miette, ok, mais de la a en consommer trois fois trop...) et il est franchement lent... autant qu'un interprete pur d'ailleur...

pour les images, vu que c'est GD (donc du C) qui rince, ca reste a peu pres normal. Mais place 2^20 integers en memoire... t'auras beaucoup plus de 4 mo de consommes...