Standard URL für Bildthumbs

Das ganze Netz Bilder ist voller Text und Bilder. Und meist braucht man die in unterschiedlichen Größen, denn man sollte "darauf achten, dass die darin referenzierten Grafiken nicht zu groß sind, denn aufwendige Grafiken verursachen lange Ladezeiten und Missmut beim Anwender. Reduzieren Sie in Ihren Grafiken gegebenenfalls die Anzahl der Farben, verringern Sie die Bildgröße und stopfen Sie nicht zu viele Grafik-Referenzen in eine einzige HTML-Datei." sagt schon selfhtml.org.

Das kann und soll man nicht manuell machen müssen, daher bieten meisten CMS bietene image-resize gleich mit an, z.B. ImageMagick macht das alles. Aber jedes CMS baut seine eigene Image URL auf. Das ist recht schade, denn so kann man nicht einfach im Quelltext das Bild mal vergrößern, sondern muss wissen wie der neue Pfad ausschaut. Auch haben unterschiedliche hostingansätze unterschiedliceh Anforderungen. Ein großer Datenbank basierter Bilderdienst achtet vmtl mehr auf eine einfache ID, eine kleine Webseite die Bidler in Ordner speichert eher auf Hirachie und Logik.

Aber könnte man nicht einen URL Standard machen der alle Anforderungen abdeckt aber dennoch verständlich und lesbar ist? Die Ordnerstruktur muss so sein dass sie auch viele Bilder verteilen kann, also tief struktieriert. Die Änderungen an der URL sollten aber möglichst an wenigen oder am besten einer Stelle machbar sein. Allerdings soll man ein komplettes Cache Löschen auch ohne aufwendiges greppen (nach '*_thumb.{jpg|gif|png}') machen können, eine Sicherung der Original ohne thumbs aber auch.

Die Lösung sucht RESTful Image API Specification (RIAPI)

Es gibt

Dabei gibt es schon unterschiedliche Ansätze:

Mediawiki spiegelt die gesamte Ordnerstruktur in eine unterordner 'thumb' und legt für jedes Bild einen Ordner an in dem alle resizden Bilder drin sind. Hat den Nachteil das man vorne in den URL 'thumb' reinschreiben muss und hinten den Bildnamen plus die neue Größe verdoppeln muss.

  images/3/3d/FuBK-Testbild.png
  images/thumb/3/3d/FuBK-Testbild.png/220px-FuBK-Testbild.png

Wordpress legt neben jedes Bild resizde version und hängt eine ID an (welche ich nicht verstehe )

  /wp-content/uploads/2012/10/FuBK-Testbild.png
  /wp-content/uploads/2012/10/FuBK-Testbild-e1351465903965.png

Die neue größe ist nicht 'schreibar' udn Cachelöschen geht auch nicht (vmtl. rendert WP bei einem Blidnrequest gar nicht neu)

Fotodienste wie flickr oder hq23 bauen eine URL aus Photo ID ordner mix und einem wenigstens sprechenden Anhänger dran

  http://farm4.staticflickr.com/3234/3124679085_773a6d6a76_q.jpg
  http://farm4.staticflickr.com/3234/3124679085_9aa8f56062_o.jpg
  http://www.23hq.com/23666/7944962_e72e46f5da95a41ac61a668ff53c4f6f_quad100.jpg
  http://www.23hq.com/23666/7944962_e72e46f5da95a41ac61a668ff53c4f6f_standard.jpg
  http://www.23hq.com/klml/photo/7944962/original

Bei beiden muss man die Namen der Größen wissen, ein cache löschen ist auch nicht möglich.

gravatar übergibt für die größe einen GET Parameter

  http://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50?s=200

am schönsten machen es iirc die zwei placeholderdienst

  http://dummyimage.com/600x400/cf00cf/0011ff&text=klml
  http://placehold.it/350x150

Was wäre schön

  /belibige/ordnerstruktur/bildnameoderid.png
  /thumb/belibige/ordnerstruktur/bildnameoderid.png/220px-bildnameoderid.png

Der Mediawikiansatz gefällt mir erst mal am besten, bis auf das 2 mal Bildnamen schreiben. Leider muss man sich das "thumb" und "px-" und die passenden Position im URL merken wenn man vom Original auf das thumb will. Von thumb auf andres resizedes thumb allerindsg gehts es wenn man die gewünscht größe angibt.

Leider sollte man das auch das thumbild nur mit der Größe bennenen ('/thumb/beliebige/ordnerstruktur/bildnameoderid.png/220px.png'), denn dann würde man beim speichern ohne URL nicht mehr wissen was es ist. Der Ordner 'thumb' vorne muss auch bleiben, sonst kann man einfaches Cache löschen ganz vergessen.

Ordnet man die resized thumbs gar nicht mehr nach Originalbild, sondern nach größe gäbe das auch eine schöne Struktur

  /thumb/beliebige/ordnerstruktur/220/bildnameoderid.png

Der Nachteil aber ist das nicht mehr einfach alle thumbs eines Bildes bekäme, z.B. zum Löschen wenn sich das Originalbild geändert hat. (Was bei Mediawiki sehr oft vorkommt)

Das wäre dann bei den oben genannten Beispielen:

Mediawiki

images/3/3d/FuBK-Testbild.png images/thumb/3/3d/220/FuBK-Testbild.png

Wordpress

/wp-content/uploads/2012/10/FuBK-Testbild.png /wp-content/uploads/thumb/2012/10/220/FuBK-Testbild.png

flickr oder hq23

http://farm4.staticflickr.com/3234/3124679085_773a6d6a76.jpg http://farm4.staticflickr.com/220/3234/3124679085_9aa8f56062.jpg

gravatar http://www.gravatar.com/avatar/220/205e460b479e2e5b48aec07710c08d50

Weitere Parameter

Natürlich kann man ein Bild noch mehr als nur resizen. Man kann mehr Parameter angeben, wobei man wenn man einen Wert nicht verändern soll, den Ordner '/_/' nennen soll

  • breite resizen /200/
  • höhe resizen /x330/
  • unproportional resizen /20x500/
  • crop (von oben im Uhrzeiersinn wie margin) /_/10x30x12x50
  • rotate (auch im Uhrzeigesinn und in Grad) ///270/

und da gäbe es noch mehr

  • Formen und Schrift
  • Verzerrungen
  • Filter
  • Unschärfe
  • Solarisation
  • Kontrast
  • Invertierung.

Wofür

In Lightweight Markup (z.B. Markdown werden Bilder auch per URL referenziert, Mediawikitext hat eine zusätzliche nicht standardisierte Funktion mit der Bilder nur mit dem Dateinamen und der Größe (es gibt noch den standard 'miniatur' der noch eine Bildunterschrift haben kann) eingebunden werden können.

So schreibt man einfach in Mediawiki ''350px]'' das ist für Wikipedia (!) auf Grund der Masse an Bildern sinnvoll

Aber ein einfaches blog/perswiki etc sollte auch einfache Bildurls haben können und das ohne serverseitige Markup, wenn der Bilderordner eindeutig wäre. z.B. in Markdown gäbe es dann:

![](/images/350/FuBK-Testbild.png)

Natürlich muss man dennoch serverseitig rendern, aber das kann man dann unabhängig. So könnte man sein wikiblog ganz plain betreiben und zum Bilderrendern an einen Webservice feuern der den Server das Thumb zur Speicherung überlässt. Ist sehr nonCGI-damalswebspace-1998, oder eben auh serh 2013 transparentproxy-CDN-is-my-webpage style ;)