Author Archives: alex

4 Replies

Vor einiger Zeit hatte ich im Beitrag Schicke Grafiken aus Matlab in LaTeX Möglichkeiten ausgelotet aus mit Matlab erzeugten Daten schicke Plots in LaTeX zu generieren. Sehr vielversprechend war dort das Paket pgfplots bei dem sich in den letzten Monaten einiges getan hat. Es liegt mittlerweile in Version 1.1 vor und hat neben dem Einbinden externer Datenquellen noch so manches dazugelernt. Ich möchte in diesem und einem folgenden Artikel an zwei Beispielen zeigen, wie man mit pgfplots tolle Ergebnisse produzieren kann.

Zunächst bleiben wir bei Matlab. Aus Matlab heraus ist es vergleichsweise einfach das .table-Format zu erzeugen, aus dem pgfplots Werte einlesen kann. Im einfachsten Fall benutzt man die Funktion dlmwrite. Will man auch noch Header und Kommentarzeilen in das Zwischenformat packen, muss man bisschen mehr Aufwand betreiben, ein entsprechendes Skript ist aber in kurzer Zeit fertiggestellt und bleibt dem geneigten Leser als Hausaufgabe überlassen. ;-) Meine Datei dahl_2008-08-19_05.table beginnt jedenfalls wie folgt:

time datadownsampled datadecimated dataresampled impactdownsampled impactdecimated impactresampled
7.2 0.0042314 0.0031181 0.0017701 7.6889e-005 7.5995e-005 4.3056e-005
7.201 0.010326 0.0048359 0.0049109 8.081e-005 8.0715e-005 8.7923e-005
7.202 0.013369 -0.0069568 -0.006471 7.9993e-005 8.087e-005 7.8394e-005
7.203 -0.011055 -0.010981 -0.011697 6.9248e-005 7.0035e-005 7.2734e-005

Es folgen knapp fünfhundert weitere Zeilen. Wie man bereits am Header sieht ist es empfehlenswert ein Downsampling der zu plottenden Daten vorzusehen, wenn eine Datenreihe mehr als ein paar hundert Elemente enthält. Diese spezielle Datei enthält in der ersten Spalte die Zeit, in den Spalten zwei bis vier ein Signal und in den Spalten fünf bis sieben ein zweites Signal. Für beide Signale wurden je drei verschiedene Downsampling-Verfahren ausgetestet, das jedoch nur nebenbei und zur Erläuterung, für den Plot werde ich nur die Spalten time und datadownsampled nutzen.

In LaTeX-Dokument sollten die notwendigen Pakete geladen sein, in diesem Fall sieht das bei mir so aus:

usepackage{tikz}
usepackage{pgfplots}
pgfplotsset{every axis plot/.append style={very thick}}

Die Einbindung selbst erfolgt wie gewohnt in einer float-Umgebung, die das ganze zentriert und auch noch label und Bildunterschrift bereit stellt. Statt includegraphics fügt man aber einfach eine tikzpicture-Umgebung ein:

begin{figure}[htb]
	centering
	begin{tikzpicture}
		begin{axis}[
			xlabel=Zeit (s),
			ylabel=Kraft (N),
			width=12cm,
			height=8cm]
		addplot[smooth,color=blue]
			table[x=time,y=datadownsampled] {plots/dahl_2008-08-19_05.table};
		end{axis}
	end{tikzpicture}
	caption{Rohdaten Messung texttt{dahl_2008-08-19_05}}
	label{fig:rohdaten_dahl_2008-08-19_05.txt}
end{figure}

Wichtig für das Lesen aus der externen .table-Datei ist die Anweisung table in der Zeile beginnend mit addplot. Das Ergebnis ist eine Vektorgrafik. Die Achsen sind wunderbar mit der im restlichen LaTeX-Dokument verwendeten Schrift beschriftet und zwar immer in der richtigen Größe. Mit extern als .eps oder ähnlichen Formaten eingebundenen Grafiken ist so etwas kaum möglich. Das Ergebnis spricht für sich:

Tiefenanordnung von Linien in Matlab-Plots

1 Reply

Heute geht es mal um ein sehr spezielles Problem mit einer Lösung auf die ich gestern durch Probieren gekommen bin und sehr erstaunt war, dass das so funktioniert und offenbar sogar so vorgesehen ist. Zunächst ein paar Worte zum ursprünglichen Problem.

Ich arbeite im Institut mit Matlab 6.1, zwar schon etwas in die Jahre gekommen aber brauchbar. Für die Auswertung meiner Messdaten habe ich ein GUI programmiert wo ich zwei verschiedene Sachen gleichzeitig in einem axes-Objekt darstellen will. Normalerweise kann man hier mit den Funktionen hold und plot arbeiten, aber mir war das zu unflexibel und ich habe daher gleich die LowLevel-Funktionen benutzt. Ich habe in dem GUI das gewünschte axes-Objekt. Direkt darunter in der Objekthierarchie kommen bereits die line-Objekte, die auch plot erzeugt. Von Hand kann man sich die mit dem Befehl line erzeugen, die landen dann in dem aktuellen axes-Objekt, das man zuvor mit axes(axeshandle) festlegen sollte. Bei der Erzeugung der line-Objekte speichere ich das line-Handle um später direkt wieder drauf zugreifen und beispielsweise die zugrundeliegenden Daten ändern zu können.

Soweit so gut, nun ist es so, dass ich nicht bestimmen kann, wann der Benutzer die eine Sache zum Plotten anklickt und wann die andere. Oben erscheint aber immer die zuletzt gewählte. Genauso verhält sich der Befehl plot. Was zuerst geplottet wird, landet hinten, die nachfolgenden Sachen darüber. Das ist bei vielen Darstellungen egal, bei einigen aber nicht.

Der Trick um die Darstellungsreihenfolge – oder englisch z-Order – zu ändern klingt ein wenig wie »von hinten durch die Brust ins Auge«, funktioniert aber wunderbar. Um zu verstehen, was dort gemacht werden muss, schaut man sich am besten nochmal die Objekthierarchie an. Ein axes-Objekt beherbergt beliebig viele line-Objekte. Die Handles dieser Objekte kann man sich ausgeben lassen:

linehandles = get(gca, 'Children')

Die einzelnen Elemente des Vektors linehandles haben genau die Reihenfolge der Anordnung in z-Richtung wobei das erste Element das zu oberst angezeigte ist. Es spricht nichts dagegen, die Elemente umzuordnen und dem axes-Objekt wieder zuzuweisen, z.B. in umgekehrter Reihenfolge:

set(gca, 'Children', flipud(get(gca, 'Children')))

Ich war einigermaßen überrascht, dass das tatsächlich so funktioniert, da ich in der ausführlichen Matlab-Hilfe nie darüber gestolpert bin. Dass das wirklich so vorgesehen ist, sagt einem Matlab selbst, wenn man versucht der Eigenschaft Children etwas anderes als ein umgeordnetes selbst zuzuweisen:

??? Error using ==> set
Children may only be set to a permutation of itself.

Damit das ganze noch ein wenig anschaulicher wird, habe ich noch ein kleines Skript geschrieben, dass die Sache nochmal illustriert:

% test data
a = rand(5,1)
b = rand(5,1)
c = rand(5,1)
% line handles
hp = plot([a b c])                  % hp in order we plotted
ha = get(gca, 'Children')           % reverse order
% vectors of line handles equal?
all(hp==ha)                         % not equal
all(hp==flipud(ha))                 % should be equal, see above
all(sort(hp)==sort(ha))             % also equal
% thick lines
set(ha, 'LineWidth', 10)
title('original order')
legend('a','b','c')                 % order as in plot call
print(gcf, '-dpng', 'z-order-original.png')
% color of the most front line, should be c
get(ha(1), 'Color')                 % should be red aka [1 0 0]
% now flip lines, put c in the back
set(gca, 'Children', [ha(2) ha(3) ha(1)])
title('flipped order')
print(gcf, '-dpng', 'z-order-flipped.png')
% color of the most front line, should be b
ha = get(gca, 'Children')
get(ha(1), 'Color')                 % should be green aka [0 0.5 0]

Schaut man sich hier die erzeugten PNG-Bilder an, erkennt man, dass die Linie für die Datenreihe c zunächst ganz vorn und dann ganz hinten dargestellt wird:

: drei zufällige Signale in normaler Reihenfolge

Alte Revisionen wiederherstellen mit Subversion

3 Replies

Im täglichen Umgang mit Subversion passiert es, dass man Dateien eincheckt, die man dann doch eigentlich nicht commiten wollte. Zum Glück kann man alte Revisionen wiederherstellen, dafür hat man ja das Versionsverwaltungssystem, man muss nur wissen wie.

Die erste Idee: revert – das funktioniert nicht, weil revert nur Änderungen an der lokalen Working Copy rückgängig macht, nach dem Commit kann revert nichts mehr ausrichten.

Die zweite Idee: update auf die ursprüngliche Version. Dann hat man in der Working Copy zwar zunächst mal die alte Version liegen. Man kann sie aber nich direkt commiten, weil Subversion sie für aktuell hält. Das ist sie im Grunde auch, nur halt in einer vorherigen Revision. Lokale Änderungen gibt es in dem Sinne nicht an der Datei. Bei Binärdateien kommt man an dieser Stelle nicht weiter, wenn man nicht jedesmal wieder ein update auf die alte Revision machen will.

Die dritte Idee: ins Handbuch schauen. Das exzellente Subversion-Buch hat natürlich auch zu dieser Problematik die passenden Tipps parat: Undoing Changes. (Wir arbeiten hier noch mit Subversion 1.4, daher der Link ins »alte« Buch.) Was auf den ersten Blick überraschend klingt: merge ist die Lösung für das Problem. Der Trick ist, dass wir dieses Mal rückwärts mergen. Dadurch gelangt die ältere Revision wieder in die Working Copy und nachdem man kontrolliert hat, ob damit alles stimmt, kann man die erneut commiten.

Genug der Vorrede, ich zeige den Vorgang mit dem Kommandozeilen-Client und mit TortoiseSVN am Beispiel. Ich habe hier eine Binärdatei driftcompgui.fig, die ich zuletzt in Revision 297 korrekt eingecheckt habe. In Revision 300 habe ich versehentlich eine falsche Version der Datei eingecheckt und möchte jetzt wieder die Version aus Revision 297 haben. Auf der Kommandozeile sieht das recht einfach aus (mit anschließendem Screenshot der Ausgaben):

svn merge -c -300 driftcompgui.fig

Wie man sieht liegt die Datei nun geändert in der Working Copy und zwar in der gleichen Version wie in Revision 297. Jetzt kann man die so einchecken oder noch weiter damit arbeiten. Bei TortoiseSVN erschließt sich diese Funktion aus dem GUI eher überhaupt nicht. Ich zeige zunächst mal den entscheidenden Screenshot und erkläre dann nochmal:

Hier wählt man zunächst im Feld »From:« die gewünschte Datei aus und klickt »HEAD Revision« an. Das ist sozusagen der Startpunkt des Rückwärts mergens. Bei »To:« natürlich »Use “From:” URL« auswählen, da es um die selbe eine Datei geht. Als Ziel Revision gibt man hier die an, die man wiederherstellen will, in meinem Fall 297. Jetzt kann man ohne weiteres auf »Merge« klicken und dann die Datei in der Working Copy untersuchen. Sollte irgendetwas nicht stimmen, kommt man mit revert wieder zur HEAD Revision, da wie bei jedem anderen Merge kein automatischer Commit passiert sondern die Änderungen des merge nur in der Working Copy landen. Wenn alles ok ist, kann man commiten und hat danach wieder die alte Version der Datei im HEAD des Repository.

Keys für Upgrade auf WordPress 2.6

5 Replies

Gestern kam mal wieder ein neues Update für WordPress. Wir setzen hier die DE-Edition ein und da gibt es auch eine detaillierte Anleitung zum Upgrade. Dort wird einem verraten, dass es für WordPress 2.6 neue Variablen in der Datei wp-config.php gibt. Der entsprechende Abschnitt in der wp-config-sample.php sieht so aus:

// Ändere jeden SECRET_KEY in eine beliebiege, möglichst einzigartige Phrase. Du brauchst dich später
// nicht mehr daran erinnern, also mache sie am besten möglichst lang und kompliziert.
// Auf der Seite https://www.grc.com/passwords.htm kannst du dir einen Ausdruck generieren lassen.
// Bitte trage für jeden SECRET_KEY eine eigene Phrase ein.
define('AUTH_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.
define('SECURE_AUTH_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.
define('LOGGED_IN_KEY', 'put your unique phrase here'); // Trage hier eine beliebige, möglichst zufällige Phrase ein.

Jetzt ist da eine Seite angegeben, auf der man sich diese Keys erzeugen lassen kann. Das ist für den DAU ganz nett, aber schrieb nicht fefe gerade die Tage:

Man sollte denken, niemand könnte je so unglaublich dämlich sein, sich einen Krypto-Schlüssel von jemand anderem generieren zu lassen

Glücklicherweise gibt es ja noch mehr Möglichkeiten zufällige Zeichenketten zu erzeugen. Eine davon habe ich vor einigen Monaten im Beitrag Kleiner Passwortgenerator in Perl vorgestellt. Was der Beitrag verschweigt: Ich hatte wenige Tage später noch eine kleine Anpassung an dem Skript vorgenommen, die es erlaubt, beim Aufruf die Anzahl der zurückzugebenden Zeichen als Parameter zu übergeben. So war es ein leichtes die nötigen Keys für die Konfigurationsdatei von WordPress zu generieren:

perl genpasswd.pl 64

Das veränderte Skript ist jetzt übrigens auch über Penguineering Tools abrufbar.

Security by Obscurity

2 Replies

Im April hatte ich über die Sicherheitslücke in Chipkarten des Typs Mifare Classic geschrieben, die auch als Studentenausweis an der Uni Magdeburg dienen. Der Hersteller InterCard hatte Anfang April angekündigt sich zügig mit seinen Kunden in Verbindung zu setzen. Davon hat man hier an der Uni bisher nichts gemerkt.

Unabhängig davon ist heute bekannt geworden, dass NXP, der Hersteller der Chips, eine niederländische Universität verklagt hat, damit die keine Paper zu der Thematik veröffentlichen. Fefe schreibt dazu:

Das sagt mir persönlich ja immer alles, was ich über eine Firma wissen muß, wenn die ihre Sicherheitslücken nicht fixen und dazu stehen sondern den Boten unter Beschuß nehmen.

Ich frage mich, wie die sich das vorstellen. Die Niederländer sind ja lange nicht die einzigen, die Details zu der Sicherheitslücke veröffentlicht haben. Da gab’s einen Vortrag auf dem 24C3, die c’t hat lang und breit drüber berichtet und all diese Informationen sind seit über einem halben Jahr öffentlich, lange genug Zeit also für böse Buben sich da schlau zu machen und das Wissen zu speichern. Viel interessanter ist die Frage, wie sie die bestehenden Systeme absichern oder auf neue Systeme migrieren wollen. Wäre glatt mal interessant beim hiesigen Studentenwerk anzufragen, ob der Hersteller schon Kontakt aufgenommen hat und was da möglicherweise hinsichtlich neuer Karten o.ä. geplant ist.

Homepage mit trac 0.10.x

Bilder automatisch drehen

3 Replies

Wir waren am Wochenende unterwegs und hatten die Kamera meiner Freundin dabei, eine Canon PowerShot S3 IS. Das ist jetzt soweit nichts besonderes. Man knipst Bilder, kopiert die später von der Speicherkarte auf den Rechner und dann ist der erste Schritt: Hochkant geschossene Bilder drehen. Auch das ist kein Problem. Die Kamera hat ja einen Lagesensor drin und speichert die Ausrichtung in den EXIF-Daten jedes einzelnen Bildes. XnView dreht die Bilder dann dank verlustfreier JPEG-Transformation in die richtige Lage. Wenn das alles so einfach und problemlos ist, warum kann die Kamera das nicht schon selbst machen? Der Bildprozessor, der da drin steckt, sollte leistungsfähig genug sein. Hab ich nur irgendwo eine Option in den Menüs der Kamera übersehen, oder geht das wirklich nicht? Gibt es andere Kameras, die das können und machen?

eisXen und eisfair-2 auf dem Weg

1 Reply

Nachdem ich gerade auf eisfair.org die Ankündigung gelesen habe, dass die Release Candidates von eisXen und eisfair-2 offiziell veröffentlicht wurden, kann ich ja hier auch ein wenig drüber plaudern. Die wichtigsten Weichen wurden ja bereits im November gestellt und einige kleinere Punkte sind auch noch offen, aber wir haben gerade eisXen in den letzten Wochen um einiges voran gebracht und ich freue mich, dass es jetzt im Rahmen des LinuxTag 2008 endlich der weiten Welt vorgestellt wird. Da es »nur« ein RC ist, hätte ich die Wette mit Tux Weihnachten 2007 zwar immernoch verloren, aber ich denke mit dem Input von den Nutzern wird das Projekt jetzt wieder Fahrt aufnehmen. Die Entwicklungsumgebung für eisfair-2 ist auch fast fertig, so dass dann auch bald die Pakete folgen werden.

antiblau blog

tech blog, another one …