Astrofotografie vom Balkon: Plejaden und Komet Lovejoy

Eben habe ich nach langer Zeit mal wieder einen klaren Nachthimmel sehen – und fotografieren können. Zwar nur vom Balkon (schlecht), nicht nachgeführt (schlechter), in Berlin (noch viel schlechter) und ohne große Vorbereitung. Stativ aufgestellt, die kleine Olympus rauf, die Blende vom 17 mm-Objektiv aufgemacht und wieder eine halbe Blendenstufe zu auf f/2, Empfindlichkeit auf ISO 1600 eingestellt sowie drei Sekunden Belichtungszeit vorgewählt. Ausgelöst ohne Vorauslösung. Das Ergebnis ist durchaus in Ordnung.

Hauptziel war M45 – der Sternhaufen der Plejaden, dank des großen Blickwinkels ist aber noch eine Menge mehr zu erkennen. Markant sind die Hyaden mit dem rötlichen Aldebaran (ɑ Leo) im mittig im unteren Bildteil zu sehen. Oben links ist Capella (ɑ Aur) deutlich zu erkennen – zusammen mit Aldebaran kann man also immerhin schon ein Drittel des Wintersechsecks ausmachen :-)

Vergrößert man das Bild kann man den einen oder anderen offenen Sternhaufen aus dem Messier-Katalog erkennen, M36, M37 und M38 im Sternibild Fuhrmann seien exemplarisch genannt.

Als besonderer Bonus ist auf dem Bild der Komet C/2014 Q2 (Lovejoy) zu sehen – das habe ich selbst erst am Rechner bemerkt. Die grünlich-blaue Farbe des Objekts machte mich stutzig – nach einem kurzen Blick in Stellarium stellte sich dann raus, dass zufällig eben der Komet mit auf dem Bild zu sehen ist.

Ein erneutes Foto ließ sich dann nicht mehr anfertigen, da mittlerweile der Himmel bewölkt war :-(

Foto mit Anmerkungen
Foto mit Anmerkungen; verlinkt ist das Bild in Originalgröße

PHP: foreach vs. array_reduce

Ich habe letztens meine PHP-Library phpgeo mit Scrutinizer CI auf Code-Qualität untersuchen lassen. Es wurde an zwei Stellen Code-Duplication angemahnt, die ich dann auch gleich entfernt habe.

Dabei stieß ich auf eine foreach-Schleife, welche für die Berechnung der Länge einer Polyline (GPS-Track) zuständig ist.

Das Ergebnis der Schleife lässt sich auch wunderbar mit PHPs Funktion array_reduce berechnen. Die Frage war jetzt, ob ich es so lasse wie gehabt oder tatsächlich auf array_reduce umstelle.

Die betreffende Methode:

public function getLength(DistanceInterface $calculator)
{
    $distance = 0.0;

    if (count($this->points) <= 1) {
        return $distance;
    }

    foreach ($this->getSegments() as $segment) {
        $distance += $segment->getLength($calculator);
    }

    return $distance;
}

lässt sich auch so schreiben:

public function getLength(DistanceInterface $calculator)
{
    $distance = 0.0;

    if (count($this->points) <= 1) {
        return $distance;
    }

    return array_reduce(
        $this->getSegments(),
        function($carry, $item) use ($calculator) {
            return $carry + $item->getLength($calculator);
        }
    );
}

array_reduce müsste schon mindestens einen relevanten Vorteil gegenüber foreach bieten und außer der Geschwindigkeit und vielleicht ein bisschen mehr Eleganz fiel mir keiner ein. Die Geschwindigkeit lässt sich zum Glück schnell testen und ein kurzes Skript für diesen Zweck war schnell geschrieben:

<?php
/**
 * we need something to call
 */
function calculate_something($value) {
    return $value / ($value + 1);
}

$cycles = 100000;

// create some random data
$array = [];
for ($i = 0; $i < $cycles; $i ++) {
    $array[$i] = mt_rand(0, 0x7fffffff);
}

$timer['start'] = microtime(true);

$sumForeach = 0;
foreach ($array as $value) {
    $sumForeach += calculate_something($value);
}

$timer['foreach'] = microtime(true);

$sumArrayReduce = array_reduce($array, function($carry, $item) {
    return $carry + calculate_something($item);
});

$timer['array_reduce'] = microtime(true);

echo $sumForeach . " == " . $sumArrayReduce . PHP_EOL;
echo "foreach     : " . ($timer['foreach'] - $timer['start']) . PHP_EOL;
echo "array_reduce: " . ($timer['array_reduce'] - $timer['foreach']) . PHP_EOL;

Es zeigte sich, dass foreach deutlich schneller ist als array_reduce:

[mj@neptune:~/tmp]
% php test.php
99999.999335167 == 99999.999335167
foreach     : 0.068737030029297
array_reduce: 0.2411630153656

Wenn man darüber nachdenkt ist auch schnell klar warum das so sein muss: Für jeden Wert des Arrays wird in array_reduce ein – in PHP relativ teurer – Funktionsaufruf fällig (nämlich die Callback-Closure), was in foreach nicht notwendig ist.

Ende der Geschichte: Die Längenberechnung in phpgeo geschieht weiterhin in einer foreach-Schleife.

Es ist allerdings leicht vorstellbar, dass der Overhead eines Funktionsaufrufes bei anderen Anwendungen weniger ins Gewicht fällt und dort array_reduce die elegantere Alternative darstellen kann.

Cargolifter / Tropical Islands

Alle Jubeljahre fahre ich mit dem Mountainbike mal durch die Krausnicker Berge. Oben auf dem Wehlaberg steht seit 2003 ein Aussichtsturm, der einen schönen Blick auf die nur wenige Kilometer entfernte imposante Cargolifter-/Tropical Islands-Halle bietet.

Bei guter Sicht erkennt man von dort sogar die Wasserdampf-Wolken aus den Kühltürmen des über 90 km entfernten Kraftwerks Boxberg. Hier gibt’s noch einige Bilder aus dem Jahr 2007, die bei sehr guter Sicht gemacht wurden.

Cargolifter-/Tropical Islands-Halle

RSS: Der Weg von Google Reader zum Selbsthosting

Jahrelang ging in Sachen RSS eigentlich kein Weg am Google Reader vorbei: die zentrale Sammelstelle für RSS-Feeds bot zum einen ein sehr gutes Webinterface. Zum Anderen gab es – ganz Google-typisch – ein API, mit welchem alle möglichen RSS-Reader-Apps sprachen. So war es möglich seine Feeds am Desktop direkt im Google Reader „abzuarbeiten“ und dann unterwegs nahtlos z. B. in Reeder auf dem iOS-Gerät weiterzulesen.

Google entschied sich dann, den Google Reader zum 1. Juli 2013 abzuschalten. Die Benutzungszahlen waren wohl rückläufig und das Produkt erwirtschaftete vermutlich nicht ausreichend Umsatz*. Nun standen wir™ also da.

Innerhalb kürzester Zeit nach Googles Ankündigung wurden dann die möglichen Alternativen zusammengetragen (natürlich las ich über die meisten in meinen Feeds im Google Reader…). Dienste wie Feedly, Feedbin, Feed Wrangler und mehr standen nun zur Ablösung des Google Reader bereit. Auch Fever als selbst gehostete Variante war wieder eine Option.

Fever hatte aber auch 2013 noch das selbe Problem wie 2009 (schon damals hatte ich meine Lizenz gekauft): Es war ausschließlich im Webbrowser zu benutzen. Fever hatte zwar mittlerweile ein API bekommen, aber keiner der bekannten RSS-Client-Apps unterstützte diese. Schon gar nicht mein damals favorisierter RSS-Reader Reeder.

So wechselte ich vom Google Reader zu Feedly. Zum Glück hatten nämlich Feedly und die anderen Dienste das Potenzial erkannt und begannen Google Reader-kompatible APIs zu bauen. Und die App-Entwickler begannen gleichzeitig den Support für alternative APIs einzubauen. So dauerte es nicht sehr lange, bis Programme wie Reeder auch mit Feedly und Konsorten sprechen konnten.

Feedly war dann auch über ein Jahr meine RSS-Feed-Zentrale. Vor Kurzem bekam ich zufällig mit, dass Reeder* zwischenzeitlich auch etwas mit dem API von Fever anfangen kann und so probierte ich es noch mal. Und siehe da – es funktioniert genauso problemlos wie all die Jahre mit Google Reader und zuletzt mit Feedly.

Ich habe mir bei Feedly meine RSS-Abonnements als OPML-Datei ex- und diese bei Fever wieder importiert. Das ging alles sehr schnell und genau so schmerzfrei wie vor einem guten Jahr der Umstieg von Google Reader zu Feedly.

Mein Feed-Aggregator ist jetzt also seit einigen Wochen selbstgehostet und ich habe Feedly seitdem nicht eine Sekunde vermisst. Mein Account bei Feedly ist mittlerweile auch schon gelöscht.


Ich glaube Google Reader hatte nie Werbung eingeblendet; es dürfte also ein reines Verlustgeschäft für Google gewesen sein – zumindest finanziell

oder zwischenzeitlich neu erschienene RSS-Reader wie z. B. der sehr schöne Unread

FFmpeg beim Erstellen von Standbildern auf die Beine helfen

Um in einem Videoplayer Vorschaubilder beim Bewegen der Maus über die Zeitleiste anzuzeigen, erstellt man vom jeweiligen Video ausreichend viele Standbilder und gibt diese dem Videoplayer zeitcodiert mit.

Das Erstellen eines Standbildes kann mit FFmpeg (bzw. avconv unter debianoiden Linuxen) relativ einfach erledigt werden:

ffmpeg -y -i videofile.mp4 -ss 10 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

FFmpeg bekommt in diesem Beispiel mit mit dem Argument -ss 10 gesagt, im Video zum Zeitpunkt 10 Sekunden „vorzuspulen“ (im Sinne von „den ganzen Film decoden und an der entsprechenden Stelle anhalten“) und ein Standbild dieser Stelle abzuspeichern. Ist der Zeitpunkt nah am Anfang des Videos geht das recht schnell. Je weiter sich der Zeitpunkt vom Start entfernt, desto länger dauert der ganze Vorgang; wir reden hier von etlichen Sekunden schon bei relativ kurzen Videos von wenigen Minuten Länge. Wenn man jetzt z. B. 80 dieser Bilder aus einem Video benötigt, dauert das schnell mal an die 10 Minuten. Und wenn man dann nicht nur eins, sondern rund 30.000 Videos hat, wird’s schnell ungemütlich.

Zum Glück gibt es einen Trick, wie ich gestern gelernt habe: Fast-Seeking.

Hierbei springt FFmpeg an den dem Zeitstempel am nächsten liegenden Keyframe, von dort zum gewünschten Zeitstempel und erzeugt dann den Screenhot. Sehr praktisch und für den gegebenen Anwendungsfall absolut ausreichend.

ffmpeg -y -ss 10 -i videofile.mp4 \
-f image2 -s 1280x720 -vframes 1 \
-threads auto -an screenshot.jpg

Was hat sich im Befehl geändert? Lediglich die Position des Arguments -ss 10: Steht dieses vor dem Input-Argument (-i) aktiviert FFmpeg das Fast-Seeking. Wer möchte kann auch eine Kombination von Slow- und Fast-Seeking einsetzen (das nennt sich dann Combined Seeking), die Details kann man auf der Wiki-Seite nachlesen.

Damit war es möglich die Dauer für das Extrahieren der 80 Screenshots eines Videos von 10 Minuten auf 5 Sekunden zu reduzieren. Es liegen immerhin rund zwei Größenordnungen zwischen den Werten – damit sind dann auch 30.000 Videos durchaus in vertretbarer Zeit abzuarbeiten.

OS X und das Terminal – The Good Parts

Craig Hockenberry veröffentlichte einen umfangreichen Artikel zur Kommandozeilen-Arbeit unter OS X. Er vermittelt hauptsächlich Terminal- und Shell-Grundlagen, was aber nicht bedeutet, dass ein gestandener Unixer (der seine Terminal-Zeit vielleicht eher auf Linux-Maschinen denn unter OS X verbringt) hier nicht noch etwas lernen kann. Sollte man sich bookmarken, was ich hiermit auch tue :-)