Memory_limit GD-lib
Jimmy skov Adetunji
p� de billeder der bliver uploaded til et webhotel, men det er
som om at nogle billeder er for store til at blive behandlet.
Jeg har webhotel hos one.com
deres memory_limet er 32mb
og 16mb gennem php
De billeder der giver problemer har ikke en st�rrelse der
overstiger 4mb. Kan det have noget at g�re med antal pixels?
Venligst
jimmy Adetunji
--
Vil du l�re at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- P�dagogiske tutorials p� dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
Peter Farsinsen
> Jeg bruger gd-lib kommando til gennem php at �ndre dimmensionerne
> p� de billeder der bliver uploaded til et webhotel, men det er
> som om at nogle billeder er for store til at blive behandlet.
> Jeg har webhotel hos one.com
> deres memory_limet er 32mb
> og 16mb gennem php
>
> De billeder der giver problemer har ikke en st�rrelse der
> overstiger 4mb. Kan det have noget at g�re med antal pixels?
St�rrelsen i mb har vist ikke s� meget at sige. Du kan sjusse dig frem
til, hvor meget hukommelse GD bruger p� at �bne et billede ved at finde
antallet af pixels (h*w) og gange det med 4 (en byte for hhv. r, g, b og
og alpha-kanalen).
Et billede p� 1280*1024 tager ca. 5mb.
((1280*1024)*4)/1048576 = 5mb
Hvis du �bner flere canvas, glemmer at rydde op etc. har du hurtigt
brugt dine 16mb.
Har One ImageMagick (http://php.net/manual/en/book.imagick.php)?
- Peter
Birger Sørensen
> Jimmy skov Adetunji wrote:
>> Jeg bruger gd-lib kommando til gennem php at ï¿œndre dimmensionerne
>> pￜ de billeder der bliver uploaded til et webhotel, men det er
>> som om at nogle billeder er for store til at blive behandlet.
>> Jeg har webhotel hos one.com
>> deres memory_limet er 32mb
>> og 16mb gennem php
>>
>> overstiger 4mb. Kan det have noget at gï¿œre med antal pixels?
>
> Stￜrrelsen i mb har vist ikke sￜ meget at sige. Du kan sjusse dig frem til,
> hvor meget hukommelse GD bruger pￜ at ￜbne et billede ved at finde antallet
> alpha-kanalen).
>
>
> ((1280*1024)*4)/1048576 = 5mb
>
> Hvis du ï¿œbner flere canvas, glemmer at rydde op etc. har du hurtigt brugt
Hvis billedet kun bruger 4 farver, er eksemplet rigtigt.
h*w*farvedybde er mere i retning af det rigtige.
Dette fordi, PHP nï¿œr man arbejder med billeder, skal bruge et bitmap -
.bmp - PHP kan ikke regne pￜ komprimerede billeder.
Og til det brug, er one.com slet ikke brugbart. Sￜ der skal enten
skiftes hotel, eller findes et bibliotek, der kan det der er brug for,
uden at overskride de 16Mb.
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk
Jimmy skov Adetunji
filst�rrelsen i mb, som er problemet. T�nker at det nok er den m�de jeg �ndre
st�rrelsen p� billederne. Som n�vnt er det kun nogle billeder der ikke kan vises.
Det skal n�vnes at alle billederne uploades til mappen, men nogle kan alts� ikke
blive omd�bt og skaleret. Siden er at find her: www.skjold-foto.dk/uploader4.php
Jeg inds�tter den relevante del nedenfor:
<?php
if (array_key_exists('btn', $_POST))
{
// DENNE AFSLUTTES I LINE 224
$filename = $_FILES ['frmfile']['name'];
$imageSize = getimagesize('images/'.$filename);
list($bredde, $hojde) = $imageSize; //Find hjden og bredden p� det billede jeg
vil resize
if ($hojde>$bredde) $stforhold = $hojde/$bredde;
else $stforhold = $bredde / $hojde;
$hight_percent = round ($hojde* 0.01);
$width_percent = round ($bredde * 0.01);
if ($hight_percent<$width_percent)
{
$max_width = 440 * $stforhold;
$max_hight = 440;
}
elseif ($hight_percent>$width_percent)
{
$max_width = 295;
$max_hight = 295 * $stforhold;
}
$hight_cal = $hight_percent * $stforhold;
while ($hight_cal < $max_hight)
{
$hight_cal++;
$hojde_ny=$hight_cal;
}
$width_cal = $width_percent * $stforhold;
while ($width_cal < $max_width)
{
$width_cal++;
$bredde_ny=$width_cal;
}
?>
<?
/*
Array ( [frmfile] => Array ( [name] => 200181513-001.jpg [type] => image/jpeg
[tmp_name] => /tmp/phpI4MqtO [error] => 0 [size] => 2482 ) )
*/
$pattern1 = "/.jpg/";
$pattern2 = "/.gif/";
$pattern3 = "/.png/";
$pattern4 = "/.tif/";
//INDLSES DET ORIGINALE BILLED OG ET TOMT MED DEN NYE ST�RRELSE
if (preg_match($pattern1, $filename))
{
$source = imagecreatefromjpeg("images/".$filename);
$destination = imagecreatetruecolor(round ($bredde_ny), round($hojde_ny));
imagecopyresampled($destination, $source, 0, 0, 0, 0, round ($bredde_ny), round
($hojde_ny), round($bredde), round($hojde));
$find = array("�", "�", "�", "�", "�", "�", " ");
$erstat = array("ae", "Æ", "oe","Ø","aa","Å", "_");
$new_file_name = "ny".$filename;
$new_file_name = str_replace($find, $erstat, $new_file_name); // S�tter
variablen besked til den v�rdi man har skrevet OG erstatter �, � og � med deres
korrekte
//v�rdier.
//DER LAVES TO "IMAGEJPEG" FOR AT BILLEDGALLERIET B�DE HAR EN VERSION I "THUMBS"
OG "IMAGES"
imagejpeg($destination, 'images/thumbs/'.$new_file_name);
imagejpeg($destination, 'images/'.$new_file_name);
unlink("images/$filename"); //Den oprindelige fil slettes for at spare plads p
server
Bertel Lund Hansen
> Jeg har unders�gt det lidt n�rmere og er overbevist om at det ikke er
> filst�rrelsen i mb, som er problemet. T�nker at det nok er den m�de jeg �ndre
> st�rrelsen p� billederne.
Jeg har lavet et skaleringsskript som jeg bruger i flere
sammenh�nge. Det skalerer relativt store billeder uden at jeg er
l�bet ind i problemer (endnu). Scriptene k�rer p� mit webhotel
hos Gigahost.
Her er min demoside:
http://bertel.lundhansen.dk/webdesign/diasshow.php
og p� den er der links til visning af koden samt en zipfil med
det hele i undtagen billederne.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
Stig Johansen
> Jeg har unders�gt det lidt n�rmere og er overbevist om at det ikke er
> filst�rrelsen i mb, som er problemet.
Som Birger skriver, s� er det ikke filst�rrelsen (alene) der er afg�rende,
men den bitmap der skal bruges til at manipulere billedet.
Med den indstilling jeg har p� mit kamara, produceres billeder med en
opl�sning p� 2592x1944.
Filen (jpg) i sig selv fylder 2-3 mb afh�ngig af ensartetheden i indholdet.
S� initielt skal du bruge 2-3 mb (din post variable), og her skal genereres
et workspace(bitmap) p� 2592x1944x32 bit= ca. 19,2 mb.
Dvs et mindsteforbrug p� 21-22 mb, og hertil skal du l�gge st�rrelsen af
output bitmappen til - i dit tilf�lde ca 0,75 mb.
S� alt i alt skal du bruge ca. 23 mb selvom _filst�rrelsen_ kun er et par
mb.
Men pr�v at unders�ge om ikke der er en sammenh�ng mellem pixelst�rrelsen og
dit memoryforbrug.
--
Med venlig hilsen
Stig Johansen
Jimmy skov Adetunji
Mange tak for din henvisning. Det er jo pr�cis det resultat jeg gerne vil opn�.
Jeg m� lige tygge mig igennem det hele og arbejde med at passe det ind.
forestiller mig egentlig at det er noget med at jeg implementere kommandoen der
angiver den maksimale st�rrelse for en enkelt af billedet sider. i stedet for den
noget kringlede udregning jeg laver pt.
Skulle der v�re andre bud p� hvad der konkret er galt med m�den jeg har lavet min
kode p�, er jeg meget interesseret, da det jo er p.. irriterende, n�r man ikke kan
gennemskue hvorfor noget virker i langt de fleste tilf�lde men alligevel til tider
fejler.
Stig Johansen
> Skulle der v�re andre bud p� hvad der konkret er galt med m�den jeg har
> lavet min kode p�, er jeg meget interesseret, da det jo er p..
> irriterende, n�r man ikke kan gennemskue hvorfor noget virker i langt de
> fleste tilf�lde men alligevel til tider fejler.
L�s mit andet svar.
Jeg kender ikke s� meget til PHP, men v�r opm�rksom p� at memory f�rst
bliver frigivet n�r GC (Garbage collector) synes det er passende.
M�ske kan nogle PHP hajer byde ind p� om det er muligt at tvinge en
frigivelse igennem, frem for at vente p� at memory g�r ud af scope.
Peter Farsinsen
>> Skulle der v�re andre bud p� hvad der konkret er galt med m�den jeg har
>> lavet min kode p�, er jeg meget interesseret, da det jo er p..
>> irriterende, n�r man ikke kan gennemskue hvorfor noget virker i langt de
>> fleste tilf�lde men alligevel til tider fejler.
Jeg er stadigv�k overbevist om, at srciptet d�r fordi der bruges for
meget hukommelse. Jimmy, outputter du fejlmeddelelser, s� du kan se om
PHP snakker til dig?
> L�s mit andet svar.
> Jeg kender ikke s� meget til PHP, men v�r opm�rksom p� at memory f�rst
> bliver frigivet n�r GC (Garbage collector) synes det er passende.
>
> M�ske kan nogle PHP hajer byde ind p� om det er muligt at tvinge en
> frigivelse igennem, frem for at vente p� at memory g�r ud af scope.
Ja, imagedestroy($img); smider et billede v�k.
Konkret kan det bruges til at smide $source v�k her:
$source = imagecreatefromjpeg("images/".$filename);
$destination = imagecreatetruecolor(round ($bredde_ny), round($hojde_ny));
imagecopyresampled($destination, $source, 0, 0, 0, 0, round
($bredde_ny), round
($hojde_ny), round($bredde), round($hojde));
// Smid source v�k og frigiv hukommelsen
imagedestroy($source);
Kig ogs� p� memory_get_usage(); det kunne v�re en m�de at finde ud af,
hvor meget ram der rent faktisk bliver brugt.
- Peter
Jimmy skov Adetunji
> Stig Johansen wrote:
> >> Skulle der v�re andre bud p� hvad der konkret er galt med m�den jeg har
> >> lavet min kode p�, er jeg meget interesseret, da det jo er p..
> >> irriterende, n�r man ikke kan gennemskue hvorfor noget virker i langt de
> >> fleste tilf�lde men alligevel til tider fejler.
>
> Jeg er stadigv�k overbevist om, at srciptet d�r fordi der bruges for
> meget hukommelse. Jimmy, outputter du fejlmeddelelser, s� du kan se om
> PHP snakker til dig?
>
jeg om det? ligesom mysql (or die mysql_error())?
Jimmy skov Adetunji
Det m� jeg jo nok bare leve med s�
Jimmy skov Adetunji
Jeg har afpr�vet dit system og sjovt nok kan det heller ikke behandle de billeder
som mit eget ikke kan behandle.
Jeg t�nker at forklaringen m� ligge i det Stigs indl�g.
Hilsen og tak
jimmy Adetunji
Birger Sørensen
> Stig Johansen wrote in dk.edb.internet.webdesign.serverside.php:
>> Men prï¿œv at undersï¿œge om ikke der er en sammenhï¿œng mellem pixelstï¿œrrelsen og
> Det giver ganske god mening for mig det du skriver.
eller finde en host, der tillader brug af nok RAM.
Helt prï¿œcist er det formentlig i linien
$source = imagecreatefromjpeg("images/".$filename);
problemet opstï¿œr - der oprettes et bitmap (ikke komprimeret) kopi af
det originale billede - og det er der ikke RAM til hos one.com.
(Jeg har selv prￜvet hos one.com - ogsￜ at fￜ mere RAM til rￜdighed -
og de er/var hverken til at hugge eller stikke i)
Jimmy skov Adetunji
> Helt pr�cist er det formentlig i linien
Har ogs� vv�ret i kontakt med dem og erfaret det samme, men der er jo en grund til
at prisen kan holdes ned. Jeg har brugt dem i mange �r og er generelt glad for
deres servicer s� jeg lever med det.
tak for pr�ciseringen.
jimmy
Peter Farsinsen
> Har ogs� vv�ret i kontakt med dem og erfaret det samme, men der er jo en grund til
> at prisen kan holdes ned. Jeg har brugt dem i mange �r og er generelt glad for
> deres servicer s� jeg lever med det.
> tak for pr�ciseringen.
Har du unders�gt om det underst�tter ImageMagick? Det er min erfaring at
det bruger langt f�rre ressourcer end GD (og det er meget lettere at bruge).
- Peter
Peter Farsinsen
>> Jeg er stadigv�k overbevist om, at srciptet d�r fordi der bruges for
>> meget hukommelse. Jimmy, outputter du fejlmeddelelser, s� du kan se om
>> PHP snakker til dig?
>>
> Jeg har netop t�nkt at jeg skulle f� php til at "snakke lidt". hvordan beder
> jeg om det? ligesom mysql (or die mysql_error())?
Kig p� error_reporting(); og display_errors(); p� php.net ;)
- Peter
Jimmy skov Adetunji
>
> Har du unders�gt om det underst�tter ImageMagick? Det er min erfaring at
> det bruger langt f�rre ressourcer end GD (og det er meget lettere at bruge).
>
Det er jeg faktisk kommet v�k fra igen, men vil da lige kigge p� sagen.
Tak for p�mindelsen
Jimmy skov Adetunji
Det er der desv�rre ikke mulighed for gennem one.com