[PHP / GD Library] Image uit DB resizen?

[Verwijderd]

Ik wil graag een plaatje uit een database inlezen, resizen naar het formaat die ik via GET argumenten mee geef en deze vervolgens weergeven. Het gaat hierbij altijd op JPEG plaatjes.

code:

<?php
   require ("../config.php");
   mysql_connect ($db_server, $db_user, $db_password);
   mysql_select_db ($db_database);

   if ($size == 3)
      $res_photo = mysql_query ("SELECT photo1 AS photo FROM 
      producten WHERE id = $id");

   if ($row_photo = mysql_fetch_array($res_photo))
      $photo = $row_photo["photo"];

   header ('Content-Type: image/jpeg');
   echo $photo;
?>

Dit werkt weer perfectm dus geen problemen. Alleen nu moet ik gaan kijken naar het resizen. Omdat de plaatjes geen vaste verhouding hebben wilde ik eerste de breedte en de hoogte van het plaatje opvragen. Echter na het toevoegen van "$width = imagesx($photo);", schiet ie al in de hik, en krijg ik een mooi kruisje ipv een plaatje. De syntax is volgens mij gewoon goed. Ik ben dus nog niet begonnen met het resizen zelf, omdat het script hier al mee spaak loopt. Weet iemand wat ik fout doe? Want zoals gezegd moet het volgens de syntax wel kloppen.

Bedankt!

[ Voor 8% gewijzigd door Verwijderd op 14-08-2004 14:54 ]

[PrisonerOfPain]

imagesx() verwacht een handle naar de afbeelding, niet de afbeelding zelf.

[Verwijderd]

Hoe realiseer je dit dan? Want:

code:

$im = imagecreatefromjpeg($photo);

werkt niet, want deze functie verwacht een filename ipv een "plaatje in een variabele" zeg maar...

[crisp]

wat is het voordeel van plaatjes opslaan in een database in plaats van opslaan op een filesystem?

[gorgi_19]

crisp schreef op 14 augustus 2004 @ 15:30:
wat is het voordeel van plaatjes opslaan in een database in plaats van opslaan op een filesystem?

Je kan een relatie afdwingen tussen je databasegegevens in je plaatje, waarbij je niet moeilijk hoeft te doen met terugzetten van backups (verschil in FS / DB) of je plaatjes 'in gelijkenis' houden met de rest van je gegevens in je database.

[crisp]

gorgi_19 schreef op 14 augustus 2004 @ 15:33:
[...]

Je kan een relatie afdwingen tussen je databasegegevens in je plaatje, waarbij je niet moeilijk hoeft te doen met terugzetten van backups (verschil in FS / DB) of je plaatjes 'in gelijkenis' houden met de rest van je gegevens in je database.

Dat kan een afweging zijn, maar dan moeten je plaatjes wel 'statisch' zijn om problemen zoals de TS heeft te voorkomen -> TS moet volgens mij om zijn probleem op te lossen eerst weer een bestand maken waarop hij de GD functies los kan laten.
Een filesystem is volgens mij toch de meest logische keuze om bestanden op te slaan, daar is het immers voor gemaakt

[gorgi_19]

crisp schreef op 14 augustus 2004 @ 15:39:
Een filesystem is volgens mij toch de meest logische keuze om bestanden op te slaan, daar is het immers voor gemaakt

Interessante discussie; maar dit hoeft niet per definitie het geval te zijn.
Statische plaatjes (onderdeel van een template) opslaan op een FS: helemaal mee eens.

Dynamische plaatjes, zoals een image gallery / avatars zie ik geen probleem bijvoorbeeld mee om op te slaan in een DB. Performanceprobleem is te ondervangen door deze in memory te cachen; het zou me niets verbazen dat dit sneller kan zijn dan plaatjes van het FS af halen.

Eerlijkheidshalve: een goed argument tegen is dat ik geen idee heb hoe goed PHP is in caching voor dit soort grappen en databaseruimte duurder is dan webspaceruimte

Dat kan een afweging zijn, maar dan moeten je plaatjes wel 'statisch' zijn om problemen zoals de TS heeft te voorkomen -> TS moet volgens mij om zijn probleem op te lossen eerst weer een bestand maken waarop hij de GD functies los kan laten.

* gorgi_19 heeft geen idee wat al die PHP functies allemaal kunnen..

*************
Op experts exchange staat hier wel eea over beschreven, zie deze vraag In de antwoorden, vooral wat verder onderaan, wordt het ook behandeld.

[ Voor 42% gewijzigd door gorgi_19 op 14-08-2004 15:49 ]

[SuperRembo]

Verwijderd schreef op 14 augustus 2004 @ 15:19:
Hoe realiseer je dit dan? Want:

code:

$im = imagecreatefromjpeg($photo);

werkt niet, want deze functie verwacht een filename ipv een "plaatje in een variabele" zeg maar...

Volgens de handleiding zou het zo moeten kunnen (niet getest)

code:

$im = imagecreatefromstring($photo);

[Wolf87]

probeer is of dit werkt, dit gebruik ik meestal om de breedte van plaatjes te weten

code:

list($width, $height, $type, $attr) = getimagesize($photo);

[ Voor 5% gewijzigd door Wolf87 op 14-08-2004 19:46 ]

[Verwijderd]

Volgens de handleiding zou het zo moeten kunnen (niet getest)

code:

$im = imagecreatefromstring($photo);

Nee dit wil ook niet werken.. het is raar, want als ik dus $photo echo dan staat het plaatje gewoon op me scherm, dus die variabele bestaat puur uit de "inhoud" van het Jpeg plaatje... dit moet dan toch in te laden zijn, en met handlers e.d., kan me niet voorstellen dat ik de enigste ben die probeert een plaatje uit een DB te bewerken

Het gaat trouwens om een kleine webwinkel, en elk plaatje moet in 3 varianten worden getoond aan de bezoeker... en er hangen dus ook andere gegevens aan vast, prijzen, omschrijvingen etc. Opslaan in DB leek mij het makkelijkst / het snelst... Ik zoek ook nog even door, maar mochten er nog mensen zijn met suggesties

[NMe]

Kun je GD niet "voor de gek houden"? Dan creëer je een plaatje op basis van een ander script. Maak dus een pagina, die zoals hierboven het hele plaatje output. Op een andere pagina doe je dan dit:

PHP:

imagecreatefromjpeg("phpbestand.php");

Op die manier kun je volgens mij wel al je GD functies erop loslaten.

[ripexx]

NMe84 schreef op 14 augustus 2004 @ 19:34:
Kun je GD niet "voor de gek houden"? Dan creëer je een plaatje op basis van een ander script. Maak dus een pagina, die zoals hierboven het hele plaatje output. Op een andere pagina doe je dan dit:

PHP:

imagecreatefromjpeg("phpbestand.php");

Op die manier kun je volgens mij wel al je GD functies erop loslaten.

Je moet dan wel het php bestand via apache laten benaderen dus via een url anders zie je op file system niveau alleen de code

[NMe]

ripexx schreef op 14 augustus 2004 @ 19:43:
[...]


Je moet dan wel het php bestand via apache laten benaderen dus via een url anders zie je op file system niveau alleen de code

Mjah, niet aan gedacht. Maar tis een mogelijkheid.

[SuperRembo]

Dit werkt, en het zou ook moeten werken als $data uit een database komt.

PHP:

$filename = 'test.png';
$img = imagecreatefrompng($filename);

// (resize)

ob_start();
imagejpeg($img);
$data = ob_get_contents();
ob_end_clean();

// ($data -> database, database -> $data)

$img2 = imagecreatefromstring($data);
imagepng($img2);

[MBV]

het klinkt toch of het een string is: als het geen string is wat in je var zit moet je imagejpeg() gebruiken namelijk. Ik stem voor imagecreatefromstring()

Kijk eens wat er 'achter' het kruisje zit. Dan zie je namelijk de foutmelding. Simpelste daarvoor is gewoon header() weghalen.

[Erkens]

MBV schreef op 14 augustus 2004 @ 23:42:
Kijk eens wat er 'achter' het kruisje zit. Dan zie je namelijk de foutmelding. Simpelste daarvoor is gewoon header() weghalen.

Daar hebben ze nu logfiles voor uitgevonden

[gorgi_19]

gorgi_19 schreef op 14 augustus 2004 @ 15:42:
Op experts exchange staat hier wel eea over beschreven, zie deze vraag In de antwoorden, vooral wat verder onderaan, wordt het ook behandeld.

^^^
Hier staat oa ook nog een heel voorbeeldscript, welke met de meeste typen voldoen

[ Voor 12% gewijzigd door gorgi_19 op 15-08-2004 00:08 ]

[Verwijderd]

crisp schreef op 14 augustus 2004 @ 15:39:Een filesystem is volgens mij toch de meest logische keuze om bestanden op te slaan, daar is het immers voor gemaakt

Een filsystem is een database .

gorgi_19 schreef op 14 augustus 2004 @ 15:42:
Performanceprobleem is te ondervangen door deze in memory te cachen; het zou me niets verbazen dat dit sneller kan zijn dan plaatjes van het FS af halen.

Performanceverlies door opslaan in een db is een myte. Een rdbms is ge-optimaliseerd om data snel te zoeken en terug te geven (index\caching), dus een goed geconfigureerde rdbms kan sneller zijn dan een filesystem.

[Erkens]

Verwijderd schreef op 16 augustus 2004 @ 11:27:
Performanceverlies door opslaan in een db is een myte. Een rdbms is ge-optimaliseerd om data snel te zoeken en terug te geven (index\caching), dus een goed geconfigureerde rdbms kan sneller zijn dan een filesystem.

maar waar slaat een rdbms zijn data op? juist toch weer op het filesystem

[djluc]

Erkens schreef op 16 augustus 2004 @ 11:36:
[...]maar waar slaat een rdbms zijn data op? juist toch weer op het filesystem

Niet helemaal het verband weghalen: een deel caching in het geheugen van o.a. indices is ook nog aanwezig.

Overigens heb ik nog niet veel echte goede tests gezien over de performance verschillen. Enige beargumenteerde stelling die ik heb kunnen vinden was:

Je creeërd extra overhead omdat je bij iedere afbeeldingsopvraag contact moet zoeken met de database enzovoorts. Terwijl je bij een filesystem een rechtstreekse aanroep naar de webserver kan doen welke de taak vervolgens zelf af kan handelen.

[ Voor 41% gewijzigd door djluc op 16-08-2004 12:42 ]

[Erkens]

djluc schreef op 16 augustus 2004 @ 12:39:
[...]
Niet helemaal het verband weghalen: een deel caching in het geheugen van o.a. indices is ook nog aanwezig.

Overigens heb ik nog niet veel echte goede tests gezien over de performance verschillen. Enige beargumenteerde stelling die ik heb kunnen vinden was:

Je creeërd extra overhead omdat je bij iedere afbeeldingsopvraag contact moet zoeken met de database enzovoorts. Terwijl je bij een filesystem een rechtstreekse aanroep naar de webserver kan doen welke de taak vervolgens zelf af kan handelen.

dat is dus precies wat ik bedoel
maar idd, heb er zelf ook nog geen goede tests van gezien, wel heb ik het zelf eens geprobeerd en toen kwam er uit dat files sneller waren dan uit de db, maarja, dat kan best aan de door mij gebruikte server/code liggen

Overigens cached "het filesystem" ook hoor, en is er ook een index zodat een file snel terug gevonden kan worden. Daarnaast denk ik dat een database server niet al die grote plaatjes gaat cachen. Dus je maakt een verbinding naar de DB, waar je je plaatje opvraagt, DB gaat het plaatje zoeken, en stuurt de gegevens terug via die verbinding, ipv rechtstreeks die file laden.

[ Voor 18% gewijzigd door Erkens op 16-08-2004 12:53 ]

[frickY]

MyIsam (meest gebruikte type onder MySQL) tabellen zijn erop gebouwd cijfertjes of zelfs tekst terug te geven. Binaire gegevens worden ondersteund, maar zijn ze niet het sterkst in.
Ikzelf ben er dan ook van overtuigd dat het dom is om je plaatjes als binaire gegevens in je MyIsam tabel te kwakken. Ikzelf save ze altijd in een subfolder waarvan de naam het productID is.

Als imagefromstring() niet werkt.. zou ik je GD-versie eens nakijken.