Bernhard Häussner
Journal: Neueste Artikel erscheinen hier (Seite 17 von 23)

Bilder züchten

12.02.2009, 17:32

Mit freeSq gezüchtetes Bild

Der neueste Trend ist es ja anscheinend genetisch zu Programmieren (bzw. programmieren zu lassen). Der Webcomic xkcd greift das Thema auf und Roger Alsing zeigt wie es geht. Mir geht es natürlich nicht darum Algorithmen genetisch zu basteln, oder Bilder nach zu stellen, sondern ich wollte einfach mal den Computer etwas herumprobieren lassen. Da wir in Kunst zurzeit kubistische Bilder malen müssen, habe ich mir gedacht, so etwas könnte doch auch ein Computer hin bekommen. Der Computer malt also Rechtecke, und versucht sie so hin zu bekommen, dass es ungefähr aussieht, wie das Originalbild.

Da das Vorgehen ja ein bisschen an die Biologie angelehnt sein sollte, benutzte ich so etwas, wie einen genetischen Algorithmus. (Es ist also nicht der Algorithmus, der „genetisch“ erzeugt wurde). Im ersten Versuch habe ich dem Computer fünfhundert, zunächst gleiche, weiße Rechtecke auf schwarzem Hintergrund vorgesetzt. Der Computer hat dann immer ein zufälliges Rechteck genommen und zufällig platziert. Die neuen Bilder waren also so etwas wie Kinder. Dann hat eine Fitting-Funktion überprüft, ob sich die Ähnlichkeit zur Vorlage verbessert hat. Wenn ja, hat er dieses neue zufällige Rechteck gespeichert (also in die „DNA“) aufgenommen und dieses Kind als neues Mutterelement verwendet. Hat sich nichts verbessert, hat er einfach ein weiteres Kind erzeugt.

Die Fitting-Funktion

Ich habe ein kleines Python-Script gebastelt, dass die Übereinstimmung zweier Bilder ausrechnen kann. Da alles in schwarz-weiß passiert, geht es jeden Pixel durch und addiert jeweils die Differenz der Rotwerte. Je größer die Zahl ist, desto schlechter passt das Bild. Der Computer favorisiert also Kinder mit kleineren Werten.

Zweiter Algorithmus

Da der erste Algorithmus zwar mit nur 500 Rechtecken immer bessere Näherungen erreicht hat, aber zum Ende hin sehr viele Versuche brauchte um wieder ein besser angepasstes Kind zu finden habe ich einen zweiten Algorithmus gebastelt, der diese Probleme vermeiden soll:

Er züchtet aus einem Elternelement zunächst 500 Kinder. Die Zucht-Funktion fügt allerdings jetzt jeweils ein schwarzes oder weißes Rechteck hinzu, wodurch Fehler schneller korrigiert werden können. Beim alten Algorithmus konnte ein fehlerhaftes Rechteck ja nur verschoben werden, wenn es zufällig gewählt und zufällig richtiger platziert wurde. Die Zahl der Rechtecke entspricht also der der Generation.

Die 500 Kinder sind zunächst noch klein und es werden nur 25% der Pixel gerastert. Die Kinder werden dann mit einer kleineren Version der Vorlage verglichen, und nur die besten 10 werden erwachsen und dann in voller Größe vergleichen. Damit werden nicht mehr so viel Ressourcen (Rechenzeit) für grobe Fehlplatzierungen verschwendet. Aus den letzten 10 Kindern wird dann das, welches in groß am Besten passt, als neues Elternelement gewählt, aus dem wiederum 500 neue Kinder-Bilder gezüchtet werden. Die 499 anderen Kinder werden für immer gelöscht, sodass nun nur noch die Elternelemente (die mit Verbesserungen) konserviert werden um meine Felsplatte zu schonen. So werden immer weiter bessere Merkmale vererbt, bzw. alte Fehler in den Merkmalen korrigiert.

Die DNA

Genau wie bei der echten DNA auch, werden die Informationen so gespeichert, dass die Kinder „wachsen“ können, nämlich als SVG. PHP kann durch seine DOM-Funktionen die DNA leicht verändern und die Rechtecke sind in einem angemessenen Format gespeichert. Mit dem Programm rsvg lassen sich die Rechtecke auch schnell rastern in allen beliebigen Größen.

Das Ergebnis

Der erste Algorithmus „500“ hat nach 21 Stunden 50830 Generationen erzeugt und einen dabei Das Original recht nett angenähert. Ursprünglich habe ich geplant ein kleines Video daraus zu erstellen, doch selbst bei 30 fps wäre es etwa eine halbe Stunde lang, und man würde hauptsächlich die Fehlschläge sehen. Deshalb nur einige Auszüge aus dem Werdegang:

Der zweite Algorithmus „freeSq“ ist so gebaut, dass er ohne Probleme unterbrochen werden kann und deswegen werde ich ihn wohl noch deutlich länger laufen lassen. Aber nach den ersten rund 2 Stunden und 255 Generationen (127500 Versuchen) ist das Entsanden (links Vorlage):

Seltsamerweise ist es etwas zu klobig, es wirkt bisher nicht so fein, dafür ein bisschen komplexer, doch es wird sich zeigen, wie es nach einigen weiteren Generationen aussieht. Da das Ganze sehr viel Zufall beinhaltet, könnte bei einem weiteren Durchlauf auch ein völlig anderes Bild entstehen. Ich bin gespannt.

Übrigens: So sieht Evolution bei den Simpsons aus.

Kommentare: keine

SVN mit SVG und XSLT gibt Visualisierung

03.02.2009, 15:36

Als ich zum ersten Mal über XSL bzw. XSLT stolperte interessierte es mich sofort. Im Gegensatz zu der von PHP und MySQL gewohnten, mehr oder weniger prozeduralen, Verarbeitung und dem Datensatz-Prinzip werden nun XML-Bäume mit XPath-Templates transformiert. Nun habe ich erstmals eine sinnvollere Anwendung gefunden: Das Transformieren eines XML-Subversion-Logs in eine Visualisierung als SVG.

Vorallem im Web-Bereich liegen fast alle Daten (wenn nicht in einer SQL-DB) in XML-Dateien vor. Ein Beispiel sind AJAX-Anwendungen. Auch viele APIs benutzen XML zur Informationsübermittlung. Natürlich kann auch PHP mit XML umgehen, doch mit XSLT findet sich eine einfachere Möglichkeit, da man im XML-Bereich bleibt und nicht so viel PHP-Syntax und anderes hineinmischen muss.

Natürlich ist XSLT zu PHP grundsätzlich verschieden, da die Scripte nicht „live“ auf einem Server laufen, sondern die Transformation entweder ganz beim Client erfolgt oder das einmal Transformierte Resultat gesendet wird. Und XSLT liegt eigentlich auch fernab von jeder Webanwendung, ganz allgemein eben transformiert es Daten zwischen verschiedenen XML-Formaten.

Nun wird XSLT im Webbereich meist verwendet, um Daten in XHTML-Seiten umzuwandeln, ich verwende allerdings ein anderes Format der XML-Syntax: SVG.

Download

Es ist noch ein kleines Schell-Script dabei, um das Log zu erstellen und den XLST-Prozessor zu starten.

Tags:
Kommentare: keine

Caesar13

02.02.2009, 19:43

By André Mayer & Bernhard Häussner.

order prints

Tags:
Kommentare: 2 Einträge

Schneller abbr- und acronym-Tags im Editor

01.02.2009, 21:42

Die beiden Abkürzungs-Tags abbr und acronym werden kaum verwendet, vielleicht weil man nicht ständig Definitionen schreiben will, denn wozu gibt es Abkürzungen? Glücklicherweise kann ich die Definitionen auch fast automatisch schreiben, dank einer netten (und neuen) Funktion im CMS, die ich hier vorstellen werde.

Da eine Abk. meist mehrere Bedeutungen hat und man auch nicht immer wissen kann, was sich hinter den wenigen Buchstaben verbirgt, wäre man manchmal froh um eine Erklärung. Weil aber meistens sowieso klar ist, worum es sich handelt, darf die Erklärung auch nicht im Weg stehen. Eine Lösung dafür bieten die abbr- und acronym-Tags welche im title-Attribut eine Definition enthalten können, die dann vom Browser als Tooltip angezeigt wird.

Um jetzt diese Definitionen einfach einzufügen markiert man die Abkürzung im Editor und klickt auf den Abkürzungsbutton. Mit Javascript und AJAX wird eine Liste der Abkürzungen mit den markierten Buchstaben geladen, die die verschiedenen Definitionen enthält. Aus dieser wählt man dann die passende Definition und die Tags werden in den Text eingefügt. Sollte die passende Definition nicht gefunden werden, kann man einfach einen leeren abbr- oder acronym-Block einfügen.

Ein PHP-Skript generiert im Hintergrund die Abkürzungsdatenbank. Es sammelt in den vorhandenen Blogposts die verwendeten Abkürzungen mit ihren Definitionen heraus. Damit bei einer großen Abkürzungsdatenbank nicht so viel übertragen werden muss, filtert das PHP-Skript die Abkürzungen auch gleich noch. Da der Filter optional ist und ich ein CSS-Stylesheet für die Abkürzungsliste gebastelt habe, kann man sich die XML-Datei mit den Abkürzungen auch im Browser anschauen.

Auf diese weise ist das Hinzufügen von Abkürzungen kein Problem und es erscheinen auch immer nur die Abkürzungen, die man auch wirklich verwendet.

(andere neue Features des Blogs)

  • Print-Stylesheet
  • Suchfeld-Tipp
  • jQuery 1.3 und dessen
  • Live Events bei Feed-Tag-Wahl
  • Noscript-Warnung bei Feed-Tag-Wahl
  • und ein paar interne Sachen

War wohl ein produktives Wochenende. Ich bin auch bei ein paar anderen Projekten erheblich weiter gekommen.

Kommentare: keine

Weniger Traffic durch JS, PNG und CSS optimierung

01.02.2009, 18:46
Web Compression

Web Compression

Wie erreiche ich schnellere Ladezeiten für meine Webseiten ohne ein riesiges Rechenzentrum anzumieten? Man kann mit einigen Details schon unglaublich viel sparen, denn schon kleine Veränderungen an häufig angeforderten Dateien machen viel aus. Das Aktivieren von gzip, das Komprimieren von HTML, CSS und Javascript, die Optimierung von PNG-Bildern und das Verwenden von CSS-Sprites und CDNs.

CSS-Sprites

Anstatt jedes Icon und jedes Hintergrundbildchen in einer eigenen Datei zu laden, werden alle in ein Bild gepackt. Da die meisten Besucher ohnehin einen Breitbandanschluss haben, machen für sie wenige KB Dateigrößen-Unterschied kaum etwas aus. Doch viele Requests brauchen bei jeder Verbindung viel Zeit. Für jedes Bild, dass man mit einem anderen Kombinieren kann, spart man ein Request.

Damit man nicht viele Container-Elemente ins HTML einbauen muss, lohnt es sich die Bilder geschickt zu kombinieren. Ich habe so auf meiner Homepage das Markup kein bisschen verändert, als ich vor kurzem CSS-Sprites implementiert habe. Um die Bilder zu packen, setzt man z.B. solche Muster und Verläufe, die horizontal wiederholt werden, zusammen untereinander in ein Bild und solche, die vertikal wiederholt werden, nebeneinander in ein anderes. Buttons und Ähnliches, was ohne Wiederholung gerendert wird, kann man entweder in ein einzelnes Bild geben oder sie in eines der beiden anderen einbauen.

Auf dieser Seite habe ich z.B. die kleinen Icons ganz rechts in die Kombinierte Graphik gestellt, damit links davon noch ein Bild mit fester Größe Platz findet. Außerdem sind unter dem Sprechblasen-Icon für Kommentare nur transparente Pixel, sodass in längeren Kommentaren keine anderen Hintergrundbilder auftauchen. Der Webseitenhintergrund ist gesondert als JPEG abgespeichert, da er keine Transparenz benötigt und so viel kleiner ist.

Komprimieren von Javascript, CSS und HTML

Das Komprimieren der eigentlichen Webseite ist auch nicht schwer. Da die Webseite sowieso dynamisch erstellt wird, lasse ich einfach sämtlichen zusätzlichen Whitespace im HTML weg. In den Templates bleibt alles schön übersichtlich, aber was gesendet wird, ist rund 10% kleiner.

Deutlich interessanter wird das ganze bei Javascript: Da Javascripts meistens statisch sind, habe ich mit ein einfaches Shell-Script geschrieben, welches alle Javascript-Dateien in eine Datei zusammenhängt um Reqests zu sparen und mit JSMin den Whitespace und Kommentare entfernt. So wird bei mir aus 19 kommentierten und nach Zweck getrennten Dateien mit rund 90 KB eine einzige mit 56 KB, also mit 30% Einsparung eine effektive Methode. Am einfachsten lässt es sich natürlich sparen, wenn man auf einiges an Javascript verzichtet.

#!/bin/sh
# Sammle alle js
for file in js/*; do
 cat "$file" >> javascript.js
 echo >> javascript.js # Leerzeile zwischen Scripts
done
./jsmin <javascript.js >>javascript.min.nocp.js # komprimieren
cat jslicences.txt javascript.min.nocp.js > javascript.min.js # Lizenzen hinzufügen
rm javascript.min.nocp.js

Beim CSS gilt ähnliches: Man kann alles in eine Datei packen und Whitespaces entfernen, jedoch habe ich keine automatische Komprimierung gefunden. Was man auf diversen Webseiten findet, spart normalerweise 10-20%.

PNG-Optimierung

Mit verlustfreier Komprimierung und trotzdem großer Farbpalette hat das PNG-Format Vorteile, wenn es um Icons und Graphiken geht. Doch aus der verlustfreien Komprimierung lässt sich noch mehr heraus kitzeln, indem man brute-force-mäßig die besten Kompressionsparameter verwendet. Das macht z.B. das einfach zu bedienende optipng und spart damit auch nochmal bis zu 15%.

CDN

Ein Content Delivery Network wird eher für besondere Seiten rentabel: Für Seiten mit viel statischem Content, also Bildern oder Videos. So entlastet man nicht nur den eigenen Server mit dem dynamischen Inhalt, sondern verteilt den Content über den ganzen Globus, sodass er dann nicht mehr so weit verschickt werden muss.

Für alle Seiten, die jQuery verwenden, ist es möglich sich dieses von Googles CDN hosten zu lassen. Dazu verwendet man einfach statt der URL der Javascript-Datei auf dem eigenen Server folgende: http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js und schon spart man sich wieder einige KB pro Seitenaufruf. Und auch die User sparen sich diese meistens. Da nämlich inzwischen sehr viele Seiten jQuery bei Google hosten, haben die meisten Surfer diese Datei schon im Cache des Browsers, müssen sie also nicht mehr herunterladen.

Kommentare: 3 Einträge
 
Χρόνογραφ
© 2008-2018 by Bernhard Häussner - Impressum - Login
Kurz-Link zu dieser Seite: http://1-co.de/bj