ubuntuusers.de

Gimp ist die Bildbearbeitung für Webdesign mit Ubuntu. Jeder der Websites unter Ubuntu gestalten will braucht dazu Gimp. Wie man Gimp einrichtet so, dass keine Wünsche mehr offen bleiben, will ich euch hier zeigen.

Wer meint, er braucht auch unter Ubuntu Photoshop zum Webdesign, der kann sein Glück mit Wine versuchen. Ich bin der Meinung, das ist nicht nötig, aber, wenn man schon seit Jahr und Tag Photoshop benutzt, kann ich das verstehen.

Wir werden im Folgenden:

1. Paketquellen für Gimp und bestimmte Plugins hinzufügen
2. Gimp, die Plugin-Registry und den Resynthesizer installieren

Paketquellen installieren

Wir müssen nur eine PPAs installieren: und zwar die von Webup8.org, damit können wir den aktuellsten Stable-Release von Gimp und die Plugin-Registry installieren. Im Terminal eineinfach:

sudo add-apt-repository ppa:nilarimogard/webupd8
sudo apt-get update

Gimp, Plugin-Registrym, Resynthesizer in Ubuntu installieren

Gimp installiert ihr denkbar einfach, im Ubuntu App-Store, ich meine natürlich Software Center, nach Gimp suchen und auf installieren klicken. Analog installiert ihr die Registry (Paketname: gimp-plugin-registry) und den Resynthesizer (Paketname: gimp-resynthesizer).

Etwas schneller könnt ihr  Gimp mit den beiden anderen Paketen natürlich auch im Terminal installieren:

sudo apt-get install gimp gimp-plugin-registry gimp-resynthesizer


Das ganze sollte dann so aussehen:

Gimp bringt für das Webdesign schon eine ganze Menge Funktionen mit. Mit der Plugin-Registry und dem Resythesizer sollten kaum noch Wünsche für das Webdesign mit Ubuntu mehr offen sein.

Übrigens: Wenn ihr keine Lust habt, das selbst zu machen, könnt ihr auch einfach Rockiger OS installieren.

Gimp ist die Bildbearbeitung für Webdesign mit Ubuntu. Jeder der Websites unter Ubuntu gestalten will braucht dazu Gimp. Wie man Gimp einrichtet so, dass keine Wünsche mehr offen bleiben, will ich euch hier zeigen.

Wer meint, er braucht auch unter Ubuntu Photoshop zum Webdesign, der kann sein Glück mit Wine versuchen. Ich bin der Meinung, das ist nicht nötig, aber, wenn man schon seit Jahr und Tag Photoshop benutzt, kann ich das verstehen.

Wir werden im Folgenden:

1. Paketquellen für Gimp und bestimmte Plugins hinzufügen
2. Gimp, die Plugin-Registry und den Resynthesizer installieren

Paketquellen installieren

Wir müssen nur eine PPAs installieren: und zwar die von Webup8.org, damit können wir den aktuellsten Stable-Release von Gimp und die Plugin-Registry installieren. Im Terminal eineinfach:

sudo add-apt-repository ppa:nilarimogard/webupd8
sudo apt-get update

Gimp, Plugin-Registrym, Resynthesizer in Ubuntu installieren

Gimp installiert ihr denkbar einfach, im Ubuntu App-Store, ich meine natürlich Software Center, nach Gimp suchen und auf installieren klicken. Analog installiert ihr die Registry (Paketname: gimp-plugin-registry) und den Resynthesizer (Paketname: gimp-resynthesizer).

Etwas schneller könnt ihr  Gimp mit den beiden anderen Paketen natürlich auch im Terminal installieren:

sudo apt-get install gimp gimp-plugin-registry gimp-resynthesizer


Das ganze sollte dann so aussehen:

Gimp bringt für das Webdesign schon eine ganze Menge Funktionen mit. Mit der Plugin-Registry und dem Resythesizer sollten kaum noch Wünsche für das Webdesign mit Ubuntu mehr offen sein.

Übrigens: Wenn ihr keine Lust habt, das selbst zu machen, könnt ihr auch einfach Rockiger OS installieren.

The post Gimp für Webdesign appeared first on Rockiger.

PDF-Datei dieses Artikels erzeugen

Um mein Spanisch zu verbessern, möchte ich nebenbei spanische Radiosender hören. Blöderweise benutzen die meisten Flash-Player und verstecken die Live-Streams dazu zwischen Java-Script und HTML. Gibt es also keine Chance, die URL zum Stream zu ermitteln, damit ich diese Radiosender auch mit dem MPlayer hören kann? Doch gibt es, man muss sich die URL nur aus dem Quellcode der Seite und der Ausgabe eines Netzwerk-Sniffers wie tcpdump zusammenpuzzeln. Vermutlich gibt es mehrere Wege, die hier zum Ziel führen, ich habe es folgendermaßen gemacht:

Zuerst bin ich auf die Hompage des Radiosenders gesurft, in diesem Fall Cadena Dial. Um den Sender zu hören, klickt man auf den Link “Escucha en directo”. Auf dieser Seite befindet sich der Flash-Player. Um sie zu analysieren, habe ich sie mit dem Befehl wget heruntergeladen:

$ wget http://www.cadenadial.com/multimedia/radios.html
--2011-03-05 14:02:58--  http://www.cadenadial.com/multimedia/radios.html
Auflösen des Hostnamen www.cadenadial.com... 194.169.201.138
Verbindungsaufbau zu www.cadenadial.com|194.169.201.138|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 6416 (6,3K) [text/html]
In »radios.html« speichern.
 
100%[===================================================================>] 6.416       --.-K/s   in 0,08s   
 
2011-03-05 14:02:58 (83,4 KB/s) - »radios.html« gespeichert [6416/6416]

Alternativ kann man sich den Quellcode der Seite natürlich auch im Browser anschauen. Der Link zum Stream befindet sich in der Regel zwischen den iframe-Tags im HTML-Code, muss aber nicht. Eventuell muss man ein grep auf callsign selbst absetzen, oder man nimmt player als Suchwort.

grep iframe radios.html
<iframe src="http://player.streamtheworld.com/_players/unionradio/?callsign=CADENADIAL" ...</iframe>

Ich habe die Ausgabe auf den wichtigsten Teil reduziert, nämlich auf den Link für den Flash-Player. Hier muss man sich den Wert hinter callsign= merken, in diesem Fall also “CADENADIAL”.

Während der Radiosender im Flash-Player des Browsers vor sich hin spielt, startet man tcpdump, um herauszufinden, von welcher IP-Adresse der Player seinen Stream eigentlich bezieht.

# tcpdump -i wlan0 -n

Man kann tcpdump nur als Root starten. Hinter der Option -i gibt man das Interface an, auf dem gesnifft werden soll, die Option -n löst keine Hostnamen auf, sondern gibt die IP-Adressen zurück. Die Ausgabe sieht dann etwa wie folgt aus:

listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
14:21:20.622711 IP 208.92.52.88.80 > 192.168.178.22.59240: Flags [.], seq 3400577045:3400578485, ack 2642445401, win 1723, options [nop,nop,TS val 1395385741 ecr 1233879], length 1440
14:21:20.675395 IP 192.168.178.22.59240 > 208.92.52.88.80: Flags [.], ack 1440, win 947, options [nop,nop,TS val 1233930 ecr 1395385741], length 0
14:21:20.719510 IP 208.92.52.88.80 > 192.168.178.22.59240: Flags [.], seq 1440:2880, ack 1, win 1723, options [nop,nop,TS val 1395385837 ecr 1233879], length 1440

Sie zeigt vor allem zwei IP-Adressen, nämlich 192.168.178.22, das ist in diesem Fall die eigene, und 208.92.52.88, die Adresse des Servers mit dem Live-Stream. Genau genommen steht in der Ausgabe von tcpdump ja 208.92.52.88.80. Die letzte Zahl, zeigt die Portnummer an, in diesem Fall Port 80, hinter dem HTTP als Dienst steht. Jetzt haben wir alle notwendigen Infos, um den Link für den MPlayer in der Kommandozeile zusammenzusetzen:

mplayer http://208.92.52.88/CADENADIAL

Oder im AAC-Format:

mplayer http://208.92.52.88/CADENADIALAAC

Zuerst kommt der Befehl, um den Musikplayer zu starten, mplayer, dann der Dienst, über den kommuniziert werden soll, http://, dann die IP-Adresse des Servers 208.92.52.88 und zum Schluss kommt mit CADENADIAL das Verzeichnis zum Stream.

Auf dem Server sind übrigens noch weitere Streams von spanischen Radios beheimatet. Unter anderem auch von Los40. Während Cadena Dial fast ausschließlich spanisch sprachige Musik spielt, ist bei Los40 der Mix mit aktueller Musik aus den Charts etwas internationaler.

mplayer http://208.92.52.88/LOS40

Oder im AAC-Format:

mplayer http://208.92.52.88/LOS40AAC

Update:

Willie gibt in den Kommentaren einen Hinweis auf den chilenischen Sender Futuro, den man lieben wird, wenn man auf Heavy Metal und Hard Rock steht. Es könnte der Lieblingssender von Jara aus dem Film Gigante sein, wobei der Film in Uruguay spielt, nicht in Chile, er passt aber zur Musik im Film. Etwas abgewandelt bekommt man mit der hier beschriebenen Methode dann diesen Befehl zustande:

mplayer http://208.80.54.28/FUTURO

Die Qualität ist allerdings nicht so berauschend. Der Screenshot mit Firebug von Johannes in den Kommentaren zeigt, dass zumindest Cadena Dial auch im AAC-Format gestreamt wird, was die Qualität verbessern sollte. Und potz blitz, bei Futuro funktioniert dieser Stream auch:

mplayer http://208.80.54.28/FUTUROAAC

Die Qualität hört sich richtig gut an. Die anderen MPlayer-Befehle habe ich deshalb entsprechend erweitert. Vielen Dank für diese Hinweise und viel Spaß beim Hören.

Wer mehrere (Linux)Betriebsysteme parallel auf einem Rechner installiert hat, wird eventuell auch schonmal das zweifelhafte Vergnügen gehabt haben, den Grub (2) Bootmanager reparieren zu müssen. Wenn gleich Grub 2 theoretisch mit den meisten Linux Live-CDs zu reparieren ist, so ist es doch schöner, wenn man dann etwas zur Hand hat, das die Wiederherstellung erleichtert und beschleunigt.

Ich kannte bisher nur Super Grub Disk (2), wobei Super Grub Disk 2 den Nachteil hatte, dass nur von der CD gebootet und keine Änderungen auf die Festplatte geschrieben wurden.

Nachdem ich jetzt mal wieder mein Grub 2 zerschossen hatte, bin ich auf Rescatux auf der selben Seite aufmerksam geworden. Im Gegensatz zu den “Vorgängern” basiert dies auf Debian und bietet die Möglichkeit, sowohl Grub 1, als auch Grub 2 mit grafischer Oberfläche wiederherzustellen. Außerdem bietet das Tool die Möglichkeit an, ein Filesystem zu überprüfen. 

Die Erkennung der installierten Distributionen klappte bei mir problemlos - Wer sich also unter Umständen einige nervtötende Momente ersparen möchte, sollte vielleicht erstmal einen Blick darauf werfen.  Ein weiteres nützliches Tool zum einfachen Anpassen (z.B. Festlegen eines Hintergrundbildes, Ändern der Einträge oder der Anzeigedauer) des Bootmanagers ist (mit grafischer Oberfläche) Grub Customizer. 

Eigentlich wollte ich ja jetzt was Tolles über die Linux, Ubuntu und Open-Source auf der Cebit 2011 schreiben, aber leider habe ich nichts spannendes gefunden.

Das Beste war noch das Gewinnspiel von B1, die einen schielenden Tux verlost haben. Er erinnert mich an das Opossum Heidi - wahrscheinlich weil er auch zu dick ist.

Ausgestellt haben nur die üblichen Firmen in Halle 2 und im Open-Source-Park waren ein paar unerschütterliche Open-Source-Projekte wie Enlightenment, Firefox und LibreOffice zu sehen - die den Menschen Open-Source näher gebracht haben.

Wirkliche Neuerungen oder spannende Projekte wie Qt, Android, etc. habe ich aber leider keine entdeckt - schade eigentlich.

Apropos Android in Halle 16 wurden gefühlte 100.000 Android-Tablets ausgestellt. Scheinbar der Megatrend für 2011.

Als ich dies das letzte mal vor ein paar Jahren ausprobiert hatte bin ich kläglich gescheitert. gorc war einfach mies und Abby musste her.

Nun die Tage musste ich mal wieder einen etwas längeren Text (ca. 50 Seiten) einscannen und in ein LaTeX-Dokument hieven und habe es mal wieder mit Linux probiert und siehe da, es gibt neue Tools und mit denen funktioniert es wunderbar!

Scannen
Zuerst musste das ganze mal eingescanned werden, was ich mit scanimage gemacht habe. Auflösung von 300dpi sollte ausreichen und Graustufen-Modus:

$ scanimage -d epson2:libusb:001:004 --mode Gray --resolution 300dpi -x 186 -y 250 > 33.pnm

OCR Vorbereitung
Zur Vorbereitung der OCR habe ich Tools von ImageMagick und Scan Tailor benutzt.

Zuerst einmal waren die Seiten verdreht was mit dem Befehl:

$ mogrify -rotate 90 *.pnm

schnell behoben war (Scan Tailor kann das auch aber das hab ich erst danach gemerkt..). Damit ich die Seiten mit Scan Tailor bearbeiten konnte mussten sie ins tif-Format, was dieser Oneliner erledigt (ZSH!!):

$ for i in *.pnm; do convert $i ${i:r}.tif;done

Nun kam Scan Tailor dran. Damit konnte ich problemlos die Seiten richtig ausrichten, unnötiges an den Rändern wegschneiden, Kontrast verbessern, usw.. Wirklich ein Hammertool um Bilder auf OCR vorzubereiten!

OCR
So und hier kam das Tool tesseract zum Einsatz, welches mich gnadenlos überzeugt hat! Die Texterkennung war fantastisch, bei über 99%. Probleme gab es nur an Stellen wo der Text Unterstreichungen hatte, was zum Glück nur sehr selten war ansonsten wäre das Ergebnis sicher schlechter gewesen, denn an diesen Stellen hat sich tesseract die Zähne ausgebissen.

Das Konvertieren hat auch hier wieder ein ZSH-Oneliner erledigt:

$ for i in *.tif;do tesseract $i ${i:r} -l deu;done

Hier sollte man aufpassen, dass man als Input die von Scan Tailor verbesserten *.tif Dateien nimmt und nicht die anfänglich erzeugten

So der Durchlauf von tesseract dauert ein bischen und wenn er fertig ist, dann kann man das alles in ein Dokument zusammenbasteln:

$ cat *.txt > dokument.txt

und ist fast fertig!

LaTeX

Man hat jetzt nämlich immernoch das Seitenlayout des gescannten Dokumentes, also die Zeilen sind so lange wie in dem ursprünglichen Dokument und natürlich sind die Wörter auch so getrennt.. Das ist natürlich uncool wenn man das ganze in ein LaTeX-Dokument verwandeln will. Um das zu beheben habe ich ein kleines Skript geschrieben. Das setzt Absätze im LaTeX-Dokument, wo im Originaldokument welche sind und löst das Problem mit den Zeilenenden.

Danach einbischen Nachbearbeitung mit TeXMaker und das wars.

Hey,
ich wollte euch auf dieses coole Skipt vom 360 percents Blog aufmerksam machen mit dem man myspace Lieder runterladen und nach mp3 konvertieren kann.

Als Abhängigkeiten benötigt es rtmpdump zum Herunterladen und ffmpeg zum Konvertieren.

Heute wurde die 3. Alpha Version von Ubuntu 11.04 Natty Narwhal freigegeben!

Diese Version ist immernoch eine Alpha und sollte wie immer noch nicht auf einem Produktiven System eingesetzt werden!

Downloads finden sich hier: Alpha 3

Release Schedule:

Nach meiner Woche mit Android auf dem Freerunner bin ich jetzt dank des Tipps von Lukas zu SHR gewechselt. Android Cupcake funktioniert auf dem Openmoko Freerunner reibungslos, soweit ich das in einer Woche beurteilen kann. Nervig ist bloß, dass man es innerhalb von 24 Stunden mindestens einmal aufladen muss, auch wenn man nicht wirklich viel damit gemacht hat. Der Stromverbrauch ist einfach recht hoch. Da scheint SHR etwas länger durchzuhalten, wenn man Dienste wie WLAN, Bluetooth oder GPS wirklich nur dann aktiviert, wenn man sie braucht, den Freerunner immer fleißig in den Suspend schickt und die Helligkeit des Displays standardmäßig etwas herunter dreht. Das Stable Hybrid Release (SHR) ist eine freie GNU/Linux-Distribution, die es nicht nur für das OpenMoko, sondern auch für andere Smartphones wie dem N900 von Nokia, dem HTC Dream, oder dem Palm Pre gibt. Außerdem ist es wirklich eine Distribution für Frans von Gnu/Linux und Freier Software, weil man von Anfang an viel selber machen darf. Die Installation ist zwar ein bisschen komplizierter als bei Android, klappt aber trotzdem sehr gut.

Die Installation von SHR auf dem OpenMoko GTA02 mit Ubuntu

Bevor man SHR auf den Freerunner flashen kann, muss man das Paket dfu-util installieren.

sudo apt-get install dfu-util

Anschließend benötigt man die Dateien zum Flashen. Da ich SHR als User einsetzen möchte, habe ich mich für SHR-testing entschieden und neben Qi als Bootloader das entsprechende Rootfs und Kernelimage heruntergeladen:

wget http://build.shr-project.org/shr-testing2011.1/images/om-gta02/qi-s3c2442.udfu
wget http://build.shr-project.org/shr-testing2011.1/images/om-gta02/full-om-gta02.jffs2
wget http://build.shr-project.org/shr-testing2011.1/images/om-gta02/uImage-om-gta02-latest.bin

Damit beim Flashen gleich alles glatt läuft, bereitet man den Ubuntu-Rechner schon mal vor und startet ein Terminal und bekommt mit dem Befehl sudo -s Root-Rechte.

Das Telefon schaltet man am besten aus, falls es noch an ist, und bootet ins NOR-Menü, in dem man erst die Taste AUX und dann die Taste POWER für ein paar Sekunden gleichzeitig gedrückt hält. Jetzt muss man sich beeilen, weil der Freerunner nach 30 Sekunden Inaktivität wieder abschaltet. Mit dem USB-Kabel verbindet man das Smartphone mit dem Ubuntu-Rechner und führt im Terminal, in dem man Root geworden ist, folgenden Befehl aus, um den Bootloader Qi zu überspielen:

dfu-util -a u-boot -R -D qi-s3c2442-master-hist_3b8513d8b3d9615e.udfu

Danach folgt das RootFS:

dfu-util -d 0x1d50:0x5119 -a rootfs -R -D full-om-gta02.jffs2

Wenn der Befehl erfolgreich ans Freerunner abgesetzt worden ist, sieht man einen Fortschrittsbalken in Form von Raute-Zeichen im Terminal.

Das Aufspielen des RootFS dauert eine Weile, aber man sollte das Ende nicht verpassen, denn sonst schaltet sich das Telefon nach 30 Sekunden Inaktivität wieder aus, obwohl man noch den Kernel aufspielen muss:

dfu-util -d 0x1d50:0x5119 -a kernel -R -D uImage-2.6.34-r7-oe17-om-gta02.bin

Mit NeoTool gibt es auch eine grafische Oberfläche für das Flashen. Da es kein Paket für Ubuntu oder Debian gibt, lädt man sich das Shell-Skript am besten direkt herunter. Die notwendigen Pakete, die man benötigt, um das Skript laufen zu lassen, wie bash, which und awk, sollte es in einer Ubuntu-Installation schon geben, zenity muss eventuell noch installiert werden.

Genauso wie dfu-util muss man auch NeoTool als Root starten, was zum Beispiel mit sudo bash neotool funktioniert.

Welchen Weg man auch geht, nach dem Flashen der drei Dateien steckt man das USB-Kabel wieder ab, schaltet das Telefon aus und bootet es neu, indem man auf den POWER-Knopf drückt.

Freerunner mit Ubuntu verbinden

Wenn man nach dem Neustart des Freerunners Telefon und Computer wieder mit dem USB-Kabel verbindet, wird es als Netzwerkadapter erkannt. Welcher Netzwerkadapter das ist, verrät der Befehl ifconfig im Terminal:

ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse 00:1d:72:12:a0:d1  
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:16 
 
eth2      Link encap:Ethernet  Hardware Adresse 00:1f:11:01:5b:25  
          inet6-Adresse: fe80::21f:11ff:fe01:5b25/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:152 (152.0 B)  TX bytes:2178 (2.1 KB)
[...]

Im Normalfall heißt das Interface usb0, aber man sollte sich auch nicht irritieren lassen, wenn es anders heißt. In diesem Fall ist es eth2, das man mit folgender IP-Adresse verbindet:

sudo ifconfig eth2 192.168.0.200 netmask 255.255.255.0

Danach kann man mit Secure Shell (SSH) ein Terminal auf dem Freerunner starten. Per default ist der Schnittstelle des Freerunners die IP-Adresse 192.168.0.202 zugeteilt:

ssh root@192.168.0.202

Wenn root@om-gta02 ~ # als Prompt erscheint, hat man es geschafft und ist auf der Shell des Freerunners gelandet.

SHR mit WLAN verbinden

Um den Freerunner mit WLAN zu verbinden, kann man entweder das Programm Iliwi auf dem Desktop des Telefons starten und das Netzwerk auswählen, oder man macht das ganze auf der Konsole. Dann muss man aber unter Settings WLAN manuell starten.

Dann gibt man im Terminal die folgenden beiden Zeilen ein:

wpa_passphrase MeinWLAN "MeinPasswort123" > /etc/wpa_supplicant/wpa_supplicant.conf
fsoraw -r WiFi -- wpa_supplicant -ieth0 -Dwext -c /etc/wpa_supplicant/wpa_supplicant.conf &

Am Ende der zweiten Zeile ist ein “&”. Lässt man das weg, blockiert der Aufruf des Befehls das Terminal und man muss eine zweite SSH-Verbindung zum Freerunner öffnen, um mit folgenden Befehlen weitermachen zu können:

ifconfig eth0 up
udhcpc

Am Ende sollte es im Terminal folgendermaßen aussehen, wenn man verbunden ist:

SHR updaten

Nun kann man erstmal das Betriebssystem updaten:

opkg update && opkg upgrade

Danach ist es gut, eine deutsche Tastatur zu bekommen, weil sich eine SMS ohne Umlaute doch blöd schreibt:

opkg install illume-keyboard-german

Damit man die deutsche Tastatur auch auch ohne Neustart des Telefons auswählen kann, reicht es aus, den X-Server neu zu starten.

/etc/init.d/xserver-nodm restart

Die Tastatur aktiviert man übrigens mit dem kleinen Button oben links, der sich gleich rechts neben dem kleinen Häuschen befindet, das einen übrigens immer zum Desktop bringt.

Wie geht es weiter?

Jetzt ist man gut gerüstet, SHR weiter zu erforschen. Dazu sollte man sich auch unbedingt in der Mailingliste eintragen, um über wichtige Änderungen informiert zu werden, oder man schaut im IRC vorbei. Die Homepage des SHR-Projekts ist natürlich auch ein wichtiger erster Anlaufpunkt, genauso wie das User Manual von SHR im Wiki von OpenMoko. Welche Pakete man unbedingt auf dem Freerunner braucht, findet man ebenfalls in dem Wiki. Und wie geht es hier weiter? Angeregt durch einen Artikel auf penguinpower.de will ich meine eigenen kleinen Apps basteln, um SHR besser an meine Bedürfnisse anzupassen.

Vor langer Zeit haben ich schon einmal ein Tutorial geschrieben wie man einen Lomo Effekt in Photoshop erzielen kann. Nun Zeige Ich euch wie es in Darktable geht.

Zuerst aber was ist überhaupt Lomo, oder Lomographie?
Der Lomo Fotoapparat ist ein “veralteten” russischen Kamera, welche der KGB 1982 in Auftrag gab. Sie ist eigentlich nur ein Kopie einer japanische Kompaktkamera (Cosina CX-1) und sollte eigentlich  zu Spionagezwecke eingesetzt werden….
Wie die Geschichte weitergeht könnt ihr wie so oft bei Wikipedia nachlesen.

So was sind nun eigentlich die charakteristischen Eigenschaften eines Fotos, aus solch einer Lomo-Kamera?  Die Fotos sind meistens sehr kontrastreich, farbintensiv und haben eine deutlich sichtbare Vignettierung. Es hängt zum Teil natürlich auch vom verwendetet  Filmmaterial ab, wie stark diese Eigenschaften ausgeprägt sind. Dieses Tutorial ahmt diese Charakteristika nur nach. Richtige LomographInnen werden solche Fotos sowieso nicht mit eine Digitalkamera machen und immer den Film bevorzugen.

Für richtige Lomographie gibt es auch noch 10 Regeln:

Die 10 goldenen Regeln der Lomographie:

1. nimm die Kamera mit, wo immer Du gehst
2. benutze sie tag und nachts
3. Lomographie ist ein Teil deines Lebens
4. bring die gewünschten Objekte so nahe wie möglich an die Linse
5. denke nicht
6. sei schnell
7. es ist vorher nicht wichtig zu wissen, was Du auf den Film gebannt hast
8. erst recht nicht nachher
9. “schiesse” aus der Hüfte
10. denke nicht über Regeln nach

Im Video Zeige ich euch wie Ihr den “Lomostyle” imitieren könnt. Am besten schaut Ihr es euch als HD auf Vimeo an.

als HD Video

Und noch das Foto zum Tutorial.

Zu guter Letzt habe ich noch ein Pressset für den Lomo Effekt zum Download:

Lomo Effekt (567)

Das Verhältnis zwischen den Open Source Projekten und ihren Distributionen ist ein sehr besonderes. Die Distributionen brauchen die Open Source Projekte, denn ohne sie haben sie nichts zu paketieren und die Open Source Projekte brauchen die Distributionen um den Quellcode zu verteilen – wie der Name schon sagt. Dieses Verfahren ist so eingespielt, dass richtig große Open Source Gemeinschaften wie z.B. KDE überhaupt keine Pakete bereitstellen, sondern nur den Quellcode zum Download anbieten. Im Falle KDE sind die Distributionen so eingebunden, dass sie Zugriff zu den Quellcode Paketen eines neuen Releases bekommen bedeutend vor dem Rest der Welt (mich eingeschlossen) um Pakete rechtzeitig zum Release bereitstellen zu können.

Die Beziehung zwischen den Open Source Projekten und ihren Distributionen ist so speziell, dass sie sogar eigene Namen haben. Die Open Source Projekte bezeichnen sich als "Upstream" und die Distributionen als "Downstream". Das Projekt ist also flußaufwärts und der Quellcode strömt zur Distribution den Fluß hinunter. Patches, die von den Distributionen zurück an die Projekte fließen, wir mit "to upstream" bezeichnet.

Mir persönlich ist das Verhältnis zu den "Downstreams" sehr wichtig. Ich kenne die Paketbetreuer unserer wichtigsten Distributionen und helfe regelmäßig falls es darum geht KWin besser in die Distribution zu integrieren und Bugreports von "Downstream" werden von mir priorisiert behandelt. Genauso wie einem als Upstream die Downstreams wichtig sind, erwartet Upstream auch, dass Downstream sich um Upstream kümmert. Einer der Punkte, die einem da sehr wichtig sind, ist die Anzahl der Patches, die Upstream integriert. Von einer guten Downstream erwartet man, dass Patches geupstreamed werden. Wenn nicht stellt sich immer die Frage: warum? Hier erfolgt dann sehr oft der Vorwurf, dass Distributionen ihre Upstreams kaputt patchen.

Natürlich ist es einer Downstream erlaubt den Quellcode zu verändern und zu verbreiten. Dies ist durch die dritte Freiheit der Free Software Definition klargestellt:

The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Wer die Open Source Welt in den letzten Tagen verfolgt hat, dem dürfte klar sein auf was ich mit meiner Einleitung hinaus wollte: dem Fall Banshee und Canonical oder verallgemeinert Upstream und Downstream. Zu dem Fall an sich will ich gar nichts mehr sagen. Das haben andere schon viel besser erledigt.

Für mich als Maintainer einer Upstream Software ist das Verhalten der Downstream aber ein sehr interessanter Fall zum Studieren und ich bin mir sicher, dass sehr viele Upstream Entwickler den Fall sehr genau betrachten und auch andere Downstreams schauen sehr genau darauf. Faktisch ist alles klar: Canonical hat durch die dritte Freiheit das Recht den Code zu ändern in welcher Art sie wollen. Ob sie es sollen ist eine andere Sache. Ich möchte hierzu den relevanten Quellcode in Banshee zitieren:

// We ask that no one change these affiliate codes. ALL (100%) revenue
// generated by these affiliate IDs is sent directly to the GNOME
// Foundation. The GNOME Foundation controls/owns these affiliate IDs.
// Please help support Free Software through the GNOME Foundation!

Ob es nun moralisch vertretbar ist, dass ein Unternehmen diesen Code ändert um selbst Profit daraus zu ziehen, muss im Endeffekt jeder selbst entscheiden. Für mich persönlich ist es befremdlich zu sehen, dass eine Downstream gegen den Wunsch des Upstream Projekts den Code ändert – auch wenn es ihr gutes Recht ist. Für mich als einer der vielen altruistisch arbeitenden Open Source Entwickler ist es noch befremdlicher zu sehen, dass das Geld eigentlich an eine gemeinnützige Organisation gehen soll. Der finanzielle Beitrag ist dabei übrigens eher marginal. Banshee bringt aktuell etwa 10.000 $ pro Jahr ein. Wir können nicht wissen wie viel Ubuntu beisteuern würde, aber meine Vermutung ist, dass es nicht viel mehr wäre. Der aktuelle Beitrag reicht vllt. um einen Entwickler einen Monat zu finanzieren oder aber um einen Sprint auszurichten. Ich überlasse die Bewertung dessen dem Leser.

Der "Skandal" ist für mich aber nicht, dass Canonical den Code geändert hat, sondern das Vorgehen. Zuerst eine Diskussion mit den Entwicklern zu starten und zwei Optionen zur Wahl zu stellen und danach einstimmig zur abgelehnten Option umzuschwanken, ist meiner Meinung nach mehr als nur schlechter Stil. Persönlich denke ich auch, dass hier das Hauptproblem ein Kommunikationsproblem von Seiten Canonicals war. Und ich meine nicht, dass überhaupt Optionen angeboten werden, wie Mark Shuttleworth es nun verteidigt hat, sondern dass man das Upstream Projekt falsch angesprochen hat.

Als Distribution muss man seine Upstreams kennen. Bei den zwei Optionen hätte es Canonical bereits im Vorfeld klar sein müssen, wie sich die Entwickler entscheiden. Canonical hätte also wissen müssen dass die gewünschte Option nicht gewählt wird und das anschließende Erzwingen stößt jeden Entwickler nur vor den Kopf. Natürlich wäre nicht zu kommunizieren genauso falsch gewesen, genauso wie zu kommunizieren, dass man das jetzt einfach so macht. Ich halte es aber für durchaus denkbar, dass man die Community so führen kann, dass sie selbst den Vorschlag zum Aufteilen der Einnahmen erbringt – wenn es unbedingt sein muss. Eine klare Aufgabe für einen Communitymanager – den Ubuntu ja hat.

Canonical hat sich mit der gesamten Geschichte einen riesigen Bärendienst erwiesen. Canonical und auch Ubuntu stehen schon länger unter genauer Beobachtung von Upstream Projekten. Immer wieder mehren sich die Vorwürfe, dass Canonical nur nimmt und nicht gibt (vgl. Diskussion zu Quellcode Beiträge zu Kernel und GNOME). Immer wieder wird auch die Art und Weise wie Canonical mit der Community umgeht kritisiert (vgl. Copyright Assignment, Ayatana, Unity). Persönlich habe ich auch schon sehr lange und intensiv mir Gedanken zu Canonical gemacht und auch immer wieder gefragt, ob Canonical überhaupt Open Source versteht. Für mich passt (leider) das aktuelle Geschehen in mein Bild von Canonical – denken viele Entwickler so, dann ist dies eine sehr gefährliche Entwicklung für Canonical. Verscherzt es sich Canonical zu stark mit allen Upstream Projekten, dann stehen sie sehr alleine dar und ob sie dafür Manpower und Kompetenz auf allen Feldern haben, ist mehr als fraglich.

Hinweis: in diesem Text fehlen viele Fußnoten. Ich habe mich aus aktuellem Anlass dazu entschlossen meine Quellen nicht anzugeben und überlasse dem Leser das Suchen der Quellen selbst. Bei der großen Anzahl von Quellen zu diesem Blogpost habe ich leider den Überblick verloren, dennoch ist es kein Plagiat, auch wenn Gedanken aus anderen Quellen übernommen worden. Dies sieht man schon daran dass alle nicht angegebenen Quellen auf Englisch sind und dieser Post auf Deutsch.

=-=-=-=-=
Powered by Blogilo

Um FFmpeg in vollem Umfang nutzen zu können, muss man es selber aus dem Quellcode kompilieren. Natürlich reichen die normalen Ubuntu-Pakete für den standard User, allerdings benötigt man z.B. für .flv-Videos die selbst kompilierte Version. Dies kann ganz einfach realisiert werden. Weiter unten findet sich auch ein guide um die Pakete zu aktualisieren

FFmpeg und x264 kompilieren und installieren

1. Zuerst einmal müssen eventuell bereits installierte deinstalliert werden:
   
sudo apt-get remove ffmpeg x264 libx264-dev

2. Benötigte Pakete zum Kompilieren installieren:
   
sudo apt-get update
sudo apt-get install build-essential git-core checkinstall yasm texi2html \
libfaac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev \
libopencore-amrwb-dev libsdl1.2-dev libtheora-dev libva-dev libvdpau-dev \
libvorbis-dev libvpx-dev libx11-dev libxfixes-dev libxvidcore-dev zlib1g-dev

3. Aktuelle Quelldateien von x264 hohlen, kompilieren und installieren:
   
cd
git clone git://git.videolan.org/x264.git
cd x264
./configure
make
sudo checkinstall --pkgname=x264 --pkgversion="3:$(./version.sh | \
awk -F'[" ]' '/POINT/{print $4"+git"$5}')" --backup=no --deldoc=yes \
--fstrans=no --default

4. Aktuelle Quelldateien von FFmpeg hohlen, kompilieren und installieren:
   
cd
git clone git://git.videolan.org/ffmpeg.git
cd ffmpeg
./configure --enable-gpl --enable-version3 --enable-nonfree --enable-postproc \
--enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb \
--enable-libopencore-amrwb --enable-libtheora --enable-libvorbis \
--enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab
make
sudo checkinstall --pkgname=ffmpeg --pkgversion="5:$(./version.sh)" --backup=no \
--deldoc=yes --fstrans=no --default
hash x264 ffmpeg ffplay ffprobe


Damit ist man auch schon fertig! Wie man x264 in Verbindung mit FFmpeg benutzt, findet sich hier: http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/

FFmpeg und x264 updaten

Da man die Pakete selber kompiliert hat, muss man auch manuell die Updates einspielen , falls es welche gibt. Dies bringt teilweise neue Features bzw. Bugfixes

1. Zuerst werden x264 unf FFmpeg deinstalliert und die Abhängigkeiten aktualisiert.
   
sudo apt-get remove ffmpeg x264 libx264-dev
sudo apt-get update
sudo apt-get install build-essential git-core checkinstall yasm texi2html \
libfaac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev \
libopencore-amrwb-dev libsdl1.2-dev libtheora-dev libva-dev libvdpau-dev \
libvorbis-dev libvpx-dev libx11-dev libxfixes-dev libxvidcore-dev zlib1g-dev

2. x264 source code aktualisieren:
   
cd ~/x264
make distclean
git pull

3. danach x264 kompilieren und installieren:
   
./configure
make
sudo checkinstall --pkgname=x264 --pkgversion="3:$(./version.sh | \
awk -F'[" ]' '/POINT/{print $4"+git"$5}')" --backup=no --deldoc=yes \
--fstrans=no --default

4. FFmpeg source code aktualisieren
   
cd ~/ffmpeg
make distclean
git pull

5. FFmpeg kompilieren und installieren
   
./configure --enable-gpl --enable-version3 --enable-nonfree --enable-postproc \
--enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb \
--enable-libopencore-amrwb --enable-libtheora --enable-libvorbis \
--enable-libvpx --enable-libx264 --enable-libxvid --enable-x11grab
make
sudo checkinstall --pkgname=ffmpeg --pkgversion="5:$(./version.sh)" --backup=no \
--deldoc=yes --fstrans=no --default
hash x264 ffmpeg ffplay ffprobe


Ich hatte am vergangenen Wochenende einige Sachen im Board umgestellt. Soweit ja kein Problem. Nur hat nun der Link der bei Google auf meine TrueCrypt-FAQ gezeigt hat (http://www.operation-tunnelbau.de/index.php?topic=27.0), nicht mehr gepasst. Diesen wollte ich nun auf das Wiki umleiten. Und was soll ich sagen? Ich hasse Htaccess, RewriteCond und RewriteRule. Naja eigentlich bin ich vermutlich einfach zu blöd dazu. Hier nun des Rätsels Lösung. Vielleicht hilft das den einen oder anderen ja weiter.

RewriteCond %{SCRIPT_FILENAME} index.php 
RewriteCond %{QUERY_STRING} topic=27\\.0
RewriteRule ^(.*)$ http://www.wiki.operation-tunnelbau.de? [L,R=301]

Im Grunde eigentlich nicht schwer und Gott sei Dank ohne kompliziertes Regex. Sonst wäre es komplett vorbei gewesen.