Schlagwort-Archiv: Kompression

Bildkompression – warum ich weiter JPEG nutze

Ich bewahre gerne Dinge auf, so auch alte Video- und Bildaufnahmen. Inzwischen wird dies zum Problem, denn Festplatten werden eher teurer als billiger, Datenmengen aber immer größer. Glücklicherweise haben sich aber auch die Formate weiterentwickelt. Moderne Vertreter wie AV1 und OPUS können für Videos mit deutlich kleinerem Speicherbedarf eine gute Qualität liefern. So konnte ich diese Dateien um im Schnitt 96% verkleinern. Eins Fehlt mir aber noch: Bilddateien.

Die Formate

Für Bilder gibt es viele moderne Formate: HEIC kennt man ggf. von Mobiltelefonen und basiert auf H.265 – leider auch mit dessen Lizenzproblemen. Webp stammt von webm ab und ist primär für die Nutzung auf Webseiten entwickelt. Avif wiederum ist das Bild-Pendant zu AV1. Jxl, auch JPEG-XL genannt ist ein direkter Nachfolger des klassischen JPEG-Formates.

Der Test

Zum Testen nutze ich 24 JPEG-Bilder mit insgesamt knapp 60MB. 22 sind Handy-Bilder im Format 4032×3024, die beiden Verbleibenden stammen von älteren Digitalkameras und haben eine etwas geringere Auflösung.

Als Hardware nutze ich einen Server mit 2×E5-2640v4, was 16 Kernen bzw. 32 Threads bei bis zu 2.6GHz entspricht. 192GB RAM und die Speicherung auf NVME sollten kein Bottleneck darstellen

Als Software kommt ffmpeg zum Einsatz. Ausnahme ist heic, dies wird von meiner Version nicht unterstützt, daher muss heif-enc herhalten.

Die Geschwindigkeit

Erste Frage: Wie lange dauert das Umwandeln?

  • webp 49 Sekunden
  • jxl 58 Sekunden
  • heic 68 Sekunden
  • avif 481 Sekunden

Webp, jxl und heic sind in ähnlichen Bereichen unterwegs und codierten alle Dateien in etwa einer Minute. Avif sticht mit über 8 Minuten klar heraus, ein Umwandeln dauert also deutlich länger.

Die Größe

Der Grund für den ganzen Spaß war ja die Dateigröße. Hier muss man Bedenken, dass die Originalbilder von Digitalkameras und Mobilgeräten stammen, welche eher auf Speichergeschwindigkeit als Effizienz setzen. Bereits beim Recodieren von JPEG zu JPEG sind daher bereits Gewinne zu erwarten. Nicht erwartet habe ich aber das Ergebnis:

  • original 57.4MiB
  • jxl 31.1MiB
  • heic 20.0MiB
  • webp 11.0MiB
  • jpeg (recoded) 8.3MiB
  • avif 5.3MiB

Mit Standardoptionen sind also außer avif alle Formate großer als ein Recodieren mit jpg, welches mit 9s auch ungleich schneller als alle anderen Optionen ist.

Natürlich kann man durch passendes Ändern der Parameter hier noch viel rausholen und vermutlich deutlich andere Ergebnisse erhalten.

Kompatibilität

Das schönste Bild hilft nichts, wenn man es nicht öffnen kann. Linux-User haben hier oft bessere Karten, da der native Support deutlich breiter ausfällt. JPEG und JXL zeigten bei mir die beste Usability, da Thumbnails auch ohne Gebastel direkt erzeugt wurden. Mit der internen Bildvorschau (EOM/EOG) ließen sich alle Dateitypen öffnen. Auch GIMP zeigte sich von der Vielfalt unbeeindruckt.

Qualität

…ist vermutlich eine persönliche Entscheidung. Für meinen Anwendungsfall des „Weglegen-falls-man-es-doch-noch-brauch“ ist quasi alles, was nicht offensichtliche Artefakte zeigt, brauchbar. Ich kann bei AVIF und den Re-Encoded JPEG Abstriche in den Details sehen. AVIF und WebP zeigen eine geringere Sättigung.

Fazit

Tja, nun, nicht ganz, was ich erwartet habe. Besonders enttäuscht hat mich AVIF – eine vielfach längere Umwandlungszeit für massiv schlechtere Qualität hätte ich nicht erwartet. Die neuen Formate brauchen durch die Bank deutlich länger und bringen gegen eine Rekompression in JPEG mir nicht wirklich Vorteile. Wenn man die JPEG-Qualität passend dreht, hat man eine ähnliche Dateigröße und Bildqualität bei einem Bruchteil der benötigten Umwandlungszeit. Für Personen, welche Wert auf hohe Qualität legen oder mit nicht per Kamera erstellten Motiven arbeiten, können neue Formate eine sinnvolle Sache sein, für meinen Zweck scheint aber der über 30 Jahre alte Formatsenior wohl weiter die bessere Wahl.

BitBastelei #193 – Backups unter Linux » Borg Backup

BitBastelei #193 - Backups unter Linux » Borg Backup

(47.8 MB) 00:36:23

2016-04-17 10:00 🛈

Existiert kein Backup, sind die Daten nicht wichtig

Diese Aussage ist schön provozierend, treibt gerne Leute in meiner Umgebung zur Weißglut, hat aber einen wichtigen Kern: Wer seine Daten benötigt sollte Datensicherungen haben. Während ich bei den lokalen Servern eine gut funktionierende und getestete Infrastruktur habe liegen mir externe Dienste etwas im Magen. Auf allen Systemen habe ich direkten Zugriff, die Daten sollen übers Netz auf ein Zielsystem gesichert werden. Die Übertragung muss verschlüsselt erfolgen, als zusätzliche Hürde ist die Bandbreite recht gering: Je nach Last kann diese schon mal auf wenige MBit/s sinken oder gar ganz abbrechen. Weiterhin benötige ich schnellen Zugriff auf einzelne Dateien der Sicherung und die Möglichkeit auch ältere Revisionen einer Datei zu erhalten. Hier setzte ich lange Zeit auf rdiff-backup.

Videoinhalt

  • 01:06 Meine Anforderungen
  • 02:51 rdiff-backup // Wie lief mein Backup bisher?
  • 05:10 OwnCloud/BTSync/Sparkleshare
  • 06:33 Unison
  • 07:36 Obnam
  • 10:18 BORG › Was ist BORG?
  • 12:42 BORG › Geschichte
  • 13:39 BORG › Aufbau & Code
  • 14:32 BORG › Sicherheit
  • 15:47 BORG › Kompression
  • 17:39 BORG › Deduplizierung
  • 19:45 BORG › DEMO
  • 33:28 BORG › EOT

rdiff-backup

Das Programm arbeitet über eine SSH-Verbindung und kann nahezu alle unter Linux auftretenden Dateitypen verarbeiten. Auch ACL & Co. ist üblicherweise kein Problem. Wie der Name schon andeutet werden bei bestehenden Dateien nur Änderungen übertragen. Auf dem Zielsystem findet sich nach dem Backup der letzte Stand direkt zugreifbar im Dateisystem – perfekt wenn man nur eine gelöschte Datei schnell zurückspielen muss. Ältere Versionen (bzw. die Differenzen) werden in einem zusätzlichen Ordner gespeichert, über die Software lassen sich ältere Versionen der Dateien dann rekonstruieren.

Eigentlich war ich recht zufrieden mit diesem System. Backupfehler traten nur selten auf, der Restore war einfach und der Ressourcenverbrauch überschauber. Nicht ganz so prickelnd: Die Software, welche auf Python 2 (ja, nicht 3) basiert, hat seit 2009 kein Update mehr gesehen. Zum einen ein Problem wegen der nur schwer noch zu installierenden Python-Version, zum Andern gibt es Gerüchte über mögliche Datenverluste. Auch bei mir hat es zuletzt durch Netzabbrüche das Repository zerlegt, sodass ich mich auf die Suche nach Alternativen machte.

Owncloud, Sparkleshare, BTSync & Co

…sind auf Desktop-Systemen schöne Systeme, für Datensicherungen aber eher wenig geeignet. Zwar gibt es die Möglichkeit auf ältere Versionen zugreifen zu können, die Archivverwaltung ist aber meist nicht sehr flexibel. Auch die Unterstützung erweiterter Attribute ist prinzipbedingt meist nicht gegeben. Größtes Problem für mein Vorhaben: Mit großen Datenmengen kommen solche Programme nicht wirklich klar.

Unison

Unison fällt in etwa in die selbe Kategorie, schien aber besser optimiert. Leider zeigt sich die Revisionsverwaltung für meine Zwecke etwas unflexibel. Auch die genutzte Programmiersprache OCaml ist nicht unbedingt etwas, was für mich leicht anpassbar aussieht. Zuletzt ist auch hier die Unterstützung von Metadaten unter Linux noch ausbaufähig.

Obnam

…wird bei vielen als „Drop-In-Replacement“ beworben. Die Funktionen ähneln rdiff-backup, jedoch wird zusätzlich eine Deduplizierung und Verschlüsselung unterstützt. Die Software muss nur auf einem System installiert werden, am Ziel werden „Chunks“ abgelegt, ein direkter Zugriff auf Dateien ist entsprechend nicht mehr möglich.

Bei mir wollte die Software nicht sonderlich mitspielen – Backups dauerten ewig, Verbindungsabbrüche führten zu verwaisten Locks und Mangels brauchbarem Verbose-Mode ist nur schwer zu ermitteln was genau die Software aktuell überhaupt versucht zo erledigen.

(Wir sind die) Borg

Der Funktionsumfang von BorgBackup ist Ähnlich zu Obnam: Deduplizierung, Kompression, Verschlüsselung und Co. Der Fork der Software Attic hat vor kurzem die Version 1.0.0 erreicht. Hier ist der direkte Zugriff nicht über ein FUSE-Modul möglich. Mit Ausnahme von dateisystemspezifischen Attributen werden ACLs und Xattr samt den meisten Device-Files und FIFOs mitgesichert.

Erster Eindruck: Scheint recht sauber zu laufen, das Projekt sieht gut dokumentiert aus. Die Optionen erlauben es alle Dateien und laufenden Abläufe auf der Konsole anzuzeigen – gerade bei meiner Konstellation sehr praktisch, da ich so direkt sehe ob überhaupt noch etwas passiert. Obendrein kann man auch gleich die Effizienz von Kompression und Deduplizierung schon während des Backups sehen. Die fehlende Konfigurationsdatei lässt sich über passende Shellscripte kompensieren, führt auf meinem 1080p-Monitor allerdings auch zu einem 4-zeiligen Progammaufruf. Der 200GB-Datensatz eines meiner Server mit 10 Revisionen passt auf etwa 75GB. Minuspunkte gibt es für die Tatsache, dass das Grundsystem (mit Ausnahme von Kompression/Deduplizierung) nicht mit mehreren Threads klar kommt. Gerade bei großen Repositories führt das doch zu der ein oder anderen Wartezeit.

Momentan sieht BORG als vielversprechendste Lösung aus, bietet es doch den größten Funktionsumfang, eine aktive Weiterentwicklung und bisher keine nennenswerten Programmfehler. Sicher nicht so ausgearbeitet wie große Lösungen wie Amanda oder Bacula, für die meisten Anwendungen aber ausreichend und wesentlich einfacher einzurichten.

BitBastelei #76 (Part 2/2) Installation von Arch Linux

BitBastelei #76 (Part 2/2) Installation von Arch Linux

(85.3 MB) 00:49:04

2013-12-29 11:00 🛈
Die grundlegenden Schritte lassen sich auf https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation finden.

Die Hintergründe warum ich installiere und was meine Ziele sind finden sich in Part 1.

Inhalt
======
00:13 Download
01:05 USB-Stick zur Installation vorbereiten
02:49 Dateiintegrität per md5sum prüfen
03:30 Boot von USB-Stick
05:20 Wenns nicht bootet: acpi=off
07:00 Internetzugang konfigurieren
08:37 Tastatur auf Deutsch umschalten
08:47 Partitionieren der Festplatte
12:21 Formatieren der Partitionen (1 swap/ext2)
13:14 Verschlüsseln einer Partition mit cryptsetup
16:28 Formatieren der Partitionen (2 btrfs)
17:30 Mounten der Partitionen
18:44 Mirrorliste
19:49 Installation des Grundsystems
21:18 Erstellen einer fstab
21:47 Wechsel ins neue System
22:07 Konfiguration: locale-gen, Sprache, Keymap, Zeitzone, Hostname
24:40 initrd für Verschlüsselung anpassen
26:04 Bootloader installieren & konfigurieren
28:20 Passwort setzen
28:44 Erster Start ins neue System
29:50 Netzwerk & Installation von SSH
30:29 Dienste per Systemd
31:18 Desktop Environments: KDE/GNOME/XFCE/LXDE
33:15 Softwareinstallation: Gruppen, Provider, Optionale Abhängigkeiten, Suche
36:06 AUR: Übersicht
37:37 AUR: Installation per Hand
40:45 AUR: Installation per yaourt
43:38 fstab: Kompression für btrfs
45:16 Anlegen eines Users
45:34 Installation eines Grafikservers
46:10 Start des LXDM
46:37 Netzwerkkonfiguration per NetworkManager
47:25 Deutsche Tastatur in der grafischen Oberfläche
47:53 Anpassen des Panels: Akkumonitor
48:20 Fazit

Ergänzungen:
============
02:19 – Korrektur: bs=4M – dd if=archlinux….iso of=/dev/sdx bs=4M
07:53 – Wenn bereits beim Booten ein Netzwerkkabel eingesteckt ist bezieht der Rechner bereits eine IP, dieser Schritt kann dann entfallen
08:29 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Wireless
10:03 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Using_cgdisk_to_create_GPT_partitions
11:40 – SWAP = Auslagerungsspeicher, Erweiterung des RAMs auf der Festplatte. Hiermit kann das System selten genutzte Daten des Arbeitsspeichers auf die Festplatte verschieben und so den schnelleren RAM zur Verfügung halten.
20:26 – https://wiki.archlinux.org/index.php/Grub#UEFI_systems_2
42:53 – …und ein RM, welches jedoch auch OK aussieht…
46:49 – Wenn man immer Netzwerk möchte sollte man den Dienst automatisch starten: „systemctl enable NetworkManager“

Hinweise:
=========
Nicht vergessen: Es gibt keine 100%ige Sicherheit. Da die Bootdateien hier zum Beispiel nicht verschlüsselt sind könnte ein Angreifer an dieser Stelle ansetzen und den Kernel infizieren. Erschweren kann man dieses vorgehen z.B. durch ein Bootloader-Passwort, einen modifizierten Bootloader für verschlüsselte Partitionen oder durch dsa Auslagern der Boot-Dateien auf einen USB-Stick. Auch kann man z.T. mit Kältespray und entsprechender Hardware das RAM auslesen und so den Verschlüsselungskey zusammensetzen. Ebenfalls bringt die Verschlüsselung nichts, wenn eine Applikationslücke genutzt wird.