thumbnail uit jpg header eficienter?
Ik hou het ff op theorie, de kenner weet waarover het gaat.
Status quo:
Ik heb een map '/small' en een map '/normal' waarin ik foto's zet, in de small een resolutie van 160x120 en waarvan de naam identiek is aan zijn grote broer in de map 'normal'.
Uiteraard kan ik bv. voor een overzicht alle foto's uit de normal map inlezen en deze als 160x120 laten zien, maar dan is inlezen van de hele pagina beduidend trager.
Nu heb ik gelezen dat in de (exif)-header van jpg foto's een thumbnail verstopt zit.
Nu mijn vraag:
Is het mogelijk om deze thumbnail via php uit de grote foto in te laden - uiteraard zonder dat de gehele foto geladen wordt - zodat de snelle laadtijd van de'/small' map methode ge-evenaard wordt?
Voorbeelden ook welkom. bvd voor reakties.
(voor de website waarvoor ik het wil gebruiken is www.renewennekes.com )
Gewijzigd op 03/09/2010 13:45:41 door Rene Wennekes
Dan moet je dus in JS de grote foto laden, de exif lezen, daarvan de thumb data extraheren en van die data een image maken en deze met een POST request naar de server sturen. Lastig hoor.
Verder ben je zeer afhankelijk van die thumb, hij zit lang niet in alle JPEGs.
Leesvoer:
http://www.exif.org/specifications.html
http://www.nihilogic.dk/labs/exif/
Als ik jou was zou ik er pas aan beginnen als je heel veel van string manipulatie weet.
Of ik begrijp je verkeerd en wil je de thumbnails server-side extraheren. In dat geval: http://www.php.net/manual/en/function.exif-thumbnail.php
Bv. thumb in de header is 6kb en de foto is 120kb. Ik vraag dan wel het bestand (jpg foto), maar er wordt alleen maar die 6kb gedownload en krijg in een string de thumb-foto.
Net zoals bv. flash al begint zodra er al een scene is geladen zonder dat de flash 100% is ingeladen.
Bij 1 foto is het geen probleem, probleem is dat het bij een hele sheet met bv. 60 foto's wel uitmaakt. Ik zal eens op die link nog eens kijken.
update: de laatste voorbeeld van php.net zegt (neothermic) dat de laadtijd korter zou zijn.
Kan iemand dat bevestigen.
Ik weet in ieder geval dat je de thumbdata niet als bestand (logisch) moet wegschrijven maar meteen in de img tag moet zetten.
Gewijzigd op 03/09/2010 14:20:29 door Rene Wennekes
Dan kan je veel beter de afbeelding verkleind opslaan met GD of Image magick.
Ik zou als ik jou was niet te veel rekenen op de aanwezigheid van die thumb in de EXIF.
Gewijzigd op 03/09/2010 14:24:50 door Pim -
Ik wou me met - cms minded - werk besparen als ik zelf geen thumbs (afbeeldingen verkleind) hoefde op te slaan.
Maar ik wil niet dat de totale laadtijd van de pagina's er op achteruitgaat (langer dus).
Via het programma wat ik lokaal gebruik, zorg ik ervoor dat die thumb erin blijft zitten, da's geen probleem.
Gaat mij erom dat ik de zelfde prestaties kan verwachten op die methode.
Nee, als je on-the-fly thumbnails uit groto foto's extraheert is dat een ernome impact op je performance. Sla gewoon verkleinde afbeeldingen op!
Kon het toch niet nalaten te experimenteren.
Kom ik erachter dat de originele foto's direct uit de camera nog niet eens thumbnail heeft volgens voorbeeldscript. Terwijl een exif programma van Panda2 (geosetter) zegt van wel.
Dat kan komen door de verschillende versies van de EXIF specificatie.
damn .... ik dacht dat zit wel in de jpg als die direct uit mijn mooie dure canon eos 450d dslr camera komen .......
Je moet ook in RAW schieten ;)
Pim de Haan op 03/09/2010 16:25:18:
Je moet ook in RAW schieten ;)
Doe ik ook.
Update:
Toch maar geprobeerd, moest ff de fouten eruit halen maar zeer tevreden over het resultaat.
Nieuwe map foto's geprobeerd (zaten dus niet in de cache).
Zeer snel ingeladen.
Bovendien hadden alle foto's een embedded thumbnail :)
Alleen hadden sommige vreemd genoeg een 2 zwarte randjes :(
(minor problem)
Gewijzigd op 04/09/2010 01:48:30 door Rene Wennekes