Opbouw "CMS" voor afbeeldingen

[mithras]

In ons systeem willen we de mogelijkheid hebben om serverside afbeeldingen te resizen, croppen e.d. Daarvoor kunnen we via php/gd allerlei bewerkingen uitvoeren. Uitgangspunten zijn:

1) Afbeelding kunnen bewerken
2) Dit efficient kunnen doen (denk aan cache e.d.)
3) De verschillende versies kunnen bijhouden (welke varianten zijn er van afbeelding x)
4) Extra parameters aan afbeeldingen kunnen geven (van een bepaalde set de volgorde bepalen)

Eerste probeersel
Onze eerste oplossing (inmiddels vervangen) voldeet alleen aan #1:
We deden dat via een url als dit: http://domein.nl/img/plaatje.jpg?w=200&cr=1:1. Oftwel: een crop-ratio van 1:1 (vierkantje) met een breedte van 200px. Dat werkte prima, maar alles gaat dus door php. De aangepaste afbeeldingen werden wel gecached, maar alsnog moet het php-scriptje alle losse afbeeldingen zelf serveren.

Tweede probeersel
Onze tweede oplossing (die draait nu, maar moet veranderd worden) voldoet aan #1 en #2, maar onze nieuwe eisen brengen roet in het eten.
Je vraagt een afbeelding op via http://domein.nl/img/resize/w/200/pad/naar/plaatje.jpg. Als het bestand niet bestaat wordt via php uit een map met originelen het bestand gepakt en de nodige bewerkingen toegepast. De afbeelding wordt weggeschreven naar het zojuist aangevraagde pad, dus elk volgend request heb je meteen via apache zelf de afbeelding te pakken (geen tussenkomst van php).
Maar dan heb je bijvoorbeeld verschillende versies (een w/200, w/500, h/350 etc). Hoe weet je vanuit het origineel welke varianten er allemaal zijn, zonder alle folders te scannen op mogelijkheden?

Nieuw probeersel
Tijd dus voor een nieuwe opzet, ditmaal liefst met jullie feedback. Uiteindelijk is het allemaal behoorlijk complex, want je wilt on-the-fly een bepaalde afmeting van een afbeelding ophalen. Deze moet liefst daarna direct opvraagbaar zijn, zonder tussenkomst van php (ook handig voor caching wat apache dan kan afhandelen).
Toch wil je, wanneer je het origineel vervangt, alle varianten daarvan kunnen weggooien om die ook te vervangen (dus je moet kunnen bijhouden welke varianten er allemaal zijn).

En liefst zou je nog van een specifieke subset van afbeeldingen (bijvoorbeeld alle afbeeldingen binnen een project van je portfolio) zaken als de volgorde kunnen bepalen. Er is dus óók meta-informatie die je moet kunnen opslaan. Dat zou per subset in een xml file kunnen, via een database of wellicht op een nog andere manier. Maar met een database krijg je natuurlijk verschillen tussen de entries in je db en de bestanden op je filesystem. Hoe ga je dat weer oplossen?

Ik heb wel verschillende systemen gezien, maar aan alle systemen kleeft een nadeel. Wat zijn jullie ervaringen? Ik zie wel wat in de opzet van ons tweede systeem, maar dan wellicht met een andere directory-structuur en/of koppeling met meta-informatie.

[NMe]

Waarom breid je je tweede probeersel niet gewoon uit met een tabelletje in je database? Daar kun je dan toch alle meta-info in kwijt die je je maar kan bedenken? Die verschillen waar je het zelf over hebt begrijp ik niet zo: als je een aanpassing doet op het filesystem moet je gewoon ook een aanpassing doen in de DB en andersom. Lijkt me niet zo'n punt.

[ Voor 37% gewijzigd door NMe op 06-08-2010 14:04 ]

[Kalentum]

Je zou de plaatjes allemaal een eigen directorystructuurtje kunnen geven.

Je urls -> filesystem mapping worden dan:
[..]/plaatje.jpg -> verwijst naar /plaatjes/plaatje.jpg/origineel/plaatje.jpg
[..]/plaatje.jpg/w/300 -> /plaatjes/plaatje.jpg/w/300/plaatje.jpg
[..]/plaatje.jpg/w/300/h/400 -> /plaatjes/plaatje.jpg/w/300/h/400/plaatje.jpg

etc

Dus elk plaatje krijgt een eigen directory waar je gecachte plaatjes in weg kan schrijven, op basis van de aanroepende url.

Volgens mij is dit nog wel te doen met url rewriting

[r0bert]

Waarom zou je van die rare url's gebruiken waarin je allerlei parameters verwerkt? Daarvoor heb je de query-string.

getPicture?id=3423width=300&height=400&..etc..
evt kan een bestandsnaam natuurlijk ook.

Vervolgens ga je in apache on request met een conditie kijken of het bestand al bestaat in jouw path. Dus je rewrite alle params naar jouw path waar je de afbeeldingen opslaat, bijv:
3243/300x400.jpg of wat voor opties je ook maar hebt.
Als die bestaat, serveer je het bestand vanuit apache.

Anders laat je de request gewoon doorgaan, het script genereerd de image en schrijft deze weg. Volgende keer bestaat de image al.

Wil je de boel vernieuwen, dan gooi je in dit geval het mapje 3243 leeg vanuit je script. Volgens mij hoeft het allemaal niet zo moeilijk te zijn.

Je zou ook nog funky kunnen gaan doen met rewrite-maps of een perl-script eraan hangen, maar lijkt me nogal overkill voor nu.

[creator1988]

r0bert schreef op zaterdag 07 augustus 2010 @ 15:55:
Waarom zou je van die rare url's gebruiken waarin je allerlei parameters verwerkt? Daarvoor heb je de query-string.

Nee, want clientside caching werkt dan niet correct

[NMe]

creator1988 schreef op maandag 09 augustus 2010 @ 10:34:
[...]

Nee, want clientside caching werkt dan niet correct

Dat valt ook wel weer mee, zolang de querystring er hetzelfde uitziet kunnen de meeste browsers het best cachen. Maar je hebt wel gelijk dat die opmerking nergens op slaat. Met die "gekke urls" gebruik je ook gewoon je querystring, alleen ziet je gebruiker dat niet. Nouja, tenzij je multiviews gebruikt, maar dat zijn ook maar semantics.

[djluc]

Je kunt 2 kanten op eigenlijk die essentieel verschillen.

1. Vanuit de client request werken. Dat wil zeggen: Op het moment dat iemand een file opvraagt ga je eens kijken wat er mee moet gebeuren, eventueel bewerken etc.

2. Vanuit de server automatisch resizen. Op het moment dat je een afbeelding toevoegt of aanpast worden er aan je "te verwerken" lijst taken toegevoegd die automatisch afgewerkt worden. Bijvoorbeeld middels een cron. Het resizen gebeurt dus geheel onafhankelijk van de bezoekers.

Het is dan dus mogelijk dat een afbeelding nog niet meteen bestaat op het moment dat je deze aan gaat maken.

Qua opvragen lijkt me dat je zaken als croppen e.d. niet in de url wilt stoppen. Een formaat wellicht nog maar daar zou ik stoppen. Geef elke foto een unieke naam (kan eenvoudig met een relationele database) en zorg er vervolgens voor dat je deze urls beschikbaar stelt.

Je opmerking:

Maar dan heb je bijvoorbeeld verschillende versies (een w/200, w/500, h/350 etc). Hoe weet je vanuit het origineel welke varianten er allemaal zijn, zonder alle folders te scannen op mogelijkheden?

Vond ik een beetje vreemd. De paden mogen gewoon nep zijn, het hoeven absoluut geen echte paden te zijn op je filesystem. Middels rewrites kan je eenvoudig bepalen waar een bestand staat. Bijvoorbeeld:
http://domein.nl/img/resize/w/200/pad/naar/plaatje.jpg

Kan gewoon verwijzen naar:
http://domein.nl/images/plaatje_200.jpg

Nergens is het voor nodig dat je zo'n complexe mappenstructuur maakt, de files indelen heeft een hele andere logica. Als je jouw structuur gebruikt en je hebt 100.000 afbeeldingen met een breedte van 200 dan kan je al een probleem krijgen tenzij je weer submapjes aan gaat maken.

[Jory]

Qua opvragen lijkt me dat je zaken als croppen e.d. niet in de url wilt stoppen. Een formaat wellicht nog maar daar zou ik stoppen.

Op mijn werk doen we dat juist wel. Bij ons wordt een afbeelding gegenereerd, op het moment dat ernaar gerefereerd wordt in de HTML. (Dit wordt door onze template engine aangestuurd.)
Dat ziet er ongeveer zo uit:

code:

<img src="{image, source="blaat.jpg", height=100, width=500, foo=bar" alt="Een plaatje!"/>

De code die daardoor wordt aangeroepen, gaat resizen, croppen, etc wat we maar willen, en geeft uiteindelijk de URL van de gegenereerde afbeelding terug. Die URL is gewoon de originele naam, plus alle (ingevulde) parameters (key+value), gescheiden door underscores. Dus bijvoorbeeld blaat_h-100_w-500_f-bar.jpg.
Op deze manier kunnen we twee "versies" van een afbeelding hebben, die bijvoorbeeld alleen verschillen in één kleine parameter. (Praktijk voorbeeld: één met overlay waardoor we mooi afgeronde hoekjes krijgen, en één zonder die overlay.)

Ik weet niet precies wat mithras bedoelt met "versies" bij punt 3. Als dat variaties zijn zoals ik hierboven beschrijf, dan zou dit je oplossing kunnen zijn. Als je bedoelt dat er een nieuwe afbeelding voor komt, is het denk ik beter gewoon die nieuwe afbeelding op te slaan en de verwijzingen naar de oude afbeelding te vervangen. (Het is immers niet dezelfde afbleeding, maar een andere.)

Voor je meta data (=alles behalve het bestand zelf) zou ik waarschijnlijk een database gebruiken, hoewel dat natuurlijk afhankelijk is van je situatie. Om dit consistent te houden, hoef je enkel te zorgen dat je mooie transacties gebruikt, ongeveer zo:

PHP:

$db->startTransaction();
try {
  $db->createImageEntry($image);
  $fileSystem->storeImage($image);
  $db->commitTransaction();
} catch( Exception $e ) {
  $db->rollbackTransaction();
}

Op die manier ben je er redelijk zeker van dat alles mooi consistent blijft.

[mithras]

"Even" een reactie op alle tips, bedankt voor de inzichten

offtopic:
Dat krijg je als je hier slechts op werktijden aandacht aan besteedt

NMe schreef op vrijdag 06 augustus 2010 @ 14:03:
Die verschillen waar je het zelf over hebt begrijp ik niet zo: als je een aanpassing doet op het filesystem moet je gewoon ook een aanpassing doen in de DB en andersom. Lijkt me niet zo'n punt.

Het is natuurlijk mogelijk dat je een db entry hebt waar de files op je fs ontbreken en andersom. Hoe vang je dat op? We bieden normaal geen ftp en phpmyadmin access aan onze gebruikers van het systeem, maar mogelijkerwijs kan er natuurlijk wel een verschil optreden. Dat wilde ik eigenlijk liefst zo veel mogelijk voorkomen.

rutgerw schreef op vrijdag 06 augustus 2010 @ 14:35:
Je zou de plaatjes allemaal een eigen directorystructuurtje kunnen geven.

Je urls -> filesystem mapping worden dan:
[..]/plaatje.jpg -> verwijst naar /plaatjes/plaatje.jpg/origineel/plaatje.jpg
[..]/plaatje.jpg/w/300 -> /plaatjes/plaatje.jpg/w/300/plaatje.jpg
[..]/plaatje.jpg/w/300/h/400 -> /plaatjes/plaatje.jpg/w/300/h/400/plaatje.jpg

Mm, wel een goed idee om het pad naar de afbeelding als directory structuur te gebruiken. Dat biedt in ieder geval een stuk meer houvast dan de huidige opzet

r0bert schreef op zaterdag 07 augustus 2010 @ 15:55:
Waarom zou je van die rare url's gebruiken waarin je allerlei parameters verwerkt? Daarvoor heb je de query-string.

Hier kleven meer nadelen dan voordelen aan. Lijkt allemaal wel leuk, maar het uitgangspunt is imho al verkeerd. Een GET request met verschillende parameters zouden niet een afbeelding in verschillende afmetingen (denk ook aan crop!) moeten serveren. Daarnaast is het vanuit SEO ook zeker niet voordelig om allerlei bestanden via ids op te halen zonder te denken aan bestandsnamen.

djluc schreef op maandag 09 augustus 2010 @ 11:05:
Je kunt 2 kanten op eigenlijk die essentieel verschillen.

1. Vanuit de client request werken. Dat wil zeggen: Op het moment dat iemand een file opvraagt ga je eens kijken wat er mee moet gebeuren, eventueel bewerken etc.

2. Vanuit de server automatisch resizen. Op het moment dat je een afbeelding toevoegt of aanpast worden er aan je "te verwerken" lijst taken toegevoegd die automatisch afgewerkt worden. Bijvoorbeeld middels een cron. Het resizen gebeurt dus geheel onafhankelijk van de bezoekers.

Die tweede optie is iets wat je niet wilt. Voorbeeld: een gebruiker maakt een nieuw portfolio item aan en upload een 10-tal afbeeldingen voor dat project. Als je dan dat gaat bekijken moet alles uiteraard meteen beschikbaar zijn.

Uiteraard gebeurt dit "pas" wanneer je als client een request stuurt naar de afbeelding (en niet naar je pagina -html- zelf).

Qua opvragen lijkt me dat je zaken als croppen e.d. niet in de url wilt stoppen. Een formaat wellicht nog maar daar zou ik stoppen.

Juist wel. Fototoestellen maken foto's in verhoudingen 4:5 en 2:3. Daar moet je gebruikers niet mee lastig vallen en de juiste aspect ratio in je ontwerp automatisch verwerken. Ook komt het vaak genoeg voor dat je square thumbnails in je ontwerp hebt terwijl echte afbeeldingen (staand of liggend) in geen geval die originele verhoudingen hebben.

Je opmerking:
[...]
Vond ik een beetje vreemd. De paden mogen gewoon nep zijn, het hoeven absoluut geen echte paden te zijn op je filesystem. Middels rewrites kan je eenvoudig bepalen waar een bestand staat. Bijvoorbeeld:
http://domein.nl/img/resize/w/200/pad/naar/plaatje.jpg

Kan gewoon verwijzen naar:
http://domein.nl/images/plaatje_200.jpg

Nergens is het voor nodig dat je zo'n complexe mappenstructuur maakt, de files indelen heeft een hele andere logica. Als je jouw structuur gebruikt en je hebt 100.000 afbeeldingen met een breedte van 200 dan kan je al een probleem krijgen tenzij je weer submapjes aan gaat maken.

Dat is inderdaad het inzicht wat ik heb gekregen door dit topic

Jory167 schreef op dinsdag 10 augustus 2010 @ 17:17:
[...]
Op mijn werk doen we dat juist wel. Bij ons wordt een afbeelding gegenereerd, op het moment dat ernaar gerefereerd wordt in de HTML. (Dit wordt door onze template engine aangestuurd.)
Dat ziet er ongeveer zo uit:

code:

<img src="{image, source="blaat.jpg", height=100, width=500, foo=bar" alt="Een plaatje!"/>

De code die daardoor wordt aangeroepen, gaat resizen, croppen, etc wat we maar willen, en geeft uiteindelijk de URL van de gegenereerde afbeelding terug. Die URL is gewoon de originele naam, plus alle (ingevulde) parameters (key+value), gescheiden door underscores. Dus bijvoorbeeld blaat_h-100_w-500_f-bar.jpg.
Op deze manier kunnen we twee "versies" van een afbeelding hebben, die bijvoorbeeld alleen verschillen in één kleine parameter. (Praktijk voorbeeld: één met overlay waardoor we mooi afgeronde hoekjes krijgen, en één zonder die overlay.)

Bij het compileren van de template direct je afbeeldingen resizen/croppen? Op zich wel handig, maar wat doe je dan met alle afbeeldingen die later worden toegevoegd door gebruikers (zie mijn portfolio voorbeeld hierboven)?

Ik weet niet precies wat mithras bedoelt met "versies" bij punt 3. Als dat variaties zijn zoals ik hierboven beschrijf, dan zou dit je oplossing kunnen zijn. Als je bedoelt dat er een nieuwe afbeelding voor komt, is het denk ik beter gewoon die nieuwe afbeelding op te slaan en de verwijzingen naar de oude afbeelding te vervangen. (Het is immers niet dezelfde afbleeding, maar een andere.)

Inderdaad. Het gaat bijvoorbeeld om onze eigen website: http://soflomo.com. Een afbeelding van higlighted projects (specifiek formaat), afbeelding thumbnail als overzicht (binnen categorie) en afbeelding binnen project. Het origineel kan nog groter zijn.

Voor je meta data (=alles behalve het bestand zelf) zou ik waarschijnlijk een database gebruiken, hoewel dat natuurlijk afhankelijk is van je situatie. Om dit consistent te houden, hoef je enkel te zorgen dat je mooie transacties gebruikt, ongeveer zo:

PHP:

$db->startTransaction();
try {
  $db->createImageEntry($image);
  $fileSystem->storeImage($image);
  $db->commitTransaction();
} catch( Exception $e ) {
  $db->rollbackTransaction();
}

Op die manier ben je er redelijk zeker van dat alles mooi consistent blijft.

Op zich wel, maar je bent nog niet verzekerd van andere mogelijkheden waarbij inconsistentie kan optreden. Ik heb geen idee of dat reeele gevallen zijn, maar toch heb ik het in overweging

[Jory]

mithras schreef op dinsdag 10 augustus 2010 @ 22:11:
[...]
Bij het compileren van de template direct je afbeeldingen resizen/croppen? Op zich wel handig, maar wat doe je dan met alle afbeeldingen die later worden toegevoegd door gebruikers (zie mijn portfolio voorbeeld hierboven)?

Hier gebeurt het croppen enzo niet bij het compileren van de templates bij ons, het gebeurd bij het serveren ervan. (Onze template engine doet niet aan compileren.)
Dus bijvoorbeeld, in jullie portfolie. Ik neem aan dat de items uiteindelijk in een lijst achtig iets in jullie PHP code zitten. Uiteindelijk heb je in je template dan een loop constructie. In die loop wordt ons componentje aangeroepen dat het croppen en dergelijke doet. Dit betekend wel, dat als je op één pagina een overzicht van 100 portfolio items laat zien, er in die request al 100 afbeeldingen gecropped enzo worden, waardoor die pagel load wat aan de langzame kant wordt. (Als er voor al die 100 afbeeldingen nog geen gecropped versie is natuurlijk.)

Dus ongeveer zoiets:

code:

/*
 Dit is in de template. {image} is de component die resizen, croppen, overlays, etc. doet. $items is een
 array. De dingen die daarin zitten, zijn objecten met wat functies.
*/
{loop $items AS $item}
  <div class="item">
    <img src="{image, source="$item.getImage()", height=100, width=100, foo="bar"} alt="$image.getName()"/>
  <strong><a href="$item.getLink()">$item.getName()</a></strong>
  </div>
{/loop}

mithras schreef op dinsdag 10 augustus 2010 @ 22:11:
Dat krijg je als je hier slechts op werktijden aandacht aan besteedt

Leuke werktijden.

[Blaise]

Misschien mosterd na de maaltijd, maar ik zou met voorgedefinieerde profielen werken in plaats van met losse parameters in de URL. De URL zou er zo uit kunnen zien: /img/resize/big/portfolio/project/6/Librio.png. Je houdt dan op een centrale plek bij dat het profiel "big" een plaatje schaalt naar 715 pixels breed. Tevens erg handig als je je site verandert, je hoeft dan alleen de profielen aan te passen, en niet meerdere templates.

Je voorkomt ook dat kwaadwillende bezoekers kunnen spelen met parameters. Als ik bijvoorbeeld dit plaatje opvraag op jouw site: /img/resize/w/-115/portfolio/project/4/Collage.png, krijg ik een PHP error.

[Freeaqingme]

Wellicht enigzins offtopic, maar waarom gebruik je niet gewoon php in je templates? PHP _is_ een template taal (en ja, tegenwoordig nog veel meer), dus waarom je nou weer een template 'taal' gaat bouwen in een taal die daar voor bedoeld is...

[mithras]

Jory167 schreef op woensdag 11 augustus 2010 @ 09:15:
[...]

Hier gebeurt het croppen enzo niet bij het compileren van de templates bij ons, het gebeurd bij het serveren ervan. (Onze template engine doet niet aan compileren.)
Dus bijvoorbeeld, in jullie portfolie. Ik neem aan dat de items uiteindelijk in een lijst achtig iets in jullie PHP code zitten. Uiteindelijk heb je in je template dan een loop constructie. In die loop wordt ons componentje aangeroepen dat het croppen en dergelijke doet. Dit betekend wel, dat als je op één pagina een overzicht van 100 portfolio items laat zien, er in die request al 100 afbeeldingen gecropped enzo worden, waardoor die pagel load wat aan de langzame kant wordt. (Als er voor al die 100 afbeeldingen nog geen gecropped versie is natuurlijk.)

Dat lijkt me wel inefficient. Hoe ga je het doen met afbeeldingen die je later inlaadt (denk aan het inladen van afbeeldingen via AJAX)? Het is een stuk eenvoudiger dat te doen op het moment dat je daadwerkelijk een afbeelding opvraagt (als client).

Blaise schreef op vrijdag 13 augustus 2010 @ 02:19:
Misschien mosterd na de maaltijd, maar ik zou met voorgedefinieerde profielen werken in plaats van met losse parameters in de URL. De URL zou er zo uit kunnen zien: /img/resize/big/portfolio/project/6/Librio.png. Je houdt dan op een centrale plek bij dat het profiel "big" een plaatje schaalt naar 715 pixels breed. Tevens erg handig als je je site verandert, je hoeft dan alleen de profielen aan te passen, en niet meerdere templates.

Je voorkomt ook dat kwaadwillende bezoekers kunnen spelen met parameters. Als ik bijvoorbeeld dit plaatje opvraag op jouw site: /img/resize/w/-115/portfolio/project/4/Collage.png, krijg ik een PHP error.

Zeker geen mosterd na de maaltijd! We hadden zelf dit ook al eerder bedacht, maar het is eigenlijk op de planken blijven liggen. Goed dat je het zegt
Het heeft niet meteen te maken met mijn probleem, maar ik ga dit zeker nog wel oppakken om het ook te laten implementeren.

Je krijgt niet alleen een PHP error, je krijgt ook een stuk makkelijker de server plat

freakingme schreef op vrijdag 13 augustus 2010 @ 02:23:
Wellicht enigzins offtopic, maar waarom gebruik je niet gewoon php in je templates? PHP _is_ een template taal (en ja, tegenwoordig nog veel meer), dus waarom je nou weer een template 'taal' gaat bouwen in een taal die daar voor bedoeld is...

offtopic:
Dat is niet mijn post, maar die van Jory167

[Freeaqingme]

mithras schreef op vrijdag 13 augustus 2010 @ 12:17:
[...]

[...]

offtopic:
Dat is niet mijn post, maar die van Jory167

offtopic:
Oops, het was al laat...

[Jory]

mithras schreef op vrijdag 13 augustus 2010 @ 12:17:
[...]
Dat lijkt me wel inefficient. Hoe ga je het doen met afbeeldingen die je later inlaadt (denk aan het inladen van afbeeldingen via AJAX)? Het is een stuk eenvoudiger dat te doen op het moment dat je daadwerkelijk een afbeelding opvraagt (als client).

AJAX requests worden bij ons in principe op dezelfde manier afgehandeld als "normale" requests. De output daarvan wordt ook door onze template engine geparsed/gegenereerd. Beide methoden hebben natuurlijk voordelen en nadelen. Waarom deze keuze uiteindelijk gemaakt is, kan ik je niet vertellen - dat was er al toen ik begon en ik werk ook niet aan het framework, enkel met het framework.

@freakingme: De gebruikelijke redenen. (Beter leesbaar, compacter, kan ook gebruikt worden door onze frontend jongens, van wie een deel geen PHP kent.)

[djluc]

mithras schreef op dinsdag 10 augustus 2010 @ 22:11:
"Even" een reactie op alle tips, bedankt voor de inzichten

offtopic:
Dat krijg je als je hier slechts op werktijden aandacht aan besteedt

[...]
Die tweede optie is iets wat je niet wilt. Voorbeeld: een gebruiker maakt een nieuw portfolio item aan en upload een 10-tal afbeeldingen voor dat project. Als je dan dat gaat bekijken moet alles uiteraard meteen beschikbaar zijn.

Uiteraard gebeurt dit "pas" wanneer je als client een request stuurt naar de afbeelding (en niet naar je pagina -html- zelf).

[...]

De keuze om het processen van afbeeldingen niet binnen een request te doen maar in een background proces heeft ook voordelen. O.a. de pagina load tijden worden sneller, er worden alleen wat taken opgeslagen. Daarnaast kan je als je een multi upload tool gebruikt de afbeeldingen al gaan resizen nog voor het "artikel" bijvoorbeeld opgeslagen wordt. Je kan dan zodra de afbeelding beschikbaar is meteen een demo tonen.

Vaak zijn dit soort dingen zeker in grotere hoeveelheden handiger lineair te verwerken met een que dan steeds per stuk op aanvraag. Als de afbeelding er nog niet is kan je een standaard "processing" afbeelding terug sturen.