Image data in img tag zetten

[Verwijderd]

Misschien beetje rare topic titel maar het zegt wel wat ik bedoel.

Een website die ik onderhoud is er een van het 'constant groeiende' type waarbij de database steeds uitgebreider wordt. Daarbij horen ook vaak kleine tot middelgrote graphics. Nu worden die graphics allemaal opgeslagen als bestandjes in een nette overzichtelijke folder structuur. Ondertussen bestaat die verzameling graphics al uit een 11.000 images. Daarom begin ik er over te denken ze allemaal als BLOB's mee in een table te gooien.

Nu vraag ik me af, is dit een goed idee ?

Indien ja, ik heb al zitten knutselen hoe ik dat het beste aanpak en de images in BLOB records gooien en dergelijke is geen probleem. Uitlezen ook niet. Maar in plaats van met headers te werken om de data uit te spuwen kwam ik ergens een <object >voorbeeldje tegen waarin men de data base64 encoded mee in de tag gooit. Nu blijkt deze manier van werken ook toepasbaar te zijn op een <img> tag.

Voorbeeldje wat ik bedoel :

PHP:

// $data komt uit het BLOB veldje
$data = base64_encode($data);
$str = '<img src="data:image/gif;base64,'.$data.'"';

En dit lijkt netjes te werken. Alleen, ik kan deze 'mogelijkheid' niet direct terugvinden op W3C of op andere plaatsen.

Dus mijn vraag, is dit een geldige, toegelaten manier van werken ? Of is dit een toevallig werkend iets ?

EDIT : blijkbaar al te snel geroepen want in IE lijkt het al niet (meer) te werken...

[ Voor 3% gewijzigd door Verwijderd op 16-09-2006 15:07 ]

[user109731]

Verwijderd schreef op zaterdag 16 september 2006 @ 14:57:
Dus mijn vraag, is dit een geldige, toegelaten manier van werken ? Of is dit een toevallig werkend iets ?

Jup, dat hoort te werken Heb je het ook getest in IE? Ik dacht dat het daarin niet werkte, maar ik kan het mis hebben.

Onder de tweede link hierboven vind je deze nadelen:

quote: http://en.wikipedia.org/wiki/Data:_URI_scheme

Disadvantages:
* Embedded content must be extracted and decoded before changes may be made, then re-encoded and re-embedded afterwards.
* Base64-encoded data: URIs are roughly 33% larger in size than their binary equivalent.
* URL-encoded data: URIs can be up to 200% larger (in extreme cases) than the original text content.
* Information that is embedded more than once is redownloaded as part of the containing file, and thus does not benefit from the browser's cache.
* Browser limits to URI length provide a maximum data size. For example, URIs in Opera used to have limit of 4kB.
* Data is included as a simple stream, and many processing environments (such as web browsers) may not support using containers

Dan is het beter om een php pagina te maken waar je de naam van een afbeelding aan meegeeft, en die de goede afbeelding voor je opzoekt en teruggeeft. Dat script kun je dan zo aanroepen:

HTML:

<img src="image.php?i=logo">

Eventueel kun je dat nog rewriten naar zoiets:

HTML:

<img src="images/logo">

Ik ben wel benieuwd naar de reden om alles in een database te zetten, als dit nu goed werkt?

[ Voor 38% gewijzigd door user109731 op 16-09-2006 15:30 ]

[Upsal]

Het is mogelijk, maar ik denk dat het af te raden is om afbeeldingen op te slaan in een database, een fysiek GIF/JPGje is een stuk makkelijk voor je server om te serveren. Vooral als je veel bezoekers krijgt, en je server hoger belast wordt, zul je dit merken.

Mocht je toch alles in een database willen opslaan, dan zou je jouw voorbeeldcode kunnen gebruiken, of (indien je PHP gebruikt) d.m.v. een PHP bestand dat de BLOB ophaalt en output. Dit in combinatie met een header("Content-Type: image/xxx");.

[Osiris]

Je moet ook denken aan dingen als cache: de meeste webservers (Apache wel iig) regelen de cache-issues voor static content zoals images en css-files allemaal prima: client stuurt request met wat extra headers, server geeft HTTP 302 terug om aan te geven dat de browser 't allemaal maar lekker uit z'n cache moet halen, 't bestand is niet veranderd.

Zodra je echter je static data via dynamische scripts zoals PHP gaat versturen, dan cachen browsers dat niet (logisch), dus vreet dat relatief gezien veel bandbreedte.

[Arjen Tempel]

Osiris schreef op zaterdag 16 september 2006 @ 15:13:
Zodra je echter je static data via dynamische scripts zoals PHP gaat versturen, dan cachen browsers dat niet (logisch), dus vreet dat relatief gezien veel bandbreedte.

Dat is op te lossen met wat extra logica in het PHP script dat je images toont:

PHP:

    if (isset($headers['If-Modified-Since']) && (strtotime($headers['If-Modified-Since']) == filemtime($fotofile))) {
       // Client's cache IS current, so we just respond '304 Not Modified'.
       header('Last-Modified: '.gmdate('D, d M Y H:i:s', filemtime($fotofile)).' GMT', true, 304);
       exit;
    } else {
       // Image not cached or cache outdated, we respond '200 OK' and output the image.
       header('Last-Modified: '.gmdate('D, d M Y H:i:s', filemtime($fotofile)).' GMT', true, 200);
    }

Ik vergelijk hier de cachetijd met de file modified tijd van de opgevraagde afbeelding, maar die tijd zou je ook uit een veld in je database kunnen halen.
Het resultaat: browsers cachen de afbeeldingen net zo goed als afbeeldingen die niet uit een PHP script komen.

[Verwijderd]

Ik gebruik voor plaatjes/andere bestanden altijd het filesystem, dit werkt stukken sneller dan een database. Je kan wel een link leggen van de database naar de bestandsnaam, en met de hierboven beschreven methode het bestand naar de gebruiker parsen. Je database kent toch het bestand bij naam (zodat je het kan koppelen aan objecten/rechten/whatever) en je hebt het voordeel dat de plaatjes niet in de database staan (wat traagheid van database EN gigantisch formaat van database tot gevolg heeft).
Dan daarbij horen bestanden op het filesystem, en data in een database. Bestanden horen niet in een database, enkel een record welk bestand het is, waar te vinden, enzovoort.

[Verwijderd]

Dus conclusie, ik laat het beter zoals het nu is. Werkt trouwens perfect.

Hartelijk dank voor de onderbouwing ook, stonden enkele interessante dingen tussen...

[crisp]

data-url's zijn inderdaad gedefinieerd in een standaard; RFC2397 om precies te zijn.
Hierboven zijn al wat nadelen hiervan opgenoemd, maar het grootste nadeel is het gebrek aan ondersteuning door IE. Er was vorig jaar sprake van dat IE7 wel support zou gaan bieden voor data: url's maar in RC1 werkt het vooralsnog niet dus ik denk dat dat op de lange baan is geschoven (en we weten allemaal wat dat betekend bij MS).

Overigens, de preview in mijn Crispy Paint maakt gebruik van data-url's met een workaround via een stukje javascript en een PHP scriptje om het ook in IE te laten werken. Helaas loop je dan weer snel tegen de beperkte max lengte aan voor URL's in IE...

[ Voor 25% gewijzigd door crisp op 17-09-2006 11:18 ]

[Verwijderd]

Nu blijf ik eigenlijk met de vraag zitten of er een deftige manier is om aangepaste image data in een webpage te persen zonder met headers te moeten werken.

Images uit een dbase halen is niet direct good practice, ok, de argumenten waren duidelijk. Maar een andere reden om bewerkte data in een page te steken kan bijvoorbeeld een image zijn die tot thumbnail verkleind is ofzo..

Wat is daar dan de beste manier voor ?

Niet dat ik te lui ben om zelf te zoeken, ik heb al rondgekeken om te zien wat de best practice is, en ik kom niet veel verder dan dat men images op voorhand processed en dan opslaat in bestanden of BLOB's, wat me dan weer op mijn eerste rvaag terugbrengt...

[Janoz]

Verwijderd schreef op woensdag 20 september 2006 @ 12:44:
Images uit een dbase halen is niet direct good practice, ok, de argumenten waren duidelijk. Maar een andere reden om bewerkte data in een page te steken kan bijvoorbeeld een image zijn die tot thumbnail verkleind is ofzo..

Wat is daar dan de beste manier voor ?

Plaatjes in de DB zetten is zeker niet per definitie bad practice. Hier is laatst nog een topic over geweest dus ik zal die discussie hier niet verder beginnen.

De beste manier is al door Grote Prutser in de eerste reactie gegeven. Je moet niet proberen om alles in 1 php pagina te willen doen. Gebruik 1 pagina waarin je de img tag zet en een andere pagina waarmee je je plaatje genereerd. Bij een statische pagina is immers ook spraken van twee apparte requests. 1 voor de pagina en 1 voor het plaatje.

[Verwijderd]

Waar het mij over gaat is dat ik al een tijd de juiste of beste manier zoek om aangepaste image data toch op een pagina te zetten zonder headers.

Stel ik laat een PHP scriptje een simpele pagina outputten waarin 4 img tags staan.

De images mogen komen waar ze van willen, laat het een dbase zijn, laat het bestanden zijn. Probleem blijft dat ik ze eerst in PHP wil manipuleren (vergroten, verkleinen, draaien, whatever) waarbij ik dus als result een variabele heb met de image data in.

Wat is nu de beste manier om die images in die HTML te gooien zonder van die data URL's of headers te hoeven gebruiken ?

Ofwel staar ik me ergens heel fout op, of ik mis iets...

[Cartman!]

Wat heb je zom tegen op een externe file?
Je zou toch iets kunnen doen als :

PHP:

<img src="image.php?filename=test.jpg&actie=draaien" alt="" />
<img src="image.php?dbid=143&actie=vergroten" alt="" />

[Borizz]

g00fy schreef op woensdag 20 september 2006 @ 18:39:
Wat heb je zom tegen op een externe file?
Je zou toch iets kunnen doen als :

PHP:

<img src="image.php?filename=test.jpg&actie=draaien" alt="" />
<img src="image.php?dbid=143&actie=vergroten" alt="" />

Dat lijkt mij ook een prima oplossing, eventueel kan je dan met een rewrite rule de URL er nog anders uit laten zien, bijvoorbeeld zoiets:

code:

/images/gedraaid/test.jpg

[Verwijderd]

Dat zijn allemaal workarounds welke geen oplossing zijn voor mijn vraag of probleem ...

Stel je hebt een page die thumbnails laat zien van een reeks images. Of die images nu uit een dbase komen of losse bestanden zijn doet er niet toe. Goed, ik lees die in, resize die en dergelijke, en wil ze dan allemaal samen in 1 pagina eruit gooien.

Wat is dan de beste manier ?

[Janoz]

Nee, dat zie je fout. Het is geen workaround. Je image data in je html op proberen te nemen is een workaround. Het hele html gebeuren is juist zo ingericht dat de verschillende onderdelen van een pagina via verschillende requests worden opgehaald. Als jij een pagina hebt met een heleboel thumbnails dan is het juist gebruikelijk dat je door je hele pagina iets doet als:

<img src="thumbnail.php?imageId=1234"/>

en vervolgens een thumbnail.php maakt die een plaatje uit de database haalt, verwerkt en naar de client stuurt. Haal willekeurig wat pagina's op van internet en kijk hoeveel van die pagina's hun plaatjes via een extern bestand ophalen en hoeveel van die pagina's hun plaatjes embedded hebben in de html.

[Verwijderd]

OK... Mijn fout... Nu zie ik wat jullie bedoelen.. In de src van de img verwijs je naar een script ipv een image en op die manier gooi je die eruit...

Dat was hetgeen ik al een hele tijd overkeek... Mijn fout...