Häufig möchte man Links zu Bildern auf Wikimedia-commons setzen. Z.B. für die historische Karte. Wenn die Bilder dort eine hohe Auflösung haben, dauert der Preview manchmal sehr lange. Wikimedia bietet aber auch auf jeder Bildseite verschieden skalierte Versionen an:
“Size of this preview: 800 × 600 pixels. Other resolutions: 320 × 240 pixels | 640 × 480 pixels | 1,024 × 768 pixels | 1,280 × 960 pixels.”
Sind diese Links permanent, d.h. könnte man direkt auf die 320x240 pixel Version verlinken statt auf die “File:<image.pg>” Seite?
Die Wikimedia Dokumentation gibt da leider nicht viel her.
Korrekt. Interessant ist vlt. zu wissen, dass die vorgegebenen “Vorschaugrößen” zwar im Cache von Wikimedia Commons vorgehalten werden, jedoch können sich diese Größen auch “zentral” ändern. Daher, wenn du dich auf eine bestimmte Größe fixierst, die es in ein, zwei Jahren vlt. nicht mehr gibt…
Edit: Dafür setzt man am besten Links auf die Dateibeschreibungsseite, um
A: Eine Vorschau aus dem Cache zu sehen
B: Die optionale Auswahlmöglichkeit für beliebige Größen zu erhalten
C: Die Lizenzen zu betrachten
Wenn aber eine Bilderseite von vorneherein Vorschaubilder verschiedener Größen anbietet (wie hier bei commons) und diese sehr schnell verfügbar sind (1-2s), dann wäre es doch schön, der historischen Karte (die sehr viel länger für die Skalierung großer Bilder braucht) die Arbeit zu erleichtern, indem man sie von vorneherein mit der kleinsten verfügbaren Version füttert.
Ich will eben nicht hingehen und die Originalbilder stark verkleinern, nur damit sie schneller angezeigt werden (und damit die Philosophie von commons vergewaltigen). Der interessierte Betrachter soll weiterhin die Möglichkeit haben, via commons das Bild in einer großen Auflösung anzusehen.
Mir ist nicht klar, ob die verschiedenen Größen bei commons prinzipiell vorliegen oder nur on the fly skaliert werden (darüber findet man nichts). In jedem Fall würde ich sie gerne auch ansprechen können.
Am angenehmsten wäre es natürlich, wenn ich mir darüber überhaupt keine Gedanken machen müßte und der Skalier-Algorithmus bei Bildern von commons automatisch die kleinst sinnvolle Version als Basis für seine Skalierung runterladen würde!
In der OpenLinkMap wird etwa bei dem kleinen Vorschaubild in den Popups bereits eine verkleinerte Version vom Wikimedia-Server angefordert, damit das Laden nicht so lange dauert.
Wenn man auf das Thumbnail klickt, wird das Bild in Originalgröße angezeigt. Bislang habe ich hier keine Begrenzung eingebaut, es wird also immer die volle Auflösung angefordert. Es würde natürlich Sinn machen, hier eine gewisse Begrenzung einzubauen, denn kaum jemand wird wohl ein 10 Megapixel Foto in voller Auflösung anfordern wollen…
Kleine Versionen ansprechen kann man sie auf jeden Fall, und zwar in beliebigen Größen - auch 277 Pixel oder so etwas. Auch wenn ich es nicht genau weiß, gehe ich daher davon aus, dass alle Bildgrößen zuerst einmal on the fly skaliert werden und dann in einem Cache liegen. (Das ist auch deshalb nötig, weil man z.B. bei Wikipedia die gewünschten Bildgrößen in den Artikeln und Bildbeschreibungsseiten umstellen kann.)
Taginfo nutzt diese Funktionalität beispielsweise für die eingebundenen Bilder. Man könnte die URL wohl selbst zusammenbauen, wenn man weiß, in welchem Wiki das Bild tatsächlich liegt. Taginfo fragt stattdessen bei der Wiki-API an, da hier Bilder aus dem OSM-Wiki und Commons bunt gemischt sind. Jochens Gedankengänge, inklusive einer Andeutung wie er die URLs aufgebaut hätte, sind aus diesem Thread ganz gut ersichtlich: http://gis.19327.n5.nabble.com/CORS-on-the-Wiki-td5743508.html
Goldene Regel #3 bei OSM (nach nicht kopieren und nach Spaß haben): niemals das Tagging an defekte Software anpassen. (Bitte ins Wiki aufnehmen.)
Wenn das Bauen der Thumbs von Wikimedia-Bildern als zu deutlich zu langsam empfunden wird, muss ich da was tun. Ich werde zuerst nachschauen, ob der WM-Server die Zeit braucht, weil wir ein Format abfragen, das nicht im Cache liegt, oder ob das Skalieren selbst zu lange braucht.
Wir können natürlich auch wie bei Flickr ein Redirekt zum Vorschaubild auf dem WM-Server geben. Jedenfalls solange, bis wir da gesperrt werden.
so, nachgeschaut: Bild decodierem und skalieren braucht nur Millisekunden; der Thumbnailer ist praktisch ausschließlich damit beschäftigt, Seiten und Bilder vom jeweiligen Server abzuholen.
Statt des Originalbildes wird jetzt das Hauptbild der Commons-File:–Seite abgeholt, das meist eine gute Größenordnung kleiner ist: dies sollte die Bereitstellung der Thumbs beschleunigen.
Der nächste Schritt wird wohl sein, nicht die Commons-File:–Seite abzuholen, sondern die zur Bildbeschaffung erforderlichen Infos über die API zu ziehen.
Ist das eigentlich auf dem Produktionsserver schon aktiviert? Für mein Gefühl dauert das Laden von nicht gecacheten commons-Images immer noch sehr lang.
Wird der Thumbnail jedesmal neu erzeugt oder nur beim ersten Aufruf? Wenn er gecached wird und es “meine” Bilder wären, wüsste ich schon, was ich machen würde.
die thumbnails werden 1 woche lang gecached, es sind ca. 2000 bilder im cache.
die cashe-zeit können wir nach belieben einstellen.
zu zeit arbeitet ein oranger mitarbeiter daran, falls neuere bilder zur verfügung stehen, das diese im hintergrund geladen werden,
und solange das alte bild angezeigt wird…
die cache-zeit wird dann auf jeden fall verlängert.
Ich habe etwas gefunden, daß Commons die parallele Zahl der downloads pro IP auf zwei beschränkt (nicht sicher ob das nur für database dumps gilt). Könnte evtl. auch etwas ausmachen, wenn die Geschichtskarte eifrig benutzt wird…?
Warum eigentlich nicht für den download einen Squid vorschalten statt den Cache selbst zu entwickeln?
Weil es Unfug ist, bei jedem Aufruf das Thumbnail aus einem Originalbild neu zu berechnen, statt ein bereitliegendes Thumbnail auszuliefern.
Weil wir lieber das Thumbnail-Script um 5 Zeilen vergrößern, als dem Lutz die Betreuung eines Squids ans Bein zu binden.
Es gibt zur Zeit kein Problem. Wir liefern mit der maximal uns möglichen Geschwindigkeit aus. Zur Zeit muss der Abrufer beim ersten Aufruf eines Vorschaubildes nach einer Woche warten, während das Vorschaubild neuberechnet wird. Das ändern wir noch dahingehend, dass der Abrufer das alte Bild geliefert bekommt, während das neue parallel berechnet wird, um die Wartezeit zu vermeiden.
