- Details
- Zugriffe: 7621
Viele Fotografen, insbesondere solche, die mit DSLR-Kameras arbeiten, vertrauen auf die Macht der Raw-Bilder. Die Vorteile des Raw-Formats liegen in besseren Bearbeitungsmöglichkeiten, als das bei jpg möglich wäre. Zudem bleibt die Raw-Datei immer unverändert, wie ein Negativ. Während viele Kameras Objektivfehler bei der Erstellung von jpg-Dateien sofort korrigieren, muß bei der Nutzung von Raw-Photos dieser Schritt mit Hilfe des Raw-Konverters vorgenommen werden.
Vorraussetzung hierfür ist natürlich das der Raw-Konverter weiß, wie das Bild das mit einem bestimmten Objektiv aufgenommen wurde korrigiert werden muß, um die Objektiv-eigenen Verzeichnungen zu eleminieren. Zu diesem Zweck führen Raw-Konverter eine mehr oder weniger große Liste mit Objektiven und den zugehörigen Korrekturdaten. Die richtigen Korrekturdaten für ein Bild werden dabei aufgrund der Objektivdaten in den Exif-Daten des Raw-Bildes herausgesucht und bei Aktivierung der Objektiv-Korrektur angewendet, wodurch das Bild entzerrt wird.
Die Liste von Objektiven und deren Korrekturdaten ist aber selten vollständig. Immer wieder kommt es vor, das für ein Foto nicht das richtige Objektiv oder gar kein Objektiv aus der Liste mit Korrekturdaten erkannt wird. Eine Korrektur ist in einem solchen Fall nicht direkt möglich.
Zum Glück ist bei Corel AfterShot Pro (ASP) die Datenbank der Objektive mit Korrekturdaten auf einfache Art und Weise erweiterbar. Dabei kann man sowohl ein bisher unbekanntes Objektiv profilieren oder auch Korrekturdaten für das unbekannte Objektiv aus einer anderen Quelle beziehen und ASP bereitstellen.
Das Profilieren eines Objektivs für ASP ist an verschiedenen Stellen bereits beschrieben, im folgenden soll hingegen die Nutzung von Korrekturdaten für ASP aus dem LensFun-Projekt beschrieben werden.
Die ASP Dateistruktur
Bevor man damit beginnt Daten aus LensFun für ein Objektiv für ASP bereitzustellen, muß man erst einmal wissen, wie ASP Korrekturdaten für Objektive verwaltet und an welcher Stelle man eingreifen kann. Der genaue Ort hängt bei ASP vom Rechner-Betriebssystem ab, da ASP ja für Windows, Mac als auch Linux verfügbar ist. Im Folgenden werde ich die Verzeichnisse der Linux-ASP-Variante beschreiben. Bei den anderen Architekturen, sind die Verzeichnisse sicherlich anders, dennoch läßt sich das im Folgenden gesagte sicherlich leicht übertragen.
Unter Linux wird ASP unter /opt/AfterShot3\(64-bit\)/ installiert. In diesem Basis-Verzeichnis befindet sich auch das Unterverzeichnis
supportfiles/Profiles/LensProfiles/. Diese Verzeichnis enthält zum einen eine Datei lens-db.xml und darüber hinaus weitere Dateien für Kamera-Hersteller wie z.B. profile_nikonlenstable.txt für Nikon.
In der Datei lens-db.xml stehen die eigentlichen Korrekturdaten aller für diesen Kamerahersteller in ASP bekannten Objekltiv Korrekturdaten. Ein Eintrag sieht z.B. wie folgt aus:
<Lens raw="true" skip="false">
<Model>Nikkor 24-85mm f/2.8-4D IF AF Zoom</Model>
<Mount>nikonSLR</Mount>
<Exif provider="Nikon" id="67 48 37 62 24 30 6D 02"/>
<FocalLength max="85" min="24"/>
<Aperture>2.8</Aperture>
<CropMultiplier>1</CropMultiplier>
<Converter factor="1" detected="false"/>
<CorrectionCoefficients>
<RadialDistortion a="0.03" b="0.008" c="0.02" focal="24"/>
<RadialDistortion a="0" b="0" c="0" focal="85"/>
</CorrectionCoefficients>
</Lens>
Die Daten sind im XML-Format als einfache Text-Dateien gehalten, was es leicht möglich macht sie zu lesen oder zu bearbeiten. Jede Objektivbeschreibung beginn mit <Lens...> und endet mit </Lens>. Das gleiche Prinzip von öffnenden und schließenden Tags mit den darin stehenden Daten wird auch innerhalb der <Lens>...</Lens> Tags in ähnlicher Weise wiederverwendet. So findet man hier beispielsweise die Brennweitenangabe <FocalLength max="85" min="24"/>, und die Tags <CorrectionCoefficients>...</CorrectionCoefficients> innerhalb derer die eigentlichen Korrekturdaten z.B. als <RadialDistortion a="0" b="0" c="0" focal="24"/> nach Brennweite (focal=) sortiert stehen.
Die Korrekturdaten bestehen also letztlich aus drei Zahlen-Werten, die mit a,b und c benannt sind.
Darüber hinaus steht ebenfalls das Objektiv-Modell in den Daten (<Model>Nikkor 24-85mm f/2.8-4D IF AF Zoom</Model>) als auch eine eindeutige ID <Exif provider="Nikon" id="67 48 37 62 24 30 6D 02"/>, die aus acht in hexadezimaler Schreibweise angebenenen Zahlen besteht.
Diese ID soll im Idealfall jedes Objektiv eindeutig betimmen, d.h. es sollte keine zwei uterschiedlichen Objektive geben, die die gleiche 8-stellige ID haben. In der Realität klappt das allerdings nicht immer zu 100%. Die genaue Herkunft und Bedeutung der einzelnen 8 Zahlen ist hier (dort nach "Nikon LensID Values" suchen) erklärt.
In dem anderen Dateityp wie z.B. profile_nikonlenstable.txt steht eine Zuordnung zwischen den eindeutigen Objektiv-IDs und den Namen der Objektive, die letztlich im ASP Menü zur Objektiv-Korrektur zur Auswahl angeboten werden.
Neben diesen Dateien sucht ASP aber noch in weiteren Verzeichnissen nach Dateien mit Korrektur-informationen. Hierzu zählt insbesondere
das Verzeichnis /home/<user>/.AfterShotPro3/LensProfiles/ wobei <user> für den Linux-Benutzer steht, der sich am System angemeldet hat.
Dieses Verzeichnis bietet eine wichtige Möglichkeit neue bisher unbekannte Objektiv-Korrektur-Daten aufzunehmen, indem in diesem Verzeichnis, das ggf. erst angelegt werden muß, eine neue XML-Datei mit Korrekturdaten erstellt werden kann. Der Vorteil dieses Verzeichnisses ist, das eine Neuinstallation von Corel Aftershot oder ein Upgrade zwar die Dateien in und unterhalb von /opt/AfterShot3\(64-bit\)/ verändern oder ersetzen wird, darunter u.U. auch die lens-db.xml aber niemals Dateien im Home-Verzeichnis des Benutzers.
Zwar könnte man z.B. auch direkt die Datei /opt/AfterShot3\(64-bit\)/supportfiles/Profiles/LensProfiles/lens-db.xml ergänzen oder anpassen, bei einem Update wäre es jedoch möglich das diese Dateien überschrieben werden und somit die eigenen Änderungen verloren wären. Daher ist es besser das Verzeichnis /home/<user>/.AfterShotPro3/LensProfiles/
für eigene Anpassungen zu verwenden.
Für welches Objektiv möchte ich Korrektur-Daten einpflegen?
Bevor mal anfängt Korrektur-Daten für ein eigenes Objektiv, das von ASP bisher nicht unterstützt wird selbst zu erstellen, muß man natürlich wissen welches Objektiv man denn wirklich hat. Das hört sich einfacher an als man glaubt. Wer denkt ich habe ein 24-85, FX, F3.5-4.5-Objektiv und glaubt das müßte doch reichen irrt sich. Von diesem Objektiv gibt es gleich mehrere Varianten. Der beste Weg herauszufinden, um welches Objektiv es sich wirklich handelt ist sich die Exif-Daten von einem Bild anzusehen, das mit diesem Objektiv gemacht wurde. Zur Ermittlung von Exif-Daten existiert ein sehr leistungsfähiges Werkzeug mit dem Namen exiftool, das es sowohl für Linux als auch für Windows und den Mac gibt. Hat man ein Foto, nennen wir es mylensfoto.nef (eine Nikon-Raw-Datei) kann man auf einfache Art und Weise massenweise Informationen über das Bild im Allgemeinen (exiftool mylensfoto.nef) als auch über das Objektiv erhalten.
Der Name des Objektivs, der benötigt wird läßt sich wie folgt ermitteln:
$ exiftool -lensid mylensfoto.nef
Lens ID : AF-S VR Zoom-Nikkor 24-85mm f/3.5-4.5G IF-ED
Darüber hinaus braucht man noch die 8-stellige Lens-Id:
$ exiftool -lensid# mylensfoto.nef
Lens ID : B4 40 37 62 2C 34 B6 0E
Somit steht nun fest welches Objektiv gerne korrigiert werden möchte. Jetzt geht es darum, die entsprechenden Daten zu suchen und anschließend in eine für ASP verdauliche Form zu bringen.
Erstellen einer ASP Korrektur-Datei mit Hilfe von LensFun
LensFun ist ein OpenSource Projekt, das sich der digitalen Korrektur von Objektiv-Fehlern widmet. Es beherbergt eine immer größere Liste von Objektiven zusammen mit deren Korrekturdaten. Aus diesem Fundus läßt sich auch für ASP die notwendige Information finden.
Um die gesuchten Korrekturdaten des Objektivs zu finden, muß man zunächst den LensFun-Quellcode herunterladen und dann z.B. in /tmp auspacken. Die Korrekturdaten befinden sich dann im Verzeichnis /tmp/lensfun-0.3.2/data/db/. Da das hier gesuchte Objektiv von Nikon stammt, muß man sich die in diesem Verzeichnis befindliche Datei slr-nikon.xml ansehen. Dort findet man bei der Suche nach "24-85" verschiedene Einträge aber nur einen, der den richtigen Objektiv-Namen enthält:
<lens>
<maker>Nikon</maker>
<model>Nikon AF-S Nikkor 24-85 mm f/3.5-4.5G ED VR</model>
<model lang="en">Nikkor AF-S 24-85mm f/3.5-4.5G ED VR</model>
<mount>Nikon F AF</mount>
<cropfactor>1</cropfactor>
<calibration>
<!-- Taken with Nikon D610 -->
<distortion model="ptlens" focal="24" a="0.00771" b="-0.03274" c="0.01406" />
<distortion model="ptlens" focal="28" a="0.01346" b="-0.04515" c="0.04487" />
<distortion model="ptlens" focal="32" a="0.0165" b="-0.0444" c="0.05448" />
<distortion model="ptlens" focal="42" a="0.00831" b="-0.00929" c="0.02554" />
<distortion model="ptlens" focal="58" a="0.00581" b="-0.00104" c="0.0207" />
<distortion model="ptlens" focal="68" a="0.00072" b="0.01909" c="-0.00624" />
<distortion model="ptlens" focal="85" a="0.00148" b="0.01645" c="-0.00584" />
<tca model="poly3" focal="24" br="0.0000562" vr="1.0003064" bb="-0.0000458" vb="1.0001659" />
<tca model="poly3" focal="28" br="0.0000260" vr="1.0003036" bb="-0.0000758" vb="1.0001937" />
<tca model="poly3" focal="32" br="0.0001195" vr="1.0000822" bb="-0.0000848" vb="1.0002045" />
<tca model="poly3" focal="42" br="0.0000594" vr="0.9999884" bb="-0.0000847" vb="1.0001990" />
<tca model="poly3" focal="58" br="0.0000426" vr="0.9998852" bb="-0.0000709" vb="1.0001834" />
<tca model="poly3" focal="68" br="0.0000360" vr="0.9998503" bb="-0.0000556" vb="1.0001424" />
<tca model="poly3" focal="85" br="0.0000118" vr="0.9998654" bb="-0.0000847" vb="1.0001720" />
</calibration>
</lens>
Dieser Eintrag sollte der richtige sein, das es sich um die VR-Variante des Objektivs handelt. Auch in der LensFun- Beschreibung findet sich wieder ein <calibration> ...</calibration> Block, der für verschiedene Brennweiten die Korrektur-Daten (<distortion ... </distortion>) enthält. Diese Zeilen müssen jetzt an die Syntax der oben stehenden ASP-Beschreibungsdatei angepasst werden. Die zusätzlichen Informationen die in <tca model .../> stehen müssen weggelassen werden.
Als Vorlage kann man die oben angegebene Ausgangsdatei verwenden in die man die an ASP-Syntax angepassten distortion-Zeilen einfügt. Das Ergebnis sieht dann wie folgt aus:
<Lens raw="true" skip="false">
<Model>Nikkor 24-85mm f/2.8-4D IF AF Zoom</Model>
<Mount>nikonSLR</Mount>
<Exif provider="Nikon" id="67 48 37 62 24 30 6D 02"/>
<FocalLength max="85" min="24"/>
<Aperture>2.8</Aperture>
<CropMultiplier>1</CropMultiplier>
<Converter factor="1" detected="false"/>
<CorrectionCoefficients>
# aus den oben stehenden <distortion-/>-Angaben erzeugt:
<RadialDistortion focal="24" a="0.00771" b="-0.03274" c="0.01406"/>
<RadialDistortion focal="28" a="0.01346" b="-0.04515" c="0.04487"/>
<RadialDistortion focal="32" a="0.0165" b="-0.0444" c="0.05448"/>
<RadialDistortion focal="42" a="0.00831" b="-0.00929" c="0.02554"/>
<RadialDistortion focal="58" a="0.00581" b="-0.00104" c="0.0207"/>
<RadialDistortion focal="68" a="0.00072" b="0.01909" c="-0.00624"/>
<RadialDistortion focal="85" a="0.00148" b="0.01645" c="-0.00584"/>
</CorrectionCoefficients>
</Lens>
Zur Erstellung dieser Datei wurden die LensFun <Distortion-Zeilen - zu <RadialDistortion umgewandelt und jeweils die Werte für a, b und exakt und unverändert übernommen. Was nun noch fehlt ist die genaue Angabe des Objektiv-Namens so, wie er von exiftool ermittelt wurde, da ASP nach dieser Bezeichnung sucht, um den passenden Korrektureintrag mit gleicher "Model"-Bezeichnung zu finden. Daher müssen die Zeilen aus obiger Datei
<Model>Nikkor 24-85mm f/2.8-4D IF AF Zoom</Model>
als auch
<Exif provider="Nikon" id="67 48 37 62 24 30 6D 02"/>
noch mit den Daten aus der exiftool-Ausgabe des mit dem Objektiv gemachten Bildes versorgt werden. Diese Daten müssen ebenfalls in das von AfterShot erwartete Format umgepackt werden (siehe kursiv gesetzte Zeilen unten). Die fertige Datei sieht dann wie folgt aus:
<?xml version="1.0" encoding="UTF-8"?>
<LenseDb>
<Lens skip="false" raw="true">
<Model>AF-S VR Zoom-Nikkor 24-85mm f/3.5-4.5G IF-ED</Model>
<Mount>nikonslr</Mount>
<Exif id="B4 40 37 62 2C 34 B6 0E" provider="Nikon"/>
<FocalLength min="24" max="85"/>
<Aperture>3.5</Aperture>
<CropMultiplier>1</CropMultiplier>
<Converter factor="1" detected="false"/>
<CorrectionCoefficients>
<RadialDistortion focal="24" a="0.00771" b="-0.03274" c="0.01406"/>
<RadialDistortion focal="28" a="0.01346" b="-0.04515" c="0.04487"/>
<RadialDistortion focal="32" a="0.0165" b="-0.0444" c="0.05448"/>
<RadialDistortion focal="42" a="0.00831" b="-0.00929" c="0.02554"/>
<RadialDistortion focal="58" a="0.00581" b="-0.00104" c="0.0207"/>
<RadialDistortion focal="68" a="0.00072" b="0.01909" c="-0.00624"/>
<RadialDistortion focal="85" a="0.00148" b="0.01645" c="-0.00584"/>
</CorrectionCoefficients>
</Lens>
</LenseDb>
Wohin mit der neuen Datei?
Der letzte Schritt ist nun die fertige Beschreibungsdatei für ASP zugreifbar zu machen. Man könnte wie schon
beschrieben diese Datei in /opt/AfterShot3\(64-bit\)/supportfiles/Profiles/LensProfiles/lens-db.xml einfügen, was aber wie bereits beschrieben das Problem mit sich bringt, das diese Datei bei einem Update von ASP überschrieben werden könnte, die Änderungen somit verloren wären.
Die bessere Lösung ist daher das Benutzerverzeichnis in /home/<user>/.AfterShotPro3/LensProfiles/Lens.xml für den Benutzer <user>, der als Platzhalter für den wirklichen Linux-Benutzernamen dient. Der Name der Datei, die hier einfach einmal Lens.xml genannt wurde, ist nicht entscheidend. Wenn ASP startet und ein Bild mit diesem Objektiv bearbeitet wird, erstellt AfterShotPro3 in diesem Verzeichnis eine Datei, die dem ASP-Namensschema entspricht, ohne dabei den Inhalt zu verändern:
Lens_AF_S_VR_Zoom_Nikkor_24_85mm_f_3_5_4_5G_IF_ED_Crop_1.xml
Am Ende des Tages liegen also zwei Datein in /home/<user>/.AfterShotPro3/LensProfiles/. Einmal Lens.xml und dann die von ASP nach dem Start erzeugte Datei Lens_AF_S_VR_Zoom_Nikkor_24_85mm_f_3_5_4_5G_IF_ED_Crop_1.xml
Die Datei Lens.xml kann jetzt wieder entfernt werden.
Bei der Bearbeitung eines Bildes in ASP, das mit dem oben beschriebenen Objektiv aufgenommen wurde, sollte jetzt in ASP in der Objektiv-Korrektur automatisch das korrekte Objektiv angezeigt werden und bei der Aktivierung der Obejktivkorrektur sollte das Bild mit Hilfe der eingefügten Korrekturdaten jetzt entzerrt dargestellt werden.
Weitere Informationen und Quellen:
- Das exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/
- LensFun-Projekt: http://lensfun.sourceforge.net/
- Herkunft und Bedeutung der 8 hex-Werte in der LensID:
http://owl.phy.queensu.ca/~phil/exiftool/TagNames/Nikon.html - Der LensID composite Tag
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Composite.html - Lens calibration in AfterShotPro3
http://forum.corel.com/EN/viewtopic.php?p=241389#p241389
- Details
- Zugriffe: 12408
Some years ago I started my website using Joomla. Those days Joomla 1.5 was state of the art. Today Jommla 1.5 has reached the end of its life and support and bugfixes will end.
So it was time to upgrade my website to the latest and greatest version. Unfortunately this upgrade process is not as easy as a simple click on the upgrade button. It requires more work especially if your old site was already multilingual like mine was. You should also not expect that your 2.5 site will just look the way it used to be in 1.5. This is due to new templates that determine the overall look of your web site.In 1.5 I eg used Rhuk Milkyway. In 2.5 this template is no longer supported so I decided to use another one and thus my website now looks different than before. But it does not only look different from the old days but better ...
In the article I describe the traps I personally ran into and also describe the basic update process.So I hope some else having the same problems will find the information I compiled here useful.
The first and most important step in upgrading from 1.5 to 2.5 is to install Joomla 2.5 as well as to convert all the structures like menus, articles,as well as the database scheme ... into something suitable for joomla 2.5.
For this purpose the extension jupgrade exists that does a great job. It installes the latest versions and does the whole upgrade stuff. The resulting new website it written into a subdirectory of your existing website (usually in <joomla_root>/jupgrade). So your old website will remain online and unchanged but you can convert it and look at the result by looking at the new joomla installation in the subdirectory jupgrade.
- Details
- Zugriffe: 9307
Running your own owncloud is a great thing, having all your data on your own servers. However since all the data are now only on your servers you also have to take care to run a regular backup especially for calendar and contact information that users store in your owncloud.I also have my "owncloud" and so I also came across the backup problem since I use calendars ans contacts stored in my owncloud version 9.
Several scripts I found were not capable of backing up owncloud 9 data and thats why I started to write my own script for home use owncloud servers. It should:
- be able to backup calendars and contacts for each of the existing users. Which eg calendar of which contact has to backed up should be configurable in the script
- the backup should be in form of exports for each calendar and each addressbook with contacts not a backup of the mysql database (or tables of it) that contains all these data. By exporting data into .ics files and .vcf files its easy to reimport the data in case of data loss.
- be able to run this script by cron without user intervention
- offer a way to create a configurable count of backups so one can easily access one of the older backups. Thus this script stores each backup in a separate folder with the todays date. This folder then contains a second level folder for each user in which the backup files for this user are written
- since authentication (user/password) against ownclod server is needed to make a backup, the script should only need one user/password to backup all wanted data for all users. This is important in my eyes since the password used for authentification has to be stored in cleartext in the script. So one cleartext password of a special backup user is better than <number of users to backup> passwords that would have to be stores else.
As a result of the requirements from above, all users for which either calendars or addressbooks should be backed up, have to share each calendar, each addressbook read only to the owncloud backup user which by default is named "backup" (see AUTHUSER Shellvariable).
The script is designed for small home owncloud installations, since the way the backup is done via one single backup user to which all owncloud users have to share their calendars and addressbooks for backup is certainly not well suited for an installation with hundreds of users.
Configuration
Configuration is quite simple. You have to set the Shell-Variables in the header of the script by which it is configured. Take a look at the script first (see below) then you can better understand the following explanations.
- USER contains the owncloud users for which backups should be performed.
- AUTHUSER is the owncloud user which is used for authentification and perfoming the backup. You need to create this regular user in your owncloud and enter its password (base64-encoded; see script) into the variable AUTHPWENC in the script. The base64 encoding is just a precaution so that the cleartext-password is not readable at a glance when someone is looking at the script.
- BACKUPROOT is the filesystem path on the host on which you run the script where backups are stored
- OCSERVER is the hostname of the server
- GENERATIONS is the number of backups to keep. If there are more backups than this number, the oldest backups are deleted until maximal GENERATIONS backups are left over.
- CALENDAR[] and CONTACT[] are to bash arrays where you can easily configure which calendar/addressbook should be backuped for which user.
The calendar names and addressbook names you write into CALENDAR[], CONTACT[] are not the names you see in the web interface of owncloud. Instead you have to look at the URL of the calendar or addressbook by clicking on the chain-symbol in ownclouds web interface for calendars/addressbooks you want to back up. At the very end of the URL you will see the name owncloud uses for this addressebook. Usually this name is very similar just a lower case version of the name the user sees.
The script code
The script is a simple bash script. So just copy it into a file, make this file executable and then set the configuration shell variables in the scripts head.
#!/bin/bash## Script that does a backup of owncloud 9 calendars and contacts for # given users. In order to keep only one cleartext password # in this script not one for each user, an owncloud backup user is used# for authentification. You have to create this user (AUTHUSER) in owncloud# and all users wishing a backup of their data have to share their calendars# and contacts (read only) to this user.# # R. Krienke, Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!# Version 0.1, 2016-04-18
# owncloud users for which contacs/calendars should be backuppedUSER="john jeff cathy"
## owncloud user used for authentication against owncloud server# !!! All users above have to share their cals, contacts to this user (read only) !!!AUTHUSER="backup"
# The password of the backup user in base64 encoding for a little obfuscation# Create new password by: echo "MyPassword"|base64AUTHPWENC="TXlQYXNzd29yZAo="AUTHPW=`echo $AUTHPWENC|base64 --decode`#
# Where to store backupdata BACKUPROOT="/import/backup/owncloud/calcard"#
# hostname or ip of owncloud serverOCSERVER="owncloud"#
# Each backup is stored in one subdirectory in $BACKUPROOT with the todays date# The latest $GENERATIONS directories are kept, older ones are deleted after each run# of this script.GENERATIONS=30
# For each user to backup tell the script which calendars of this user should be backupped# The calendar names are not the ones you see in ownclouds webpage but those you# see when looking at the cal name at the end of the URL for this calendar shown in ownlouds# webpage for this calendar. Seperate multiple calendar names by space. declare -A CALENDARCALENDAR[john]="persönlich geburtstage"CALENDAR[jeff]="persoenlich geburtstage"CALENDAR[cathy]="persoenlich"
# Addr books, same like abovedeclare -A CONTACTCONTACT[jeff]="kontakte"CONTACT[cathy]="kontakte"
### configuration ends here ######################################################
echo "$0 starting caldav/carddav backup ...."
umask 0077trap "rm -f $HOME/.wgetrc" HUP KILL TERM ABRT STOPcat <<EOF >$HOME/.wgetrchttp-password = $AUTHPWhttp-user = $AUTHUSEREOFchmod 600 $HOME/.wgetrc
## get one calendar for one specific user#getcal () { local CALNAME="$1" local USER="$2" local BUSER="$3" local SERVER=$4 local ROOT="$5"
BACKUPFILE="$CALNAME.ics" TODAY=`date "+%Y-%m-%d"` BPATH="$ROOT/$TODAY/$USER" if [ -e "$BPATH/$CALNAME" ]; then rm -rf "$BPATH/$CALNAME" fi mkdir -p $BPATH 2>/dev/null
wget -q --no-check-certificate --auth-no-challenge --no-clobber \ --http-user=$BUSER -O $BPATH/${BACKUPFILE} \ "https://$SERVER/owncloud/remote.php/dav/calendars/$USER/${CALNAME}?export"
STATUS=$? echo "Status wget: $?"
if [ -e "$BPATH/$CALNAME" ]; then chmod 600 "$BPATH/$CALNAME" fi }
## get one addressbook for one specific user and addressbook#getcard() { local ADDRBOOKNAME="$1" local USER="$2" local BUSER="$3" local SERVER="$4" local ROOT="$5"
BACKUPFILE="${ADDRBOOKNAME}.vcf" TODAY=`date "+%Y-%m-%d"` BPATH="$ROOT/$TODAY/$USER" if [ -e "$BPATH/$BACKUPFILE" ]; then rm -rf "$BPATH/$BACKUPFILE" fi mkdir -p $BPATH 2>/dev/null
wget -q --no-check-certificate --auth-no-challenge --no-clobber \ --http-user=backup --http-password=$AUTHPW \ -O "$BPATH/$BACKUPFILE" \ "$SERVER/owncloud/remote.php/carddav/addressbooks/$USER/${ADDRBOOKNAME}?export" \ STATUS=$? echo "Status wget: $?"
if [ -e "$BPATH/$BACKUPFILE" ]; then chmod 600 "$BPATH/$BACKUPFILE" fi }
## Backup all calendars#for i in $USER; do CALLIST=${CALENDAR[$i]} echo "$CALLIST" for j in $CALLIST; do echo "Getting cal $i, $j" getcal "$j" "$i" "$AUTHUSER" "$OCSERVER" "$BACKUPROOT" donedone
## Backup all addressbooks#for i in $USER; do CARDLIST=${CONTACT[$i]} echo "$CARDLIST" for j in $CARDLIST; do echo "Getting card $i, $j" getcard "$j" "$i" "$AUTHUSER" "$OCSERVER" "$BACKUPROOT" donedone
## cleanup#echo "Cleaning up old backups ..."cd $BACKUPROOTif [ $? != 0 ]; then echo "$0: Cannot chdir into $BACKUPROOT. Stop" exit 1fi
NUM="+$GENERATIONS"for i in `ls -1|sort -r|tail -n ${NUM}`; do echo "Deleting: $BACKUPROOT/$i" rm -rf "$i"done
kill -TERM $$
- Details
- Zugriffe: 18809
Der Anfang
Seit 2003 betreibe ich Wetterbeobachtung in Koblenz Lay. Anfangs wurde hierzu eine ws2500 Wetterstation der Firma ELV verwendet.Zum Betreiben der Software habe ich die ws2500-Software geschrieben mit deren Hilfe Daten ausgelesen, in eine MYSQL-Datenbank geschrieben und im Web visualisiert werden können.
Inzwischen wird diese Station nicht mehr hergestellt und auch nicht mehr von ELV vertrieben. Daher war eine Neuanschaffung unumgänglich. Die Wahl viel letztlich auf eine Davis Vantage Pro 2 Station.
Der Neuanfang
Nach der Anschaffung der Davis Vantage Pro 2 stellte sich natürlich die Frage, wie man an die Daten dieser Station kommt und es schafft einen Bruch in der Anzeige der alten und neuen Daten zu vermeiden. Schließlich existierten schon Daten von ca. 8 Jahren, die natürlich weiter genutzt werden sollten. Zudem sollten die Daten der neuen Station nahtlos an die alten Daten der ws2500 anschließen.
Erhalt aller Wetterdaten
Den Weg, die ich gefunden und implementiert habe basiert auf der Wetterauswertungssoftware wview, mit deren Hilfe die Daten von zahlreichen Wetterstationen ausgelesen und auf einer Web-Seite visualisiert werden können. Der Nachteil dieser Software alleine wäre jedoch der gewesen, das ich keinen Zugriff mehr auf die bereits bestehenden ws2500-Daten gehabt hätte. Zudem erlaubt wview nur eine relativ statische Auswertung der Daten. wetter.cgi aus meinem ws2500-Paket hingegen ist rein dynamisch indem gewünschte Daten bei jedem Aufruf aus einer MYSQL-Datenbank ausgelesen, aufbereitet und graphisch in einer Webseite dargestellt werden.
Seite 1 von 3