@ -0,0 +1,11 @@
|
||||
+++ |
||||
title = "{{ replace .Name "-" " " | title }}" |
||||
date = "{{ dateFormat "2006-01-02" .Date }}" |
||||
author = false |
||||
cover = "icon.jpg" |
||||
tags = [""] |
||||
keywords = ["", ""] |
||||
description = "" |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
@ -0,0 +1,84 @@
|
||||
+++ |
||||
title = "DDO Prototype" |
||||
date = "2014-11-30" |
||||
author = false |
||||
cover = "skizze.jpg" |
||||
tags = ["programmierung"] |
||||
keywords = ["ddo", ""] |
||||
description = "DDO - Der Kilometerzähler im Arduion-Derivat." |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
|
||||
Aufgabenstellung |
||||
Früher hatte ich mal so einen Kilometerzähler am Vorderrad meines Rennrads, sehr zum Leidwesen meiner Radkollegen, da das Ding ziemlich laut klackerte. |
||||
|
||||
 Analoger Kilometerzähler |
||||
|
||||
Das gleiche soll nun mit moderner Technik neu gebaut werden - aber ohne Klackern, wenn's geht. |
||||
|
||||
Schaut man sich auf dem Markt um, was es derzeit gibt, so findet man den Bikelogger. Der kann mehr einiges mehr als nur den aktuellen Stand zählen. Der Preis ist mit ca. 140 € aber ziemlich hoch. Cool ist, das er kein Kontakt-Kontakt für die Bewegungserfassung benötigt. |
||||
|
||||
Den Zähler, den ich mir vorstelle, soll einfach nur die Laufleistung zählen und ansonsten nicht weiter auffallen. Es muss völlig wartungsfrei und ohne Schnickschnack sein. Außerdem soll er aus möglichst wenigen Bauteilen bestehen und die vorhanden Infrastruktur am Rad nutzen. Bei Bedarf kann man den aktuellen KM-Stand per Smartphone abfragen, |
||||
|
||||
|
||||
Komponenten |
||||
Man benötigt einen Mikrocontroller zur Steuerung, ein EEPROM zum Speichern und eine stabile Spannungsversorgung. |
||||
|
||||
Als Mikrocontroller habe ich mich für den RFduino entschieden, da er sehr klein ist und Bluetooth 4.0 unterstützt. Man kann ihn als SMD-Chip oder als Entwicklerboard mit USB-Anschluss für Rasterplatinen beziehen. Das Board kann mit 3.3 V betrieben werden. Die Programmierung ist einfach und es gibt viele Beispiele. |
||||
|
||||
Als Speicher-Baustein kommt der 24AA256 von Microchip zum Einsatz. Er ist mit 256 kB ausreichen groß, kann per I2C einfach mit dem RFduino kommunizieren und kann mit 3.3 V betrieben werden. |
||||
|
||||
Die Spannungsversorung bedient sich der am Fahrrad vorhanden B&M Lumotec-Leuchte mit Supercup-Kondensator. Um die Spannung der LED auf konstante 3.3 V zu bringen, kommt zur Spannungsstabilisierung der Step-Up Spannungsregler U1V11F3 von Pololu zu Einsatz. |
||||
|
||||
Die Radbewegung wird klassisch per Kontakt-Schalter |
||||
|
||||
|
||||
Schaltung |
||||
Auf dem Schaltplan sieht man noch die zusätzlich eine LED, als Minimal-Kommunikation so zu sagen. |
||||
|
||||
 Schaltplan |
||||
|
||||
Die Stromversorgung geht tatsächlich direkt an die LED der Lumotec-Leuchte, dazu wurde ein 2-adriges Kabel an die LED-Platine gelötet. |
||||
|
||||
|
||||
Steckbrett |
||||
Auf das Breadboard gesteckt, ist die Schaltung sehr übersichtlich: |
||||
 Steckbrett |
||||
|
||||
|
||||
Bauteil-Liste |
||||
M1 RFD22102 RFduino DIP |
||||
M2 Pololu 3.3V Step-Up Voltage Regulator U1V11F3 |
||||
IC1 EEPROM Microship 24AA256 |
||||
R4 Vorwiderstand 82 kΩ |
||||
LED1 Rote LED |
||||
R1 Vorwiderstand 330 Ω |
||||
LED2 Gelbe LED |
||||
R2 Vorwiderstand 330 Ω |
||||
R3 Pull-Down-Widerstand 55 k Ω |
||||
|
||||
LED1 blinkt kurz, wenn der aktuelle KM-Wert gespeichert wurden. LED2 zeigt, das Spannung anliegt (nur auf dem Breadboard gesteckt, nicht im Prototyp verbaut). |
||||
|
||||
|
||||
Platine |
||||
Die Platine ist so gestaltet, dass sie in ein Gehäuse 56 x 56 x 40 mm passt (Hammond Electronics 1594ABK, gibt z.B. bei Conrad Electronics, Best.-Nr. 535086-62). |
||||
|
||||
 Layout |
||||
|
||||
|
||||
Die Verbindungen von Pin 8 vom 24AA256 nach VOUT musst aus Platzmangel fliegend verkabeln, dass könnte man noch besser machen. Gelötet sieht das dann so aus: |
||||
 Oberseite |
||||
|
||||
 Unterseite |
||||
|
||||
Als Signalgeber kommt ein kabelgebundener eine kabelgebunde Variante von einem billigen Baumarkt-Tacho zum Einsatz. Die Kabelenden werden direkt an die Steckerstifte auf der Platine gelötet (REED bzw. VOUT), Polung spielt keine Rolle. Ebenso das Kabel der Spannungsversorgung (VIN und GND). Das Kabel wird von unten durch das Lumitec-Gehäuse gezogen (Belüftungsloch) und auf die kleine LED-Platine gelötet. Hier natürlich auf die richtige Polung achten. |
||||
|
||||
Hinweis: Mit dem Eingriff verliert die Leuchte den Garantieanspruch. Ob das Fahrrad noch im Straßenverkehr zulässig ist, habe ich nicht geprüft. |
||||
Montage |
||||
|
||||
Auf Rasterplatine gelötet und in ein Gehäuse gepackt sieht das Gerät dann am Fahrrad recht klobig aus, so wie es sich für einen Prototypen halt gehört. |
||||
|
||||
 Montage am Brompton |
||||
|
||||
An meinem Brompton konnte es einfach an die Taschenhalterung montiert werden. Es führen zwei Kabel aus dem Gerät: Die Stromversorgung zur Frontlampe sowie das Kabel für den Kontaktnehmer zur Gabel. |
||||
|
After Width: | Height: | Size: 82 KiB |
|
After Width: | Height: | Size: 77 KiB |
|
After Width: | Height: | Size: 172 KiB |
|
After Width: | Height: | Size: 252 KiB |
|
After Width: | Height: | Size: 93 KiB |
|
After Width: | Height: | Size: 78 KiB |
|
After Width: | Height: | Size: 83 KiB |
|
After Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 1.2 KiB |
@ -0,0 +1,86 @@
|
||||
+++ |
||||
title = "Exif Spickzettel" |
||||
date = "2017-08-09" |
||||
author = false |
||||
cover = "icon.jpg" |
||||
tags = ["linux"] |
||||
keywords = ["", ""] |
||||
description = "Von häufig zu setzenden EXIF-Werte und GPS-Tooling" |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
Bei der Fotobearbeitung verbrauche ich immer Zeit für die nebensächlichen Dinge wie das Setzen von Titel, GEO-Daten u. s. w. etc. pp. Daher hier mein ganz persönlicher Spickzettel, den ich in der jeweiligen Situation aus dem Ärmel ziehen kann. |
||||
|
||||
In meinen Fotos nutzte ich folgende Tags: |
||||
- Title |
||||
- Beschreibung |
||||
- Kommentar |
||||
- GPS-Daten |
||||
|
||||
Die verwendeten Tool skönnen viel mehr als hier beschrieben, Dokumentation lesen, lohnt sich. |
||||
|
||||
|
||||
|
||||
# exiftool |
||||
--> Für die Einzelbearbeitung |
||||
|
||||
Übernehmen aller EXIF-Daten aus src.jpg nach dest.jpg (z.B. nach GIMP-Export): |
||||
```bash |
||||
$ exiftool -tagsFromFile jpg/src.jpg final/dest.jpg |
||||
``` |
||||
|
||||
Setzen des Titels: |
||||
```bash |
||||
$ exiftool -title='Vergänglichkeit' final/dest.jpg |
||||
``` |
||||
|
||||
Setzen der Beschreibung: |
||||
```bash |
||||
$ exiftool -description='Beschreib mich' final/dest.jpg |
||||
``` |
||||
|
||||
Setzen des Kommentars: |
||||
```bash |
||||
$ exiftool -overwrite_original -comment='Fremd bin ich eingezogen...' final/dest.jpg |
||||
``` |
||||
|
||||
GPS-Position aus einer Track-Datei setzen: |
||||
```bash |
||||
$ exiftool -geotag 20170719.gpx final/dest.jpg |
||||
``` |
||||
|
||||
Am Ende löscht man die Originaldatei: |
||||
```bash |
||||
$ exiftool -delete_original! final/dest.jpg |
||||
``` |
||||
|
||||
Alternativ kann man auch Originaldatei mit jedem Befehl direkt löschen, z.B.: |
||||
```bash |
||||
$ exiftool -overwrite_original -tagsFromFile jpg/src.jpg final/dest.jpg |
||||
``` |
||||
|
||||
Anzeigen der hier bearbeiteten Felder: |
||||
```bash |
||||
$ exiftool -title -description -comment -gpsposition final/dest.jpg |
||||
Title : Vergänglichkeit |
||||
Description : Beschreib mich |
||||
Comment : Fremd bin ich eingezogen... |
||||
GPS Position : 51 deg 23' 20.36" N, 3 deg 26' 26.46" E |
||||
``` |
||||
|
||||
# Weitere Tools |
||||
|
||||
## geotag |
||||
--> GPS-Position setzen, wenn keine Trackdatei vorhanden ist. |
||||
|
||||
Bilddatei laden, im Browser anzeigen lassen, Positionsnadel verschieben und speichern. |
||||
Leider bietet geotag keine Kommandozeilenparameter. |
||||
|
||||
Geotag ist eine jar-Datei. |
||||
|
||||
> Geotag startet eventuell nicht mit open-java-sdk. |
||||
|
||||
## GIMP |
||||
|
||||
Gimp übernimmt die EXIF-Daten des ersten Bildimports. Die werden dann auch mit exportiert. XMP-Import und -Export klappen bei mir nicht, auch nicht das manuelle ändern der Werte. Deshalb ignoriere ich bei der Verwendung von GIMP die EXIF-Daten und setze sie lieber mit exiftool. |
||||
|
||||
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 127 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 42 KiB |
|
After Width: | Height: | Size: 51 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 4.5 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 4.2 KiB |
@ -0,0 +1,223 @@
|
||||
+++ |
||||
title = "Foto-Workflow" |
||||
date = "2017-03-04" |
||||
author = false |
||||
cover = "icon.jpg" |
||||
tags = ["fotografie"] |
||||
keywords = ["linux", ""] |
||||
description = "Terminal-basierter Workflow der digitalen Bildbearbeitung" |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
|
||||
|
||||
Fotos von der Digitalkamera zum sicheren Ablageort zu bringen wird sehr schnell unübersichtlich. Die letzten Urlaubsfotos liegen noch unbearbeitet in einem tmp-Ordner und aus der Nachbearbeitung meiner Kalenderfotos ist auch noch nichts geworden. Ein strukturiertes System muss her... |
||||
|
||||
|
||||
Es gibt viele Programme, um digitale Bildersammlungen zu verwalten. Hier geht es aber um den Schritt davor, also der Entwicklungsprozess vom Kamerabild über die Bearbeitung, Publizieren bis zum Archiv. Der hier skizzierte Workflow bedient sich vorhandener Tools und regelt lediglich die strukturierte Verwendung und systematische Abarbeitung der einzelnen Schritte. |
||||
|
||||
# Übersicht |
||||
|
||||
Folgende Aufgaben fallen in der Regel an (nicht alle Schritte sind immer nötig): |
||||
1. Bilddateien von der jeweiligen Kamera auf den Computer kopieren (Import) |
||||
1. Sicherungskopie der Dateien erstellen und Kamerabilder löschen (Backup) |
||||
1. Umbenennen der Bilder in eine einheitliches Zeitstempelformat (Rename) |
||||
1. Hinzufügen von Geopositionsdaten, von der Smartphone-App (Location) |
||||
1. Verschieben, löschen und gruppieren der Bilder in einzelnen Projektordner (Sort) |
||||
___ |
||||
Nun wird in den Projekten, zeitlich unabhängig voneinander, jedes Bild bearbeitet. |
||||
___ |
||||
1. 'Entwickeln' der Bilder in der digitalen Dunkelkammer (Develop) |
||||
- Bildbearbeitung ausführen |
||||
- Titel setzen |
||||
- Erstellen der finalen Bildes |
||||
2. Publizieren und Archivieren der Bilder (Export) |
||||
3. Aufräumen durch Löschen des Projekts incl. aller Bilder (Clean) |
||||
|
||||
Die gesamte Workflowbearbeitung erfolgt auf einem Linux-Computer. Der lokale Server fungiert als Datendrehscheibe für die GPS-Daten, als Backup-Speicher sowie als Archiv für die fertigen Bilder. |
||||
|
||||
 Workflow-Übersicht |
||||
|
||||
Der Workflow lässt sich natürlich genauso auf einem Windows-PC durchführen. Hat man einen PC und möchte nicht auf die Linux-Umgebung verzichtet, bietet es sich an, Linux in einer virtuellen Umgebung zu betreiben. Auf meinem Windows-PC kommt seit Jahren VirtualBox mit Linux Mint/Mate zum Einsatz. Im Folgenden gehen wir aber von einem reinem Kubuntu-Computer aus. |
||||
|
||||
## Das Workflow-Verzeichnis |
||||
Der Workflow hat eine feste Verzeichnisstruktur mit den drei Hauptverzeichnissen 00_Inbox, 01_Import und 02_Progress. |
||||
|
||||
Das erste Verzeichnis **00_Inbox** dient als Eingangskorb. Hier werden die externen Bilder unverändert gesammelt. In das zweite Verzeichnis, **01_Import**, kommen die Bilder durch Umbenennung. Hier können auch die Geo-Positionen hinzugefügt werden. |
||||
Das letzte Oberverzeichnis heist **02_Progress**, in welches die Bilder dann schließlich, in frei wählbaren Unterordnern, nach Projekten organisiert werden. |
||||
|
||||
 Verzeichnisstruktur |
||||
|
||||
Ein Projektverzeichnis selbst (z. B. 20170226) hat wiederum eine feste Verzeichnisstruktur mit folgenden Verzeichnissen: |
||||
- final - Fertig bearbeitete Bilder |
||||
- jpg - Originalbilder im JPG-Format |
||||
- raw - Originalbilder im RAW-Format |
||||
- videos - Originalvideos |
||||
- work - Optionales Arbeitsverzeichnis für Hilfsdateien wie z. B. Gimp-Projektdateien |
||||
|
||||
Betrachten wir nun die einzelnen Schritte genauer und stellen vor, mit welchen Tools die einzelnen Schritte durchgeführt werden können. Welche Programme für die einzelnen Schritte einsetzt, ist letztendlich natürlich Geschmackssache. Wichtig ist nur, dass man das für jeden Zweck das passende Tool findet und dann möglichste dabei bleibt. Als Bilddateien werden hier JPG, RAW und Video-Dateien zusammengefasst. |
||||
|
||||
# Die einzelnen Schritte des Workflows |
||||
Der Workflow setzt sich aus den einzelnen Schritten zusammen, welche vorwiegend streng sequenziell durchgeführt werden. Jeder Schritt hat einen definierten Anfangs- und Endzustand und eine definiertes Tooling. Kommen weitere Bilder hinzu, so wird der Workflow einfach wieder von vorne begonnen. |
||||
|
||||
|
||||
## Import |
||||
 |
||||
|
||||
Eingang: Bilddateien liegen auf externem Medium, z. B. SD-Card |
||||
Ausgang: Bilddateien liegen in 00_Inbox |
||||
|
||||
Import mit der Dateiverwaltung Dolphin im geteilten Modus. Die Dateien werden per Verschieben von der externen Quelle, abhängig von Dateityp, in das jeweilige Unterverzeichnis verschoben. |
||||
|
||||
 Laden externer Bilder durch Verschieben |
||||
|
||||
Alternativ zum Drag'n Drop kann man den Import einfacher per Scripting durchführen. Befindet man sich im Workflow-Verzeichnis und hat 'sdcard' gemountet, dann verschiebt man die Dateien sortenrein in drei Schritten: |
||||
|
||||
```bash |
||||
photo-workflow$ find /media/sdcard/ -name *.jpg -exec mv "{}" 00_Inbox/jpg \; |
||||
photo-workflow$ find /media/sdcard/ -name *.raf -exec mv "{}" 00_Inbox/raw \; |
||||
photo-workflow$ find /media/sdcard/ -name *.mov -exec mv "{}" 00_Inbox/video \; |
||||
``` |
||||
|
||||
|
||||
## Backup |
||||
 |
||||
Eingang: Alle Bilddateien befinden sich innerhalb des Workflow-Verzeichnisses |
||||
Ausgang: Workflow-Verzeichnis extern gesichert |
||||
|
||||
Der Backup erfolgt einfach per rsync: |
||||
|
||||
```bash |
||||
photo-workflow$ rsync -av --delete . /media/diskstation/christianDok/mirrors/photo-workflow |
||||
``` |
||||
|
||||
## Rename |
||||
 |
||||
|
||||
Eingang: Bilddateien in 00_Inbox |
||||
Ausgang: Bilddateien in 01_Import, 00_Inbox ist leer. |
||||
|
||||
Die Dateien werden anhand Aufnahmezeitstempel aus den EXIF-Informationen und Originalname in eine einheitliches Format umbenannt. Der Originalname ist Teil des neuen Namens. Damit ist der neue Name immer eindeutig (z. B. bei Serienbildern oder Import von verschiedenen Kameras). Ausserdem gibt es so keine Probleme, falls eine Bilddatei aus versehen ein zweites mal importiert wird: Die alte Datei wird einfach überschrieben. |
||||
Als Tool verwende ich Rapid Photo Downloader. Man legt einmal die Regeln fest, dass Umbenennen/Verschieben geht dann mit wenigen Klicks. |
||||
|
||||
 Rapid Photo Downloader: Verschieben von jpg-Bildern |
||||
|
||||
 Namensregel für JPG-Dateien |
||||
|
||||
|
||||
|
||||
## Location |
||||
 |
||||
|
||||
Eingang: Bilddateien in 01_Import, optional GPX-Dateien in externer Quelle |
||||
Ausgang: Geänderte Bilddateien in 01_Import, GPX-Dateien unverändert |
||||
|
||||
Für JPG-Dateien werden die Geo-Koordinaten den Bildern hinzugefügt. Liegen RAW-Dateien vor, wird der Schritt übersprungen und erst vor dem Export mit den Final-Bildern durchgeführt. |
||||
|
||||
Um GPX-Dateien zu erstellen verwende ich meistens GPSLogger auf dem Android-Smartphone. Die so erstellten Dateien werden auf den lokalen Server synchronisiert (mit FolderSync geht das automatisch). |
||||
|
||||
Als Tool kommt Geotag zum Einsatz. Damit kann man für ein komplettes Bildverzeichnis anhand einer beliebigen Menge von GPX-Dateien die Koordinaten hinzufügen. Hat man keine GPX-Datei, kann man die Location auch per Google-Maps hinzufügen. |
||||
|
||||
 Geotag |
||||
|
||||
|
||||
## Sort |
||||
 |
||||
|
||||
Eingang: Bilddateien in 01_Import |
||||
Ausgang: Bilddateien in 02_Progress, 01_Import ist leer |
||||
|
||||
In diesem Schritt werden zusammenhängende Bilddateien auf einzelne Projekte verteilt. Dazu wird zuerst das Projekt unter 02_Progress/<Projektgruppe>/<Projektname> angelegt. Ein Beispiel für eine Projektgruppe wäre 'weekly' und pro Woche erstellt man dann darin ein Projekt (z. B. '20170205'). |
||||
|
||||
Die Verzeichnisse werden per Dolphin von Hand erstellt. Die Dateien werden, ebenfalls mit Dolphin, im geteilten Modus per Drag'n Drop verschoben. |
||||
|
||||
 Projekt füllen |
||||
|
||||
|
||||
Hat man neben JPGs noch RAW-Dateien, sind diese ebenfalls zu verschieben (ins Zielverzeichnis RAW). |
||||
|
||||
### RAW automatisch verschieben |
||||
Erstellt man mit der Kamera gleichzeitig JPGs und RAWs, verschiebt man erst die JPGs wie beschrieben. Die gleichnamigen RAWs sind dann zusätzlich zu verschieben (Zielverzeichnis RAW). Per Script kann man das auch automatisieren. Nachdem die JPGs verschoben sind, lässt man die gleichnamigen RAWs nachziehen. Dazu ruft man aus dem Projektverzeichnis heraus auf: |
||||
|
||||
```bash |
||||
02_Progress/weekly/20170205$ ls ../../../01_Import/raw/ -1 |
||||
20170202-103548-DSCF4580.raf |
||||
20170205-180804-DSCF4593.raf |
||||
|
||||
02_Progress/weekly/20170205$ for f in jpg/*; do g="${f/.jpg/.raf}"; h="${g:4}"; mv "../../../01_Import/raw/$h" raw/ ; done |
||||
|
||||
02_Progress/weekly/20170205$ ls raw/ -1 |
||||
20170202-103548-DSCF4580.raf |
||||
20170205-180804-DSCF4593.raf |
||||
``` |
||||
|
||||
Das Beispiel geht davon aus, dass man sich im aktuellen Projektverzeichnis befindet und die JPG-Dateien bereits dort einsortiert worden sind. Im Verzeichnis 01_Import/raw befinden sich die korrespondierende raf-Dateien. |
||||
Dieser Workflowschritt wird pro Projekt vollständig durchgeführt, d.h. die Bilder eines Projektes sind entweder noch alle in 01_Import oder **vollständig** nach 02_Progress verschoben worden. |
||||
|
||||
|
||||
### Projektbearbeitung |
||||
|
||||
Mit Sort sind nun die Bilddateien in Projekte einsortiert worden. Die weitere Bearbeitung erfolgt nun in diesen einzelnen Projekten. Das kann zeitlich unabhängig von einander erfolgen. |
||||
|
||||
|
||||
|
||||
## Develop |
||||
 |
||||
|
||||
Eingang: Originalbilder in den Projektverzeichnissen jpg, raw. |
||||
Ausgang: Finale Bilddateien als Kopien im Projektverzeichnis final (Auswahl). |
||||
|
||||
Die JPGs bzw. RAWs werden nun vorsortiert, bearbeitetet und nach final exportiert. Die Originalbilder bleiben dabei unverändert. Dabei können die Bilder zusätzlich mit einem Titel ergänzt werden. Haben die Finals noch keine Geo-Positionsdaten, können diese, wie bereits in Schritt 'Location' beschrieben, um diese ergänzt werden. |
||||
Das eingesetzte Tool ist Geschmackssache, ich verwende Darktable. |
||||
|
||||
Beim Vorsortieren werden die zu bearbeitenden Bilder markiert, z.B. durch Vergabe von drei Sternen: |
||||
|
||||
 Darktable: Bilder auf dem Leuchttisch vorsortieren |
||||
|
||||
|
||||
Nach der Bearbeitung wird das Bild nach final exportiert, ggf. mit einem Titel. |
||||
|
||||
 Darktable: Export |
||||
|
||||
Das erstellte Bild kann direkt nach Final exportiert werden. Im Feld 'Speicherziel' gibt man dazu `'$(FILE_FOLDER)/../final/$(FILE_NAME)'` an. |
||||
|
||||
|
||||
## Export |
||||
 |
||||
|
||||
Eingang: Finale Bilddateien liegen im Unterverzeichnis final |
||||
Ausgang: Bilddateien wurden zu allen Zielen exportiert (Kopie) |
||||
|
||||
Lokale Exportziele werden durch Kopieren der Dateien aus dem final-Verzeichnis gefüllt (Dolphin). Hochladen in Webportale erfolgt mit deren Importseiten (flickr, Instagram, etc.). |
||||
|
||||
Exportieren der Daten auf den lokalen Server: |
||||
|
||||
```bash |
||||
photo-workflow/02_Progress/weekly/20170205$ ls final/ |
||||
20170202-103548-DSCF4580.jpg |
||||
photo-workflow/02_Progress/weekly/20170205$ cp final/*.* media/diskstation/photp/tagesbild/2017 |
||||
``` |
||||
|
||||
## Clean |
||||
 |
||||
|
||||
Eingang: Projektverzeichnis mit Bilddateien |
||||
Ausgang: Projekt mit allen Originaldateien und Zwischendateien wurden gelöscht |
||||
|
||||
Nach dem Export kann das Projektverzeichnis gelöscht werden: Alle finals wurden exportiert, alle Originalbilder liegen unter jpg bzw. raw. Die Originaldateien werden also nicht aufgehoben. |
||||
Auch das Entfernen kann man mit dem Dolphin oder per Bash machen: |
||||
|
||||
```bash |
||||
photo-workflow/02_Progress/weekly$ rm -r 20170205 |
||||
``` |
||||
|
||||
Damit ist der Workflow für das Projekt durchgeführt. Aber sicherlich sind schon die nächsten Bilder auf der Kamera und der Prozess beginnt von vorne... |
||||
|
||||
# Links |
||||
- Dolphin, wiki.ubuntuusers.de/Dolphin |
||||
- Rapid Photo Downloader, www.damonlynch.net/rapid |
||||
- Geotag, geotag.sourceforge.net |
||||
- GPSLogger play.google.com/store/apps/details?id=com.mendhak.gpslogger |
||||
- FolderSync play.google.com/store/apps/details?id=dk.tacit.android.foldersync.full |
||||
- Darktable, www.darktable.org |
||||
|
||||
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 5.2 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 38 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 101 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 5.8 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 14 KiB |
@ -0,0 +1,220 @@
|
||||
+++ |
||||
title = "Hochbett Aus Alten Dachsparren" |
||||
date = "2017-01-17" |
||||
author = false |
||||
cover = "icon.jpg" |
||||
tags = ["schreinerei"] |
||||
keywords = ["", ""] |
||||
description = "Upcycling-Projekt schafft aus verwitterten Dachsparren des alten Wintergartens ein Kinderhochbett." |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
|
||||
Mit diesem Upcycling-Projekt wurde aus den verwitterten Dachsparren des alten Wintergartens ein Kinderhochbett geschaffen. |
||||
|
||||
Die ausgedienten Dachsparren (13 x 7 und 14 x 8 cm) lagerten seit vier Jahren im Freien und waren bereits dementsprechend zum Teil verwittert, krumm und verdreht. Wir wollten sie eigentlich gerade entsorgen... |
||||
Durch Umgestaltung des Kinderzimmers wurde ein Hochbett benötigt, welches |
||||
im rechten Winkel zum anderen Kinderbett unter der Dachschräge stehen sollte. |
||||
|
||||
 Kinderbett mit linksseitig versetzten Pfosten |
||||
|
||||
 |
||||
Ausgangsmaterial sind ausrangierte Dachsparren |
||||
|
||||
Es wurde schnell klar, dass es sich um eine Individualkonstruktion handelt, da die linken Pfosten versetzt sein mussten. Es wurde entschieden beide Probleme mit einer Klappe zu schlagen und das Bett aus den Balken selbst zu bauen. |
||||
Nach etwas Überlegung wurde die Aufgabe wie folgt gestellt: |
||||
|
||||
- Wenig Holz zukaufen, möglichst alles aus den Dachsparren herstellen |
||||
- Stabile Konstruktion durch Verzapfung und Einblattung, um der Belastung durch Toben standzuhalten |
||||
- Präzise Verbindungsflächen durch Fräsen herstellen - während der Balken an sich seine 'krumme' Form behalten soll |
||||
- Lösbare Verbindungen durch metrische Schrauben, Vermeidung von Holzschrauben |
||||
- Fest montierte Leiter mit kleinem Einstieg |
||||
- Für Matratze 190 x 90 |
||||
- Schlafhöhe ca. 1,35 m |
||||
|
||||
Der Blog liefert keine Bauanleitung, sondern gibt nur die Erfahrung wieder und kann so Anregung für ähnliche Projekte geben. |
||||
|
||||
Die Bauzeit erstreckte sich über mehrere Monate bis in den Winter hinein, da ich nur immer stundenweise arbeiten konnte. Als Werkstatt und Lager musste der Schuppen dienen, grobe Arbeiten wurden im Garten auf wackligen Holzböcken gemacht. |
||||
|
||||
Es ergaben sich folgende Bauphasen: |
||||
- Erstellen eines Arbeitstisches und Zukauf von Werkzeug und Zwingen |
||||
- Entfernen aller nicht verwendbaren Balkenteile und anschließend Balken auf Länge bringen |
||||
Hobeln der Oberfläche |
||||
Längsteilen zur Erstellung der schmalen Bretter |
||||
- Herstellung der Verbindungszapfen und -Flächen durch Fräsen |
||||
- Schraublöcher bohren und Schrauben herstellen |
||||
|
||||
# Werkzeuge |
||||
Die wichtigsten Werkzeuge, welche zum Einsatz kamen: |
||||
|
||||
- Kapp- und Gehrungssäge |
||||
- Elektrohobel (Bosch Elektrohobel PHO35-82C) |
||||
- Handkreissäge (AEG) |
||||
- Oberfräse (Bosch GOF 1250 LCE) |
||||
- Heimwerker Bohrmaschine und mobiler Bohrständer (Black- und Decker, Wolfcraft) |
||||
- Gewindeschneider |
||||
- Tischspannelemente und Schraubzwingen |
||||
- Handsäge Holz, Handsäge Metall, ... |
||||
|
||||
# Arbeitstisch |
||||
Um die schweren und z.T. langen Balken fräsen und bohren zu können, muss ein stabiler Tisch her. Die Balken sollen per Klemmen auf dem Tisch fixiert werden können. Bei Nichtbedarf soll der Tisch nicht zu viel Platz einnehmen. Angeregt durch die Anleitung Arbeitstisch mit Lochplatte von Roberto Hoffmann auf Eigenbaukombinat.de ist eine sehr einfacher, U-förmiger Tisch erstellt worden: |
||||
|
||||
- Maße 70 x 120, Höhe 32 cm |
||||
- Tischlerplatte 19 mm |
||||
- Lochraster 96 mm, 20 mm Lochdurchmesser |
||||
|
||||
Der Tisch ist schwer genug, dass auch seitlich ein Balken fixiert werden kann. |
||||
|
||||
 Arbeitstisch im Einsatz |
||||
|
||||
Die Tischlerplatten kommen aus dem Baumarkt, ca. 80 EUR incl. Zuschnitt. Die Investition lohnt sich aber. Die Platte wird auf die beiden Seitenteile montiert und mit Holzschrauben und Holzdübeln verleimt. Innen sind die beiden Seitenteile mit zwei Holzstäben versteift. |
||||
|
||||
Neben normalen Spannklemmen kommen spezielle Spannelemente für den Tisch zum Einsatz: |
||||
|
||||
- 2 Bessey BE-TW16-10-2K mit Werkbankadapter 3/4" |
||||
- 2 Festool Schraubzwinge FSZ 120 |
||||
|
||||
|
||||
Die Bessey-Zwingen haben sich als die besseren Zwingen erwiesen: Sie sind sehr schnell zu montieren (auch einhändig), spannen sehr fest und sind ausreichen lang. Die Festool-Zwingen sind etwas zu breit für das 20-Loch und müssen leicht eingepresst werden. |
||||
|
||||
# Werkzeug |
||||
Kurzer Abriss der Werkzeuge und Arbeitsmittel und deren Verwendung. |
||||
|
||||
## Kapp- und Gehrungssäge |
||||
Damit werden die Balken auf Länge gesägt, Nachbearbeitung erfolgt nicht. Hat man die Säge einmal auf einen rechtwinkligen Schnitt in beiden Achsen eingerichtet, ist sie dann einfach und problemlos einsetzbar. |
||||
|
||||
## Elektrohobel |
||||
Hier reicht ein alter Hobel mit neuen Messern aus. Damit wird die lasierte und verwitterte Oberfläche der Balken abgenommen und die Balken bekommen ihren rustikalen Touch. Vor dem Hobeln ist der Balken auf abgebrochen Schrauben und Nägel zu untersuchen, ansonsten sind die Messer schnell hinüber. |
||||
|
||||
## Handkreissäge |
||||
Mit Hilfe der Führungsschiene werden die Balken halbiert, um die schmalen Bretter des Geländers zu sägen. |
||||
|
||||
 Balken längs teilen |
||||
|
||||
|
||||
Der Sägeschnitt erfolgt von zwei Seiten, da das Sägeblatt nicht tief genug eintaucht: |
||||
|
||||
 Erster Schnitt |
||||
|
||||
## Oberfräse |
||||
Für das Erstellen der Zapfenlöcher und Einblattungen (Fräser: HM-Nutfräser mit Bohrschneide, D16). Für die Blindzapfenlöcher sind Frässchablonen anzufertigen (s. [Youtube-Video](https://www.youtube.com/watch?v=MH3ZYx1dFiI) von Heiko Rech), dafür ist eine Kopierhülse D24 hinzuzukaufen. |
||||
|
||||
 Anwendung der Kopierhülse für die Nut der Leitersprossen |
||||
|
||||
Die Auflagefläche der Fräse reicht für breite Frässchablonen nicht immer aus. Abhilfe schafft ein (unfixiertes) Auflagebrett mit kleinerer Aussparung (weiß). |
||||
|
||||
 Schwimmendes Auflagebrett |
||||
|
||||
|
||||
|
||||
Für Dübellöcher: Dübellochfräser 8mm. Für die meisten Löcher wird eine Anreißschablone erstellt und mittels Anreißnadel der Mittelpunkt auf das Werkstück übertragen. Das geht recht schnell und ist ausreichend präzise. |
||||
|
||||
 |
||||
Schablone von einer Seite |
||||
|
||||
 Schablone von der anderen Seite |
||||
|
||||
Zum Abrunden der Kanten wird ein einfacher Abrundfräser aus dem Baumarkt verwendet. |
||||
|
||||
 Abrundfräsen |
||||
|
||||
## Bohrmaschine und mobiler Bohrständer |
||||
Bohren der Löcher für die Schraubverbindungen (Schrauben und Querbolzenmutter). Die Bohrmaschine hat recht viel Spiel, da hilft der mobile Bohrständer nur bedingt. Löcher, welche durch zwei Werkstücke führen, werden immer von der Berührungsseite aus gebohrt. Das hilft, den Versatz in Grenzen zu halten. Als Bohrer kommen Holzspiral- bzw. Schlangenbohrer zum Einsatz, welche sich äußerst präzise in das Werkstück reinarbeiten. |
||||
|
||||
Der mobile Bohrständer von Wolfcraft ist nicht sehr stabil und lässt sich nur bedingt genau auf 90° ausrichten, dafür ist er preiswert und ausreichend für den Verwendungszweck. |
||||
|
||||
Um die Auflagefläche des Bohrständers zu vergrößern, wird dieser, für einige Arbeiten, auf einer Platte montiert. |
||||
|
||||
 Mobiler Bohrständer mit Brett |
||||
|
||||
Bei unebenen Werkstücken wird die Platte auf Auflagehölzern oder direkt auf dem Werktisch aufgelegt. |
||||
|
||||
 Bohren der Durchgangslöcher |
||||
|
||||
Die Markierung der Querbolzenmutter-Löcher erfolgt für jedes Loch individuell, um die nicht sehr präzise gebohrten Schraubenlöcher bestmöglichst zu treffen. |
||||
|
||||
 Anreißen des Querbolzenlochs |
||||
|
||||
# Konstruktion |
||||
Nach dem festlegen der Eckmaße, ist eine initiale Handzeichnung erstellt worden. Details sind bei Bedarf im Laufe der Umsetzung zu fertigen. |
||||
|
||||
 Seitensicht |
||||
|
||||
Jedes Teil hat eine Nummer, welche auch auf dem Werkstück steht, damit man es in der Werkstatt wiederfindet und nicht ausversehen das falsche Teil bearbeitet. Zusätzlich wird an jeder Verbindungsstelle des Werkstücks die Nummer des zu montierenden Gegenstücks geschrieben, damit nicht die falsche Seite bearbeitet wird. |
||||
|
||||
|
||||
 Draufsicht |
||||
|
||||
|
||||
Die Zapfenverbindung ist nur durch Fräsung der Vertiefung hergestellt (15 mm), in der das Gegenwerkstück eingeführt wird, s. Schnitt C-C. Auf die Ausbildung des Zapfens ist also verzichtet worden (ist also gar keine Zapfenverbindung, oder?). Lediglich die Kanten sind abgerundet und ggf. das zapfenseitige Werkstück eingepasst. |
||||
|
||||
Der kleine Pfosten für die Einstiegsluke (8) ist als gerade Einblattung mit dem vorderen Querrahmen (5) verdübelt und verleimt. Mit der Leitermontage kommen dann noch zwei Schrauben M12 hinzu, die die Verbindung zusätzlich stabilisieren. |
||||
|
||||
Die Skizze zeigt den Querschnitt durch Teil 8 und 5: |
||||
|
||||
 Einstiegspfosten mit Leiterwange (L1) |
||||
|
||||
Die beiden freistehenden linken Pfosten (2) werden durch Einblattung in den Querbalken (5 bzw. 9) eingearbeitet, so dass diese die Last abnehmen können (s. Schnitt A-A). Das ist aber in Querrichtung zu instabil, so dass im Nachhinein noch eine Querlatte zwischen beiden Pfosten montiert wurde. |
||||
|
||||
 Stabilisierungsbrett |
||||
|
||||
Da nachträglich angefertigt, ist das die einzige Verbindung, welche nicht gefräst ist. Die Verstrebung ist seitlich durch angeleimte Enden in der Höhe verlängert. Hier ein Bild aus der Herstellung der Zapfenschlitze (die Löcher für die Holzdübel sind bereits vorhanden). |
||||
|
||||
 Zahnverzapfung |
||||
|
||||
Das Lattenrost ist gekauft und liegt auf zwei, ebenfalls gekauften, Leisten. Diese sind an den langen Querträgern verdübelt und mit Holzschrauben verschraubt. |
||||
|
||||
# Leiter |
||||
Ist nach Fertigstellung der Bettteile gebaut worden. Die Sprossen (L2) sind aus geviertelten 14 x 8 cm Balken hergestellt, also ca. 7 x 4 cm im Querschnitt. Die Wangen (L1) sind halbierte 13 x 7 cm Balken, also ca. 6,5 x 7. |
||||
|
||||
[Skizze der Leiter](Leiter-Zeichnung.jpg) Skizze der Leiter |
||||
|
||||
Herstellung der Sprossen: |
||||
|
||||
 Sprossenholz wird eingespannt |
||||
|
||||
Auch die Sprossen sind von zwei Seiten zu sägen. |
||||
|
||||
 Zweite Seite sägen |
||||
|
||||
|
||||
Die Leiter ist schraubenfrei verleimt. Dazu sind Schlitze in die Wange gefräst und mit Holzdübeln verstärkt worden. Die fertige Leiter wird mit M12-Schrauben (und den bereits vorhanden langen M8-Schrauben) mit dem Bett fest verbunden. |
||||
|
||||
# Verschraubung |
||||
Alle Elemente des Bettrahmens sind mit M8-Schrauben verbunden, entweder mit Querlochbolzenmuttern oder, für die freistehenden Pfosten, mit Hülsenmuttern. Um die Anschaffung der Schrauben zu vereinfachen, sind diese aus Gewindestange und Hülsenmutter selbst erstellt. Zur Montage der Leiter kommen M12 Gewindestange und Hülsenmuttern zum Einsatz. |
||||
|
||||
 Schraubverbindungen: nur aus vier verschiedenen Teilen |
||||
|
||||
Das Montieren der Schrauben mit den Querbolzen war anfangs nicht gut möglich. Durch das Hantieren mit Schraubendreher und Innensechskantschlüssel, sowie der Tatsache, dass die Löcher nicht sehr genau gebohrt sind, fand die Schraube nicht das Muttergewinden. Daher wird an jede Schraube einseitig ein Zapfen geschliffen, wodurch sich die Querbolzenmuttern nun selbständig ausrichtet. |
||||
|
||||
 Zapfen anschleifen |
||||
|
||||
Der Zapfen ist bei der Berechnung der Schraubenlänge unbedingt zu berücksichtigen. |
||||
|
||||
Die gesägte und angefaste Gewindestange ist mit dem Gewindeschneider gefügig zu machen, ansonsten lässt sich die Mutter von Hand nicht gut verschrauben. |
||||
|
||||
 Nachschneiden des Gewindeanfangs |
||||
|
||||
# Oberfläche |
||||
Die durch Sägen und Hobeln gegebene Oberfläche soll erhalten bleiben, das Holz aber haptisch ansprechend werden. Dies wird durch folgende Arbeiten erreicht: |
||||
|
||||
1. Fräsen der Kanten mit einem Abrundfräser |
||||
Durch Abrunden der Kanten werden die splittrigen Kanten geglättet und die Balken werden auch optisch viel gefälliger. |
||||
|
||||
 Abrunden der Kanten |
||||
|
||||
2. Vorschleifen der Oberfläche mit einer Tellerbürste aus Nylon, K80 |
||||
Staubige Sache, sollte man besser draußen machen. |
||||
|
||||
 Tellerbürste |
||||
|
||||
Versuche mit einer Drahttellerbürste zeigten, dass dafür das Holz zu weich ist. Die Nylonbürste ist nicht billig, lohnt sich aber. |
||||
|
||||
3. Handschleifen der Oberfläche |
||||
Den letzten Schliff bekommt das Holz durch Handschleifen mit Scheifvliesmatten 180. |
||||
|
||||
Anschließend wird das Holz mit Arbeitsplattenöl von Auro behandelt und noch mal mit dem Schleifvlies geglättet. |
||||
|
||||
# Schluss |
||||
|
||||
 Steht wie 'ne Eins |
||||
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 5.0 KiB |
@ -0,0 +1,40 @@
|
||||
+++ |
||||
title = "RFduino Implementation of DDO" |
||||
date = "2015-01-15" |
||||
author = false |
||||
cover = "icon.png" |
||||
tags = ["programmierung"] |
||||
keywords = ["ddo", "arduino"] |
||||
description = "Describes the Coding for the DDO hardware, based on a RFduino board." |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
|
||||
This post describes the coding for the DDO hardware, based on a RFduino board. The hardware itself is introduced in the post [posts/ddo-prototype](/posts/ddo-prototype/). To implement the program, the standard Arduino SDE with RFduino library is installed on your computer (The RFduino Quick Start Guide on www.rfduino.com is not available any more). |
||||
|
||||
|
||||
|
||||
The implementation has following main features: |
||||
|
||||
Counting wheel rotations and calculation distance |
||||
Read/Write the distance to memory in a safety way |
||||
Push the actual distance via Bluetooth LE (BLE) |
||||
Further topics are: |
||||
Flash the LED with a memory write, communicate an error via LED |
||||
Send logging to SDE |
||||
The most important challenge is the non-stable power supply, especially at writing time. |
||||
|
||||
Architecture |
||||
The implementation communicates or controls five external components. The EEPROM is used to store the actual distance value. The LED give signals to the user at run time. The reed contact attached to the front wheel is the rotation trigger. |
||||
|
||||
 |
||||
|
||||
Via BLE the board sends the actual distance value periodically into the environment (independent, if there is a receiving app or not). |
||||
For the developer, messages can be pushed via serial port to the Arduino SDE. |
||||
|
||||
|
||||
The inner view: |
||||
|
||||
 |
||||
|
||||
|
||||
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 6.7 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 73 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 2.2 KiB |
@ -0,0 +1,438 @@
|
||||
+++ |
||||
title = "Fow Foto Workflow Tool" |
||||
date = "2017-09-11" |
||||
author = false |
||||
cover = "icon.jpg" |
||||
tags = ["fotografie"] |
||||
keywords = ["linux", ""] |
||||
description = "Ein Kommandozeilen-Tool für den digitalen Fotoprozess oder wie man auch bei mehreren Kameras und vielen Fotoprojekten den Überblick behält." |
||||
showFullContent = false |
||||
readingTime = false |
||||
+++ |
||||
|
||||
Ein Kommandozeilen-Tool für den digitalen Fotoprozess |
||||
Wie man auch bei mehreren Kameras und vielen Fotoprojekten den Überblick behält. |
||||
|
||||
In dem [Fotoworkflow-Blog](/posts/foto-workflow/) wird der gesamte Ablauf für die Fotoentwicklung vorgestellt, so dass der Weg von der Kamera-Speicherkarte bis zur Veröffentlichung bzw. Archivierung beschrieben ist. Der Nachteil des so durchgeführten Workflows liegt auf der Hand: da ist einen Menge Handarbeit auf der Konsole bzw. mit dem Datei-Browser zu machen. Das ist zeitraubend, fehleranfällig und einfach nervig. Die Lösung für mich sind eine handvoll Kommandozeilenbefehle die genau die einzelnen Schritte als Befehl umsetzen. Dieses Tool, fow genannt, wird hier nun genauer vorgestellt. |
||||
|
||||
# Technische Umsetzung |
||||
Als Sprache wurde Python3 gewählt, da die Befehle damit schnell implementiert werden konnten. Die Befehle benötigen, neben Python 3, folgende Tools, welche aber in der Regel bereits installiert sind: |
||||
|
||||
- exiv2 |
||||
- exiftool |
||||
- rsync |
||||
|
||||
Das Projekt ist unter [gitHub](https://github.com/chs8691/fow) gehostet und steht als Open Source zur Verfügung. Vorschläge für Verbesserungen und Fehlermeldung sind willkommen und können dort erfasst werden. Wer aktiv mitentwickeln möchte, kann dies gerne tun. |
||||
|
||||
# Installation |
||||
Voraussetzung: Linux-System, auf dem DEB-Pakete installierte werden können (Debian, Ubuntu, Lint etc.). Für Windows-PCs lässt sich fow in einer VirtualBox z. B. mit Lint/Mate betreiben. |
||||
Download: Neuestes Deb-Paket von gitHub-Projekt fow Unterverzeichnis /dist herunterladen und in einer Shell installieren mit z . B.: |
||||
|
||||
```bash |
||||
$ sudo dpkg -i fow_1.1.8_all.deb |
||||
``` |
||||
|
||||
# Initialisierung |
||||
Man benötigt ein, am besten leeres, Unterverzeichnis und initialisiert das fow, indem man in diesem Verzeichnis ‚init‘ aufruft. Beispiel: |
||||
|
||||
```bash |
||||
$ mkdir ~/photo |
||||
$ cd ~/photo |
||||
$ fow init |
||||
``` |
||||
|
||||
Damit wird die Verzeichnisstruktur aufgebaut und ein paar Konfigurationsvariblen initialisiert. Zur Erfolgskontrolle lässt man sich die Konfigurationswerte anzeigen: |
||||
|
||||
```bash |
||||
$ fow config |
||||
backup.path = None |
||||
gps.tracks = None |
||||
task = None |
||||
``` |
||||
|
||||
Ok, dass sieht noch nicht wirklich eingerichtet aus. Dass erfolgt erst bei Bedarf der einzelnen Befehle, für den Anfang genügt es. |
||||
Hier ein paar grundlegende Tipps für den Anfang: |
||||
- Das Wurzelverzeichnis hat keinen Einfluss auf fow und kann beliebig umbenannt und verschoben werden |
||||
- Man muss sich innerhalb der Verzeichnisstruktur befinden, um einen fow-Befehl ausführen zu können |
||||
- Fow-eigene Unterverzeichnisse dürfen nicht gelöscht/umbenannt werden |
||||
- Zusätzliche Unterverzeichnisse sind möglich |
||||
- Man kann beliebig viele fows nebeneinander betreiben |
||||
- fows können nicht geschachtelt werden |
||||
|
||||
# Prinzip |
||||
Die Befehle sind so angelegt, dass sie mit möglichst wenig Tipparbeit einen Workflow-Schritt oder Befehl ausführen. Jedem Befehl geht das 'fow' voraus. Ein Übersicht über die Befehle bekommt man mit help: |
||||
|
||||
```bash |
||||
$ fow help |
||||
fow commands: |
||||
backup - save the fow to an external directory |
||||
config - show and change settings of the fow. A setting is a key value pair. |
||||
exif - Set or show EXIF values for final images of the actual task |
||||
export - Copy final images to external destinations for the actual task |
||||
gps - add gps locations from gpx files |
||||
help - This help. Use "help <command>" for a specific command help |
||||
init - Creates new fow in the actual directory |
||||
load - Loads images from external destinations into 00_Inbox. |
||||
rename - Move and rename files from 00_Inbox to 01_Import. |
||||
show - reporting for processing steps |
||||
task - manage a fow's task |
||||
``` |
||||
|
||||
Detaillierte Hilfe zu den einzelnen Befehlen bekommt man mit help <command>, z. B.: |
||||
|
||||
```bash |
||||
$ fow help init |
||||
``` |
||||
|
||||
Ein Befehl kann Optionen (beginnend mit 2 Bindestrichen) und Parameter haben. So habe z. B. viele Befehle eine verbose-Ausgabe (--verbose). Ändernden Befehle bieten in der Regel eine Testoption (--test), die keine Änderungen macht (Dry-run). Beispiele: |
||||
|
||||
```bash |
||||
$ fow rename --test |
||||
Processing jpg 5: 5 |
||||
Processing raw 3: 3 |
||||
Processing video 0: 0 |
||||
8 files will be moved and renamed. |
||||
``` |
||||
```bash |
||||
$ fow rename --verbose |
||||
Processing jpg 5: 5 |
||||
Processing raw 3: 3 |
||||
Processing video 0: 0 |
||||
OK jpg 20170720-181117-DSCF5339.JPG --> 20170720-181117-20170720-181117-DSCF5339.JPG |
||||
OK jpg 20170720-184415-DSCF5343.JPG --> 20170720-184415-20170720-184415-DSCF5343.JPG |
||||
OK jpg 20170720-184415-DSCF5344.JPG --> 20170720-184415-20170720-184415-DSCF5344.JPG |
||||
OK jpg 20170720-184416-DSCF5345.JPG --> 20170720-184416-20170720-184416-DSCF5345.JPG |
||||
OK jpg 20170720-184650-DSCF5346.JPG --> 20170720-184650-20170720-184650-DSCF5346.JPG |
||||
OK raw 20170720-184415-DSCF5343.RAF --> 20170720-184415-20170720-184415-DSCF5343.RAF |
||||
OK raw 20170720-184415-DSCF5344.RAF --> 20170720-184415-20170720-184415-DSCF5344.RAF |
||||
OK raw 20170720-184416-DSCF5345.RAF --> 20170720-184416-20170720-184416-DSCF5345.RAF |
||||
8 file(s) moved. |
||||
``` |
||||
|
||||
Tipp: Eine Option hat auch eine Abkürzung, bestehend aus einem Bindestrich und dem Anfangsbuchstaben der Option, zum Beispiel kann statt –verbose auch einfach -v geschrieben werden. Zur besseren Lesbarkeit des Blogs wird hier aber nur die lange Schreibweise verwendet. |
||||
|
||||
# Die einzelnen Workflowschritte |
||||
Das Workflow Diagramm, wie es schon im Fotoworkflow-Blog vorgestellt wurde, dient fow als Grundlage und wurde nur leicht angepasst. |
||||
|
||||
 Workflow |
||||
|
||||
Folgende Schritte werden von fow nicht unterstützt, da es für sie vorhandene Tools gibt: |
||||
- Develop: Nachbearbeitung der JPG- bzw. RAW-Bilder erfolgt mit dem jeweiligen Lieblingstool, z. B. Darktable. Ferner fällt hierunter auch das Hinzufügen von Titel, Beschreibung etc. |
||||
- Clean: Nicht mehr benötigte fow-Tasks sind manuell zu löschen |
||||
|
||||
## LOAD |
||||
|
||||
**Aufgabe** |
||||
Laden aller Bilddateien (incl. aus Unterverzeichnissen) aus einer externen Quelle (wie z. B. SD-Karte oder Smartphone) in den Eingangsordner 00_Inbox. |
||||
|
||||
**Endzustand** |
||||
Alle Bilddateien der externen Quelle wurden nach 00_Inbox kopiert bzw. verschoben und liegen nun in einem der Unterordner. |
||||
|
||||
 Load-Verzeichnis |
||||
|
||||
**Voraussetzung** |
||||
Die SD-Karte ist gemountet. |
||||
|
||||
**Durchführung** |
||||
Das Mount-Verzeichnis der SD-Karte wird einmal als config-Variable gesetzt: |
||||
|
||||
```bash |
||||
$ fow config -s=load.sd=/mount/sd-card |
||||
``` |
||||
|
||||
Nun kann man sämtliche Bilddateien importieren lassen: |
||||
|
||||
```bash |
||||
$ fow load sd |
||||
Processing jpg 3: 3 |
||||
Processing raw 1: 1 |
||||
Processing video 0: 0 |
||||
All 3 files copied (0 existing files ignored). |
||||
``` |
||||
|
||||
> **Hinweise** |
||||
Mit der Option _--move_ werden die Dateien nach dem Kopieren aus der Quelle gelöscht. Das ist mit Vorsicht zu verwenden, schließlich hat man noch kein Backup der Bilddateien gemacht. |
||||
Mit der Option _--force_ werden vorhandene Dateien überschrieben |
||||
|
||||
**BACKUP** |
||||
Es wird einmalig ein Backup-Verzeichnis ausserhalb des fow-Vezeichnisses definiert. Mit Backup kann dann man zu einem beliebigen Zeitpunkt die Daten dorthin sichern. Ein guter Zeitpunkt ist direkt nach dem Load, damit hat man einen definierten Zustand des fow-Verzeichnisses und kann mit ruhigem Gewissen die Daten von der SD-Karte löschen. |
||||
|
||||
**Aufgabe** |
||||
Sichern des gesamten fow-Verzeichnisses auf ein externes Verzeichnis, idealerweise eine externe Festplatte oder der lokale Server. |
||||
|
||||
**Endzustand** |
||||
Eine Kopie das fow-Verzeichnisses liegt vor. |
||||
|
||||
**Voraussetzung** |
||||
Das externe Medium muss gemountet sein. |
||||
|
||||
**Durchführung** |
||||
Es wird einmalig das Backup-Verzeichnis als Config-Wert definiert. |
||||
|
||||
```bash |
||||
$ fow config -s=backup.path=/media/diskstation/fow-backup |
||||
``` |
||||
|
||||
Nun kann das Backup durchgeführt werden. |
||||
|
||||
```bash |
||||
$ fow backup |
||||
Starting backup to "/media/diskstation/fow-backup". |
||||
sending incremental file list |
||||
.fow/ |
||||
.fow/setting.pickle |
||||
00_Inbox/ |
||||
00_Inbox/jpg/ |
||||
00_Inbox/jpg/20170202-103548-DSCF4580.jpg |
||||
00_Inbox/jpg/20170720-181117-20170720-181117-DSCF5339.JPG |
||||
00_Inbox/jpg/20170720-184415-20170720-184415-DSCF5343.JPG |
||||
00_Inbox/jpg/20170720-184650-20170720-184650-DSCF5346.JPG |
||||
00_Inbox/jpg/DSCF4580.jpg |
||||
00_Inbox/jpg/DSCF4593.jpg |
||||
00_Inbox/raw/ |
||||
00_Inbox/raw/20170202-103548-DSCF4580.raf |
||||
00_Inbox/video/ |
||||
01_Import/ |
||||
01_Import/jpg/ |
||||
01_Import/raw/ |
||||
01_Import/raw/20170720-184416-20170720-184416-DSCF5345.RAF |
||||
01_Import/video/ |
||||
02_Progress/ |
||||
02_Progress/blog/ |
||||
02_Progress/blog/labels/ |
||||
02_Progress/blog/labels/final/ |
||||
02_Progress/blog/labels/final/20170226-103222-DSCF4702.jpg |
||||
... |
||||
Number of files: 95 (reg: 45, dir: 50) |
||||
Number of created files: 95 (reg: 45, dir: 50) |
||||
Number of deleted files: 0 |
||||
Number of regular files transferred: 45 |
||||
... |
||||
sent 124,487,247 bytes received 1,106 bytes 1,791,199.32 bytes/sec |
||||
total size is 124,452,210 speedup is 1.00 |
||||
``` |
||||
|
||||
> **Hinweis** |
||||
Es wird nur ein Backup unterstützt, keine Rotierung |
||||
|
||||
Intern wird _rsync_ für den Befehl verwendet. |
||||
|
||||
## RENAME |
||||
Auf den verschiedenen Kameras habe die Bilddateien unterschiedliche Namensregeln. Mit rename werden die Bilddateien einheitlich umbenannt und bekommen einen Zeitstempel. Das vereinfacht das Dateimanagement erheblich. Die Umbenennung erfolgt auf Basis der Exif-Informationen. Eine Bilddatei wird nach folgendem Muster benannt: |
||||
`<yyyymmdd>-<hhMMss>-<Dateiname mit Dateisuffix>` |
||||
Die Dateien bekommen also einen Zeitstempel vorangestellt und sind damit chronologisch sortierbar. Der ursprüngliche Dateiname wird angehängt. Das hat den Vorteil, das es keine Namenskonflikte bei zeitgleichen Aufnahmen gibt. Außerdem wird das Duplizieren verhindert, falls ein Dateien erneut geladen und umbenannt werden. |
||||
|
||||
 Vor- und nach der Umbenennung |
||||
|
||||
**Aufgabe** |
||||
Umbenennung aller Bilddateien aus 00_Inbox und verschieben nach 01_Import. |
||||
|
||||
**Endzustand** |
||||
Keine Bilddateien mehr in 00_Inbox und in 01_Import liegen die verschobenen Bilddateien vor. |
||||
|
||||
**Durchführung** |
||||
Die Durchführung ist denkbar einfach und kann je nach Menge ein paar Sekunden dauern. |
||||
|
||||
```bash |
||||
$ fow rename |
||||
Processing jpg 5: 5 |
||||
Processing raw 2: 2 |
||||
Processing video 0: 0 |
||||
7 file(s) moved. |
||||
``` |
||||
|
||||
> **Hinweis** |
||||
Fehlt das Exif-Datum, wird nur verschoben. |
||||
|
||||
## ORGANIZE |
||||
Verteilen der importierten Bilddateien auf einzelne, unabhängige Aufgaben (Task). |
||||
|
||||
**Ausgangssituation** |
||||
Eine Menge von Bildern, evtl. für unterschiedliche Zwecke, liegen in 01_Import vor. |
||||
|
||||
**Endzustand** |
||||
Einige oder alle Bilddateien wurden in unterschiedliche 'Tasks' verschoben. Nicht mehr benötigte Bilder wurden gelöscht. |
||||
|
||||
**Durchführung** |
||||
Hier ist Handarbeit mit dem Bildbetrachter bzw. Dateibrowser gefragt. fow unterstützt bei der Verwaltung der Task-Verzeichnisse und kann RAW-Dateien dorthin nachziehen. |
||||
Das Verzeichnis 01_Import/jpg wird mit einem beliebigen Bildbetrachter gesichtet. Zusammengehörige Bilder werden in einen neuen bzw. bestehenden Task verschoben. Evtl. vorhandene Raw-Dateien nachgezogen. Nicht mehr benötigte Bilder werden aus 01_Import gelöscht. |
||||
|
||||
Ein Task ist eine Verzeichnisstruktur unter 02_Prozess. Tasks liegen aber nicht direkt unter 02_Prozess, sonder werden weiter in Unterverzeichnisse gruppiert. |
||||
Hat man z. B. Fotos für 'Bild des Tages' vom 1.9. und 2.9.2017, legt man sich zuerst die Tasks für beide Tage an. Beispiel: |
||||
|
||||
```bash |
||||
$ fow task -c=daily/20170901 |
||||
$ fow task -c=daily/20170902 |
||||
``` |
||||
|
||||
Damit werden die Task-Verzeichnisse angelegt: |
||||
|
||||
 Task-Verzeichnisstruktur |
||||
|
||||
Nun kann man die JPG-Bilder in die Tasks verschieben. |
||||
|
||||
Bei fow ist immer nur ein Task aktiv. Im aktive Task kann man u. a. die RAW-Dateien aus 01_Import nachziehen. Einen vorhanden Task kann man wie folgt aktivieren: |
||||
|
||||
```bash |
||||
$ fow task -a=daily/20170901 |
||||
``` |
||||
|
||||
Man kann auch durch Vorwärts- bzw. Rückwärtsblättern (Option --next bzw. --previous) den aktiven Task wechseln: |
||||
|
||||
```bash |
||||
$ fow task --next |
||||
daily/20170901 |
||||
* daily/20170902 |
||||
dienstreise/hamburg17 |
||||
``` |
||||
|
||||
Hat man neben JPGs noch RAW-Dateien erstellt, kann man diese RAWs in den aktuelle Task aus 01_Import/raw nachziehen. Mit der Test-Option kann man auch erst mal sehen, ob noch RAWs in 01_Import existieren: |
||||
|
||||
```bash |
||||
$ fow task --raw-import --test |
||||
raw files to move (may already exists): |
||||
20170202-103548-DSCF4580.raf |
||||
``` |
||||
|
||||
## DEVELOP |
||||
Unter Develop wird der gesamte Prozess der Fotobearbeitung innerhalb eines Tasks zusammengefasst, also die Erstellung des Endbildes auf Basis eines RAW bzw. JPGs mit Hilfe von Bildbearbeitungsprogramme. Dabei wird davon ausgegangen, dass das Originalbild nicht verändert wird, sondern dass die Programme mit Sidecar-Dateien (XML) oder Projektdateien (z. B. XCF bei Gimp) arbeiten und das Ergebnis in eine neue Datei exportiert werden (z. B. jpg). |
||||
|
||||
 Verzeichnis von Task 'weekly/20170205' |
||||
|
||||
Fow unterstützt hier durch Vorgabe der Verzeichnisstruktur des Tasks: In jpg und raw liegen die Originaldateien, in work können ggf. Projektdateien abgelegt werden und final dient als Exportverzeichnis für das fertige Produkt. |
||||
|
||||
**Ausgangssituation** |
||||
Originalbilder zur Bearbeitung sind im Task abgelegt (jpg, raw). |
||||
|
||||
**Endzustand** |
||||
Endbilder liegen im Ordner 'final'. |
||||
|
||||
**Durchführung** |
||||
Erfolgt mit den jeweiligen Bildbearbeitungsprogrammen. Der letzte Schritt ist der Export nach final. Z. B. Darktable unterstützt das Festlegen des Exportverzeichnisses. |
||||
|
||||
 Export bei Darktable |
||||
|
||||
Mit fow kann man sich einen Überblick über den Bearbeitungszustand eines Task verschaffen, z. B.: |
||||
|
||||
```bash |
||||
$ fow task --long |
||||
Actual task is weekly/20170205. Listing all image files. |
||||
Reading /photo-workflow/02_Progress/weekly/20170205/jpg 2: 2 |
||||
Reading /photo-workflow/02_Progress/weekly/20170205/raw 1: 1 |
||||
Reading /photo-workflow/02_Progress/weekly/20170205/video 0: 0 |
||||
Reading /photo-workflow/02_Progress/weekly/20170205/final 1: 1 |
||||
jrftg 20170202-103548-DSCF4580 Ramification |
||||
j--tg 20170205-180804-DSCF4593 Ronneburg |
||||
``` |
||||
|
||||
Das Beispiel zeigt, dass es zwei Bilder gibt. Das erste trägt den Titel (t) 'Ramification', es hat Originalbilder in jgp (j) und raw (r), wurde bereits nach final (f) exportiert und hat gps-Daten (g). Das zweite Bild hat auch bereits einen Titel, 'Ronneburg', hat gps-Daten und liegt nur als Original-jpg vor. |
||||
|
||||
Der Befehl 'task' bietet noch weitere Optionen, u. a.: |
||||
- _--activate <task>_: Aktivieren eines bestimmten Tasks |
||||
- _--next_ und _--previous_: Wechseln in den nächsten bzw. vorherigen Task |
||||
- _--fill-final_: Ergänzen des final-Verzeichnisses aus jpg |
||||
|
||||
### EXIF-Tags |
||||
|
||||
Zum Setzen der EXIF-Tags für Titel, Beschreibung und Author, gibt es den Befehl 'exif'. Hier ein Beispiel wie alle drei Tags auf einmal gesetzt werden können: |
||||
|
||||
```bash |
||||
$ fow exif -f -t 'Pendel LXIIX' -d 'Und Autos rauschen vorbei' -a |
||||
20181205-192255-DSCF7592.jpg |
||||
o title T 2 -> Pendel LXIIX |
||||
+ description Und Autos rauschen vorbei |
||||
+ author Christian Schulzendorff 2019, CC BY-SA 2.0 |
||||
``` |
||||
|
||||
Den Wert für Author muss man sich nur einmalig erstellen und wird dann nicht mehr explizit gesetzt: |
||||
|
||||
```bash |
||||
$ fow config -s 'exif.author=Christian Schulzendorff {YYYY}, CC BY-SA 2.0' |
||||
``` |
||||
|
||||
Ebenso kann man sich gesetzten Exif-Werte mit 'fow exif' anzeigen lassen. |
||||
|
||||
## LOCATION |
||||
Nicht alle Kameras taggen GPS-Informationen an die Bilder. Oft sollen aber trotzdem die Ortsdaten (Längen- und Breitengrad, ggf. Höhe) dem Bild hinzugefügt werden. Dazu muss dann für jedes Bild die aufgezeichnete Trackdatei ausgewertet werden. Manche Navi-Herstellen bieten dazu Programme an, oder man bedient sich Programmen wie z. B. [geotag](https://geotag.sourceforge.net/). Alternativ bietet fow die Möglichkeit, die finals eines Tasks mit Tracks in einem fest definierten Verzeichnis zu taggen. |
||||
|
||||
**Ausgangssituation** |
||||
Finals (Dateien im Task-Verzeichnis 'final') sind erstellt und das Verzeichnis mit Trackdateien (gpx) ist gemountet. |
||||
|
||||
**Endzustand** |
||||
Final-Dateien sind getaggt. |
||||
|
||||
**Durchführung** |
||||
Einmalig muss das externe Verzeichnis mit den Trackdateien als config-Wert festgelegt werden. |
||||
|
||||
```bash |
||||
$ fow config -s=gps.tracks=/media/tracks |
||||
``` |
||||
|
||||
Die gpx-Dateien müssen den Datumsstempel im Format yyyy*mm*dd im Namen haben, damit sie erkannt werden, z. B.: |
||||
|
||||
```bash |
||||
$ find /media/tracks/ -name '*2017*02*0[2|5]*' |
||||
../tracks/20170205.gpx |
||||
../tracks/Christian_Schulzendorff_2017-02-02_09-10-10.gpx |
||||
``` |
||||
|
||||
Das taggen geht dann für den aktiven Task sehr einfach: |
||||
|
||||
```bash |
||||
$ fow gps -verbose |
||||
Reading /photo-workflow/02_Progress/weekly/20170205/final 2: 2 |
||||
Path to images: /photo-workflow/02_Progress/weekly/20170205/final |
||||
Path to tracks: /media/tracks |
||||
+g 20170202-103548-DSCF4580.jpg Christian_Schulzendorff_2017-02-02_09-10-10.gpx |
||||
+g 20170205-180804-DSCF4593.jpg 20170205.gpx |
||||
2 images processed, 2 gps data set (where 0 existing gps data were changed) |
||||
``` |
||||
|
||||
## EXPORT |
||||
Sind alle Bilder eines Tasks in final erstellt, werden diese von dort an ihren Bestimmungsort verteilt. Fow unterstützt dabei den lokalen Export in beliebig viele Zielordner. Für andere Ziele, wie z. B. Flickr, Instagram u. s. w. bietet fow keine Unterstützung. |
||||
Beim Export werden die Bilddateien immer nur kopiert, niemals verschoben. |
||||
|
||||
**Ausgangssituation** |
||||
Alle Bilder liegen im Task-Ordner 'final' bereit und die Exportziele sind definiert. |
||||
|
||||
**Endzustand** |
||||
Final-Dateien wurden an alle Bestimmungsorte exportiert. |
||||
|
||||
**Durchführung** |
||||
Einmalig müssen die Exportziele definiert werden, z. B. für das Jahresarchiv. |
||||
|
||||
```bash |
||||
$ fow config -s=export.archiv=../archiv/2017 |
||||
``` |
||||
|
||||
Nun können die logischen Pfade für den Export verwendet werden: |
||||
|
||||
```bash |
||||
$ fow export archiv |
||||
2 images in weekly/20170205/final |
||||
Destination: ../archiv/2017 |
||||
Copying 20170202-103548-DSCF4580.jpg. Done. |
||||
Copying 20170205-180804-DSCF4593.jpg. Done. |
||||
``` |
||||
|
||||
Existiert die Datei bereits in dem Exportverzeichnis, kann das Überschreiben mit --force erzwungen werden. Das ist nützlich, wenn finals nach dem Export doch noch mal geändert wurden. |
||||
|
||||
Alternativ kann auch durch Pfadangabe direkt in ein Exportziel kopiert werden. |
||||
|
||||
```bash |
||||
$ fow export --path=~/Bilder/Diashow/ |
||||
``` |
||||
|
||||
## CLEAN UP |
||||
Ein Task ist etwas Temporäres und hat mit der Erzeugung der final-Bilder und dem anschließenden Export in der Regel ausgedient. Fow bietet zum Aufräumen keine Unterstützung. |
||||
Wird ein Task nicht mehr benötigt und wurden alle relevanten Dateien aus dem Task kopiert, ist das Taskverzeichnis z. B. per rm zu löschen: |
||||
|
||||
```bash |
||||
$ rm -r 02_Progress/weekly/20170226 |
||||
``` |
||||
|
||||
> **Hinweis** |
||||
Der aktive Task sollte nicht gelöscht werden, da noch der config-Eintrag dazu existiert). |
||||
|
||||
|
||||
|
||||