[php]wél getimagesize, imagecreatefromjpeg not valid

[Verwijderd]

Met mijn script haal ik een afbeelding van een http:// adres naar mijn webserver, dat gaat allemaal prima:

code:

//afbeelding openen:
$fp = fopen($_POST["url"], "r"); 
$afbeelding = fread ($fp, 3000000); 
fclose($fp); 
     
//temp bestandje maken
$temp_naam = tempnam ($GLOBALS["DOCUMENT_ROOT"]."/afbeeldingen", "IMG"); 
     
//afbeelding in het tempbestandje schrijven
$fp = fopen($temp_naam, "w"); 
fwrite($fp, $afbeelding); 
fclose($fp);

so far, so good. Om te kijken wat voor afbeelding $temp_naam is gebruik ik "getimagesize", die netjes aangeeft:

code:

Array ( [0] => 404 [1] => 290 [2] => 2 [3] => width="404" height="290" [bits] => 8 [channels] => 3 [mime] => image/jpeg )

vervolgens wil ik nog het een en ander met het plaatje doen, waarvoor ik in dit geval gebruik:

code:

$im = imagecreatefromjpeg($temp_naam);

Nu geeft php de waarschuwing:

code:

Warning: imagecreatefromjpeg()[function.imagecreatefromjpeg]: 'C:\xampplite\htdocs\afbeeldingen\IMG6394.TMP' is not a valid JPEG file on ...etc .

Dat is toch raar, omdat getimagesize() geen fouten geeft op hetzelfde bestand. Ook wanneer ik de overgezette afbeelding open in bijv. photoshop is de foto prima.

de volgende dingen heb ik inmiddels geprobeerd:
- renamen .TMP naar jpg
- alles in kleine- / alles in hoofdletters
- andere afbeeldingen kiezen

steeds komt deze fout. iemand ideeen?

EDIT:
vanaf php 4.3.0 (windows) is het mogelijk om direct met imagecreatefromjpeg een url te benaderen, gek genoeg geeft dit geen fouten..! Weet iemand wat er fout zit in bovenstaand script? Dan kan ik het ook voor <4.3.0 servers werkend maken..

[ Voor 14% gewijzigd door Verwijderd op 03-09-2004 12:10 ]

[NMe]

Wat doet de functie tempnam in je code? Ik neem aan dat die de bestandsnaam in een gewenst formaat teruggeeft? Waarom zorg je er niet voor dat dat formaat relatief is aan het pad waar het script in runt? Dan zou imagecreatefromjpeg() gewoon moeten werken.

[Soultaker]

Onder Windows moet je je bestand misschien lezen met 'rb' file mode in plaats van 'r'?

Overigens zit getimagesize() in de EXIF library en imagecreatefromjpeg() in de GD library, dus het is niet heel vreemd dat die twee functies zich anders gedragen. Bovendien hoeft de EXIF library alleen maar wat metadata (headers) uit te lezen en is de kans groot dat 'ie allerlei inhoudelijke fouten mist.

[Verwijderd]

NMe84 schreef op 03 september 2004 @ 13:28:
Wat doet de functie tempnam in je code? Ik neem aan dat die de bestandsnaam in een gewenst formaat teruggeeft?

tempnam is een php functie voor het maken tijdelijk bestandje met een unieke naam. Het 1e argument is de locatie, het 2e argument is een prefix voor je bestandsnaam.

NMe84 schreef op 03 september 2004 @ 13:28:
Waarom zorg je er niet voor dat dat formaat relatief is aan het pad waar het script in runt? Dan zou imagecreatefromjpeg() gewoon moeten werken.

Ik begrijp niet precies wat je bedoelt, maar relatief (.../afbeelding) werkt het ook niet. Het lijkt wel alsof met het schrijven van het temp-bestandje bepaalde informatie verloren gaat, waardoor imagecreatefromjpeg() erover struikelt.

ook het lezen van de file in "rb" of schrijven van de file in "wb" (heb ik ook ff geprobeerd) werkt helaas niet.

[pjonk]

Ik vind de volgende regel nogal gevaarlijk:

PHP:

$afbeelding = fread ($fp, 3000000);

Waarom lees je niet de file niet in een buffertje van bijvoorbeeld 4 KB, bijvoorbeeld:

PHP:

$afbeelding = '';
while (!feof($fp)) {
  afbeelding .= fgets($fp, 4096);
}

[ Voor 5% gewijzigd door pjonk op 03-09-2004 15:32 . Reden: PHP tags toegevoegd ]

[Verwijderd]

JonkieXL schreef op 03 september 2004 @ 15:31:
Waarom lees je niet de file niet in een buffertje van bijvoorbeeld 4 KB..

Ja, waarom ook eigenlijk niet ..? Want nu doet hij het wel! Hartelijk dank!

[LuCarD]

fread leest streams per pakketje in. En stopt dus na het eerste pakketje!

zie http://www.php.net/fread

[Verwijderd]

Ja, ik zie het nu ja.. Had fread() wel meer gebruikt maar dan lokaal en dan werkt het anders zo blijkt:

Als er gelezen wordt vanaf netwerk streams of pipes, zoals bij remote files of popen() of proc_open(), wordt het lezen gestopt als er een pakketje aanwezig is. Dit betekent dat je zelf alle data bij elkaar in blokken moet verzamelen zoals in het voorbeeld hier beneden.

nogmaals bedankt voor alle hulp!

[Verwijderd]

Voor het openen van files (en zeker remote files), zou ik altijd get_file_contents() gebruiken. Je hebt dan een mooie ondeelbare actie: òf het lezen is goed gegaan (en je hebt de hele file in één keer), of het is niet goed gegaan, en dan heb je niks.

Je hoeft je dan niet bezig te houden met pakketjes, een verbinding die halverwege wegvalt, etc. En, omdat deze functie in zijn geheel in C is geïmplementeerd, is het (waarschijnlijk) nog eens sneller dan een lusje in PHP ook.

[Soultaker]

Verwijderd schreef op 04 september 2004 @ 13:30:
Voor het openen van files (en zeker remote files), zou ik altijd get_file_contents() gebruiken. Je hebt dan een mooie ondeelbare actie: òf het lezen is goed gegaan (en je hebt de hele file in één keer), of het is niet goed gegaan, en dan heb je niks. Je hoeft je dan niet bezig te houden met pakketjes, een verbinding die halverwege wegvalt, etc.

Dat is een nuttig advies.

En, omdat deze functie in zijn geheel in C is geïmplementeerd, is het (waarschijnlijk) nog eens sneller dan een lusje in PHP ook.

Dat is nogal een onzinargument, tenzij je ontzettend kleine buffers gebruikt en lokale bestanden leest (de overhead van een internet verbinding is gigantisch). Dan kun je ook wel aan C-programmeurs aanraden om in assembly te gaan programmeren voor die paar clockcycles.

Kortom: ik vind file_get_contents() ook een goede suggestie, maar niet vanwege de mogelijke verbeterde performance.

[ Voor 14% gewijzigd door Soultaker op 04-09-2004 19:42 ]

[Verwijderd]

Okee, ik zal het maandag gelijk proberen.

Kunnen ze bij php niet eens wat funties gaan schrappen? Er zijn nu een heel reut functies die min of meer hetzelfde doen, waarbij de een net iets beter is dan de ander (?), dat maakt het niet echt overzichtelijk..

[NMe]

Verwijderd schreef op 05 september 2004 @ 14:44:
Okee, ik zal het maandag gelijk proberen.

Kunnen ze bij php niet eens wat funties gaan schrappen? Er zijn nu een heel reut functies die min of meer hetzelfde doen, waarbij de een net iets beter is dan de ander (?), dat maakt het niet echt overzichtelijk..

Ken je de uitdrukking 'backwards compatibility'?

Bovendien heeft elke functie zo zijn voordelen. Zo is bijvoorbeeld str_replace snel, en preg_replace uitgebreider. Simpelweg str_replace schrappen omdat preg_replace beter is, is dus niet zo'n goed idee, er spelen meer factoren mee.

[Verwijderd]

Soultaker schreef op 04 september 2004 @ 19:41:
Dat is nogal een onzinargument, tenzij je ontzettend kleine buffers gebruikt en lokale bestanden leest (de overhead van een internet verbinding is gigantisch). Dan kun je ook wel aan C-programmeurs aanraden om in assembly te gaan programmeren voor die paar clockcycles.

Mjaaaaaahhh...

Ik gebruik het ook niet vanwege de performance (het gebruik is gewoon superfijn). Maar soms zijn mensen alleen niet te overtuigen met het argument dat het "netter" is. En diezelfde mensen luisteren vaak wel naar het argument dat het "sneller" is. Dus ik zeg het maar allebei .

Bij lokale files zal het waarschijnlijk wel (iets) uitmaken. Al ben ik nu te lui om te gaan benchmarken . En je hebt natuurlijk volledig gelijk dat het verschil bij een internetconnectie te verwaarlozen zal zijn.

[Verwijderd]

NMe84 schreef op 05 september 2004 @ 14:52:
[...]
Ken je de uitdrukking 'backwards compatibility'?

Yup, maar er zijn wel meer zaken in php die er langzaam maar zeker uitgaan.

Maargoed, file_get_contents() werkt prima en is inderdaad netjes, geen gedoe met filepointers etc. Goede tip!