Die Umstellung auf GTK4 ist für Shotwell mehr als eine optische Modernisierung. Gerade unter Arch Linux mit aktuellem GNOME und Wayland profitiert die Anwendung von den moderneren Schnittstellen des Toolkits. Auch Funktionen wie Drag-and-drop und Desktop-Portale sollen dadurch zuverlässiger funktionieren.

Für meinen Test habe ich Shotwell unter Arch Linux allerdings nicht aus den Paketquellen, sondern als Flatpak installiert. Das ist gerade bei größeren GNOME-Anwendungen interessant, wenn ihr eine aktuelle Version ausprobieren möchtet, ohne auf den Paketstand der Distribution warten zu müssen. Auch lassen sich die Daten der Anwendung schnell rückstandsfrei löschen.

GTK4 bringt Shotwell nach vorn

Shotwell 0.33 bringt neben der GTK4-Portierung zahlreiche kleinere Verbesserungen mit. Dazu gehören eine Übersicht der Tastaturkürzel, überarbeitete Funktionen zum Exportieren und Drucken sowie Toasts als moderne Alternative zu einfachen Dialogfenstern. Auch das Öffnen von URLs im Viewer wurde ergänzt.

Einige Funktionen, die während der GTK4-Portierung vorübergehend fehlten, sind ebenfalls wieder zurück. Dazu gehört insbesondere Drag-and-drop. Außerdem zeigt der Viewer zusätzliche Systeminformationen an, während sich Kontextmenüs nun auch per Tastatur öffnen lassen. Die Navigation zwischen Bedienelementen wurde ebenfalls verbessert.

Veröffentlichung und Fehlerkorrekturen

Überarbeitet wurde zudem die Veröffentlichung von Bildern an externe Dienste. Das Fenster für die externe Authentifizierung kann nun an verschiedenen Stellen angezeigt werden. Den bisherigen separaten Authentifizierungshelfer ersetzt Shotwell durch einen einfachen Webserver, der lokal auf dem Rechner läuft.

Dazu kommen zahlreiche Fehlerkorrekturen. Unter anderem wurden Probleme mit automatisch ausgeblendeten Werkzeugleisten im Vollbildmodus, der Diashow, dem Setzen von Desktop-Hintergründen und dem Versand vieler Bilder behoben. Auch die Arbeit mit Gesichtern und deren Markierungen wurde weiter verbessert.

Mein Eindruck unter Arch Linux

Für mich ist die GTK4-Portierung die eigentlich interessante Nachricht dieses Releases. Shotwell wirkt damit deutlich besser für aktuelle Linux-Desktops aufgestellt. Gerade unter Arch Linux und GNOME mit Wayland ist es angenehm, wenn eine ältere Anwendung nicht dauerhaft auf ihrem bisherigen GTK-Unterbau festhängt.

Wenn ihr Shotwell unter Arch Linux ausprobieren möchtet, könnt ihr zunächst prüfen, welche Version in euren Paketquellen verfügbar ist. Für meinen Test habe ich stattdessen Flatpak verwendet. Damit lässt sich die aktuelle Shotwell-Version unabhängig vom Paketstand von Arch Linux installieren und wieder entfernen. Aktuell hängt selbst Arch Linux eine Version zurück.

Die neue Version ist damit auch für Nutzer interessant, die Shotwell bisher wegen der technisch überholten GTK3-Basis nicht mehr auf dem Radar hatten. Ob die Anwendung dauerhaft als Bildverwaltung überzeugt, hängt natürlich stark vom eigenen Workflow ab. Für eine schlanke GNOME-Lösung ist sie aber einen Blick wert.

Weitere Beiträge zu GNOME und Bildern

Zum Thema Bildbearbeitung und Fotowerkzeuge findet ihr auch schon einige ältere Beiträge hier im Blog. So habe ich beispielsweise einfache Bildbearbeitung unter Linux und verschiedene Werkzeuge rund um Screenshots und die Arbeit mit Bildern vorgestellt. Auch Gradia setzt inzwischen konsequent auf GTK4.

Die aktuelle Shotwell-Version findet ihr als Flatpak auf Flathub. Wer sich für die neusten technischen Änderungen der Anwendung interessiert und dem weiteren Verlauf der Entwicklung folgen möchte, kann außerdem die offizielle Release-Ankündigung und die Projektseite von Shotwell ansehen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Mit Version 1.4 hat sich das grundlegend geändert. Gradia ist in riesigen Schritten jetzt ein vollwertiges Screenshot-Tool mit integrierten Bildbearbeitungsfunktionen geworden – ähnlich wie etwa Shutter oder Ksnip. Der große Unterschied: Gradia konzentriert sich nach wie vor darauf, aus schlichten Screenshots ansprechende Grafiken zu machen.

Was ist neu seit Version 1.1.0

Der wichtigste Unterschied zur frühen Version: Gradia kann jetzt selbst Screenshots erstellen. Das passiert entweder über den Button in der Anwendung oder – eventuell sogar praktischer – über Kommandozeilenparameter. Mit dem folgenden Kommando startet ihr die interaktive Bereichsauswahl, alternativ erstellt ihr sofort einen Vollbild-Screenshot.

$ flatpak run be.alexandervanhee.gradia --screenshot=INTERACTIVE

$ flatpak run be.alexandervanhee.gradia --screenshot=FULL

Das kann man auch dazu verwenden via Shortcuts Screenshots aufzunehmen und anschließend umgehend Gradia mit dem gerade erstellten Bild zu starten. Öffnet dazu in GNOME Einstellungen » Tastatur » Tastenkürzel anzeigen und anpassen » Eigene Tastenkürzel. Dort tragt ihr dann etwa folgendes ein.

• Name: „Screenshot mit Gradia“
• Befehl: flatpak run be.alexandervanhee.gradia --screenshot=INTERACTIVE
• Tastenkombination: Zum Beispiel Strg + Druck (der Shortcut sollte eigentlich noch frei sein)

So wird Gradia zum direkten Ersatz für andere Screenshot-Tools, nur dass das Ergebnis direkt zur weiteren Bearbeitung bereitsteht. Im Hintergrund greift Gradia auf das Screenshot-Portal von Wayland zu, sodass es zu keinen Problemen mit dem modernen Display-Server-Protokoll kommt.

Dazu kommen die Bildbearbeitungsfunktionen, die man von ähnlichen Tools kennt: Annotationen, Markierungen, Pfeile, Text und Formen. Gradia kombiniert diese Standard-Werkzeuge mit seinem ursprünglichen Ansatz – dem Aufhübschen durch Hintergründe und Effekte.

Bildbearbeitung mit Potenzial

Die neuen Annotation-Tools decken die üblichen Verdächtigen ab: Stift, Text, Linien, Pfeile, geometrische Formen, Hervorhebungen und die Möglichkeit, Bereiche unkenntlich zu machen. Für schnelle Markierungen und einfache Erklärungen reicht das vollkommen aus.

Allerdings merkt man noch, dass diese Funktionen relativ neu sind. Feineinstellungen, die man von etablierten Tools wie Shutter gewohnt ist, fehlen noch: Die Liniendicke lässt sich nicht anpassen, bei Texten kann ich nur die Schriftart ändern, aber nicht die Größe oder einen Schlagschatten hinzufügen. Das ist nicht dramatisch, aber für detailliertere Annotationen durchaus spürbar. Einen Verbesserungsvorschlag dazu gibt es bereits.

Die Stärke liegt nach wie vor in der visuellen Aufbereitung. Ein Screenshot bekommt durch die Hintergrund-Optionen, Schatten und anpassbare Seitenverhältnisse schnell ein professionelles Aussehen – ohne dass ich mich durch komplexe Menüs klicken muss.

Blitzschnelle Entwicklung

Gradia hat sich von einem Nischen-Tool für die visuelle Aufbereitung zu einem vollwertigen Screenshot-Programm entwickelt. Die Integration der Bildbearbeitungsfunktionen ist gelungen, auch wenn hier noch Raum für Verbesserungen bleibt.

Wer bereits die frühere Version nutzte, sollte definitiv ein Update machen. Die neuen Funktionen erweitern die Einsatzmöglichkeiten erheblich, ohne die ursprünglichen Stärken zu verwässern. Für neue Nutzer ist Gradia jetzt eine ernstzunehmende Alternative zu etablierten Tools wie Shutter oder Ksnip – mit dem besonderen Fokus auf ansprechende Optik.

Ihr findet die aktuelle Version wie gewohnt auf Flathub und könnt den Quellcode auf GitHub einsehen. Unter Arch und seinen Derivaten lässt sich die aktuelle Version von Gradia auch alternativ über das AUR installieren, so spart man sich die doch recht umfangreichen Abhängigkeiten von Flatpaks.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Früher habe ich für diese Aufgaben Shutter verwendet. Leider hat dieses Tool inzwischen den Support für Wayland verloren und scheint seit geraumer Zeit nicht weiterentwickelt zu werden. Als aktuelle Alternative setze ich deshalb KSnip ein, um Anmerkungen und Markierungen hinzuzufügen – Auch wenn ich dafür in Kauf nehmen muss, dass ich mir damit einen Haufen Qt-Bibliotheken ins System laden muss. Was mir jedoch immer noch fehlt, ist ein Lupeneffekt, mit dem ich kleine Details in meinen Screenshots vergrößern und hervorheben kann.

Dieser Effekt lässt sich aber schnell und einfach mit GIMP umsetzen, auch wenn es dafür keinen direkten Filter gibt. In dieser Anleitung zeige ich euch, wie ihr in wenigen Minuten einen Lupeneffekt auf euren Screenshots erstellen könnt.

Schritt-für-Schritt-Anleitung für den Lupeneffekt in GIMP

Screenshot öffnen

Öffnet zunächst euren Screenshot in GIMP. Falls ihr noch keinen Screenshot gemacht habt, könnt ihr dies direkt in GIMP erledigen: Wählt dafür im Menü Datei | Erstellen | Screenshot. Damit könnt ihr den Screenshot entweder direkt im Programm aufnehmen oder eine vorherige Aufnahme importieren.

Bereich auswählen

Wählt nun das Rechteckige Auswahlwerkzeug oder das Elliptische Auswahlwerkzeug aus der linken Werkzeugleiste aus. Zieht die Auswahl um den Bereich, den ihr vergrößern wollt – also den Bereich, den ihr später als Lupeneffekt hervorheben möchtet. Um mit dem Ellipsenwerkzeug eine kreisförmige Auswahl zu erstellen, haltet ihr während des Aufziehens mit der Maus die Umschalt-Taste gedrückt.

Sobald die Auswahl getroffen ist, drückt auf der Tastatur Strg+C, um den Bereich zu kopieren. Anschließend drückt Strg+V, um den Bereich als neue schwebende Auswahl einzufügen. Diese neue Auswahl erscheint dann im rechten oberen Bereich von GIMP unter Schwebende Ebene. Klickt mit der rechten Maustaste darauf und wählt Zur neuen Ebene aus, um die schwebende Auswahl in eine feste Ebene mit dem Namen Transformation umzuwandeln.

Vergrößern der Auswahl

Jetzt kommt der eigentliche Lupeneffekt: Wählt das Skalieren-Werkzeug aus der linken Werkzeugleiste aus und klickt auf die gerade erstellte neue Ebene. Vergrößert die Auswahl so, dass sie die gewünschte „Lupenwirkung“ erzielt. Achtet dabei darauf, das Seitenverhältnis zu sperren, damit die Proportionen der Auswahl erhalten bleiben.

Ebene an Bildgröße anpassen

Rechtsklickt auf die neue Ebene im rechten Panel und wählt Ebenen auf Bildgröße. Damit passt ihr die Ebene an die Gesamtbildgröße an, ohne dass sich die anderen Elemente auf dem Screenshot verändern.

Auswahl um den Effekt hinzufügen

Rechtsklickt wieder auf die Ebene im rechten Panel und wählt diesmal Auswahl aus Alphakanal aus. Diese Funktion macht den transparenten Bereich der Ebene auswählbar.

Kontur hinzufügen

Geht nun auf Bearbeiten | Auswahl nachziehen … und passt die Eigenschaften der Umrahmung an. Ihr könnt hier die Farbe der Linie und deren Dicke wählen. Die Standardfarbe wird dabei aus der Vordergrundfarbe von GIMP übernommen. Eine Vorschau gibt es für diese Funktion leider nicht. Klickt auf OK, um die Umrahmung anzuwenden.

Hintergrund anpassen

Zu guter Letzt könnt ihr noch einen Filter auf den Hintergrund anwenden, um den Effekt weiter zu verstärken. Eine Unschärfe oder ein Schatten auf der neuen Ebene sorgen dafür, dass der Lupeneffekt stärker zur Geltung kommt. Dazu könnt ihr im rechten Panel der Ebene Filter auswählen und verschiedene Optionen ausprobieren, wie z. B. Weichzeichnen oder Schatten hinzufügen.

Mit diesen einfachen Schritten habt ihr einen effektiven Lupeneffekt in GIMP erstellt. Es erfordert ein bisschen Übung und Feintuning, aber schon nach wenigen Versuchen bekommt ihr ein gutes Gefühl für die Werkzeuge und könnt sie effizient in eure Screenshot-Nachbearbeitung einbauen. Besonders praktisch: Ihr könnt die Methode für beliebige Bildbereiche anwenden, um nicht nur Text, sondern auch andere Details in euren Screenshots hervorzuheben.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

$ wget https://github.com/RH12503/triangula/releases/download/v1.2.0/triangula-linux-1.2.0.zip
$ unzip triangula-linux-1.2.0.zip
$ chmod +x Triangula
$ ./Triangula

Triangula

Zum Programm selbst möchte ich gar nicht viele Worte verlieren, da ihr sowieso selbst damit experimentieren müsst. Am besten funktionieren in meinen Augen Motive, die ein Objekt gut im Vordergrund herausstellen. Also etwa ein Porträt eines Menschen oder ein großes Objekt vor einer Landschaft. Je nach Motiv müsst ihr mit der Anzahl der Knoten, der Form des Netzes (Dreiecke oder Polygone) und den anderen Werten experimentieren. Mit einem Klick auf Start fängt das Programm an zu rechnen. Es arbeitet dann so lange am Verfeinern des Netzes, bis ihr die Rechnung mit einem Klick auf Pause (oben unter der Fensterleiste) oder auf Stop unterbricht. Das Ergebnis lässt sich dann als Datei im PNG- oder SVG-Format exportieren. Die SVG-Datei könnt ihr dann in einem vektororientierten Grafikprogramm wie Inkscape weiterbearbeiten.

FOSStriangulator

Als Alternative zu Triangula habe ich den FOSStriangulator im AUR von Arch Linux entdeckt. Dementsprechend leicht lässt es sich unter Arch und Manjaro via yay -S fosstriangulator einspielen — selbstverständlich funktioniert das auch mit allen anderen AUR-Helpern. Im Unterschied zu Triangular arbeitet der FOSStriangulator nun nicht ganz vollautomatisch, was das Programm ein wenig komplizierter macht, euch aber auch ein wenig mehr Einfluss auf das Ergebnis vermittelt. Im ersten Schritt öffnet ihr über CHOOSE AN IMAGE euer Bild in das Programm. Danach schraubt ihr erstmal über # OF EDGE POINTS die Anzahl der Knotenpunkte hoch.

Jetzt kommt der interaktive Part: Fahrt mit dem Mauszeiger die Konturen eures Motivs ab und klickt immer wieder auf eine Kante, um einen neuen Knoten zu setzen. Wieder funktionieren Motive am besten, die ein Objekt im Vordergrund deutlich herausstellen. Setzt die Punkte am Rand des Objekts und an wichtigen Details, etwa um die Nase herum, rund um die Augen oder den Mund. Habt ihr aus Versehen an einer falschen Stelle einen Knoten gesetzt, dann löscht ihr ihn über den ERASER. Ähnlich wie bei der Bildbearbeitung Gimp könnt ihr die Größe des Radiergummis einstellen. Ihr müsst mit dem Ratzefummel allerdings Klick für Klick arbeiten. Ihn durch das Bild zu wischen funktioniert nicht.

Zudem erzeugt ihr über # OF RANDOM POINTS zufällige Knotenpunkte im Bild. Um das Ergebnis jetzt zu kontrollieren, wechselt ihr den DISPLAY MODE. Die Knoten seht ihr mit einem Klick auf MESH (M). Das berechnete Bild über RESULTS (R). Dazu könnt ihr euch noch das Ergebnis der Kantenerkennung und die einzelnen Punkte ansehen. Die Ansicht lässt sich jederzeit ändern. Gefällt euch eine durch Herumprobieren gefundene Einstellung, könnt ihr sie über SAVE POINTS sichern und bei Bedarf auch später wieder in das Programm laden (LOAD POINTS). So könnt ihr in Ruhe experimentieren, ohne Angst haben zu müssen, eine gute Darstellung zu verlieren.

Den größten Unterschied macht ihr in meinen Augen schon bei der Wahl des Motivs. Den Hahn oben im Aufmacherbild habe ich in ein paar Minuten zusammengeklickt. Auch ohne große Mühe ist das Ergebnis schon fast druckreif. Ich habe einfach nur das Bild geladen, ein paar Punkte rund um die Kontur gesetzt, sowie ein paar Punkte im Gefieder markiert und schon war das Bild fertig. Der Hahn hat selbst nur wenige Details und das Tier erkennt das menschliche Gehirn auch ohne viele Informationen, das macht die Arbeit leichter. Der Strauß in den Beispielen hingegen lässt sich deutlich schwerer auf einfache Dreiecke reduzieren. Euch wünsche ich viel Spaß beim Gestalten, vielleicht schickt ihr mal eure Ergebnisse via Kommentar.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Shutter für Gnome-User

Mit dem Update Anfang des Jahres auf Version 0.95 ist das Projekt auf Github umgezogen, zudem wurden die Perl-Abhängigkeiten aktualisiert, was die Entwicklung erleichtert und die Software auf die Zukunft vorbereitet. In der Version 0.96 danach, haben die Entwickler die Oberfläche auf GTK3 aktualisiert, wodurch die Paketbauer das Projekt wieder in die Paketquellen der großen Distributionen integrieren konnten, da inzwischen viele Distributionen auf GTK2-Bibliotheken verzichten. Unter Arch Linux lässt sich Shutter daher endlich wieder ohne das AUR direkt über ein sudo pacman -S shutter installieren — natürlich auch über die Paketverwaltungs-Frontends wie etwa Pamac. Für Ubuntu und Co. betreiben die Entwickler zum Teil eigene Paketquellen, im Fall von Ubuntu in Kooperation mit dem Blog Linuxuprising.com eine PPA-Paketquelle. Sämtliche Installationsvarianten erklärt das Projekt auf seiner Homepage.

Der Vorteil von Shutter liegt darin, dass das Programm nicht nur Screenshots schießt, sondern diese auch noch verwalten und bearbeiten kann. Dazu zeigt die Anwendung im Hauptfenster eine Übersicht an. Praktisch ist, dass man nicht nur einen Screenshot eines Fensters, des Desktops oder einer Auswahl auslösen kann, sondern Shutter auch den letzten Screenshot mit einem Klick auf das erste Icon links wiederholt. Das hilft beim Erstellen von Dokumentationen zu Programmen, bei denen man nicht nur das Anwendungsfenster, sondern auch ein bisschen vom Desktop drumherum im Bild haben möchte. Beim Update auf die aktuelle Version fiel mir auf, dass die Screenshots übelst verpixelt und mit Artefakten übersät waren: Ich musste in den Einstellungen unter Allgemein den Dateityp noch auf PNG ändern.

Super hilfreich ist auch die Möglichkeit, die von Shutter geschossenen Screenshots direkt im Programm weiterzubearbeiten, ohne dass man Gimp und Co. bemühen muss. Dazu öffnet man einfach nur das entsprechende Bild und geht ganz rechts auf Bearbeiten. So könnt Ihr zum Beispiel Bereiche verpixeln oder komplett unkenntlich machen — Verpixelungen lassen sich in gewissen Grenzen wiederherstellen. Auch andere nützliche Werkzeuge wie Linien, Boxen und Kreise oder Pfeile sind mit im Programm. Für Anleitungen praktisch sind auch die fortlaufend nummerierten Ziffern in den Kreisen. So muss man sich Bilder zu Texten wie „Tippen Sie auf Schalter (1) und dann auf (2)“ einfach nur zusammenklicken.

Der aktuell noch größte Nachteil an Shutter liegt darin, dass das Programm noch nicht mit dem Display-Server Wayland zurechtkommt, der unter Gnome generell und auch Distributionen wie etwa Ubuntu inzwischen Standard ist. An dem Problem wird seit einiger Zeit gearbeitet, doch der entsprechende Bug-Report auf Github kommt nicht so schnell voran. Startet man Shutter unter Wayland, dann deaktiviert das Programm alle Screenshot-Funktionen, bis auf das Ablichten des kompletten Desktops. Ein Klick darauf startet den in Gnome integrierten Screenshooter, der dann das Bild des kompletten Desktops an Shutter durchreicht. Als Workaround bleibt einem nichts anderes übrig, als auf den klassischen Xserver umzustellen. Dazu müsst Ihr Euch vom Desktop abmelden, im Displaymanager (bei Gnome auf dem Desktop in der Regel GDM) auf das Einstellungs-Icon gehen und dann eben auf Gnome unter Xorg umstellen.

Ksnip für KDE-User

Mit noch mehr Funktionen und auch generell ein wenig runder arbeitet Ksnip, ein Programm, das — wie der Name schon andeutet — eher unter KDE zu Hause ist. Die Anwendung ist im Vergleich zu Shutter deutlich jünger, findet sich allerdings bereits in den Paketquellen der meisten aktuellen Distributionen. Die gerade aktuelle Version Ksnip 1.9.1 bekommt man nur bei Rolling-Release Distros wie Arch Linux oder Manjaro, ab Debian 12 oder Ubuntu 21.04 ist das Programm in einer älteren Ausgabe in den Paketquellen enthalten. Wer unter Ubuntu die neuste Version installieren möchte, kann auf die PPA-Paketquelle der Entwickler zurückgreifen. Optional gibt es auch Installationspakete für DEB- und RPM-basierte Distributionen auf der Github-Seite des Projekts

$ sudo add-apt-repository ppa:nemonein/ksnip
$ sudo apt update
$ sudo apt install ksnip

Bei der Auswahl der Funktionen haben sich die Entwickler von Ksnip eine ordentliche Portion bei Shutter abgeschaut: So bietet auch Ksnip die Möglichkeit gerade geschossene Screenshots zu wiederholen (unter Neu » Letzter rechteckiger Bereich) und Bildbereiche mit fortlaufenden Nummern zu markieren. Unterm Strich setzt Ksnip die Bearbeitungsfunktionen jedoch eine ganze Hausnummer ansprechender um. Das Programm hinterzeichnet so zum Beispiel Objekte wie Pfeile oder die Nummern mit einem Schlagschatten, was die Screenshots nochmal wesentlich professioneller aussehen lässt. Und auch Wayland stellt für Ksnip kein Problem dar, die Anwendung arbeitet auch unter Gnome mit Wayland ohne Komplikationen und Einschränkungen.

Praktisch ist auch das „Zielfernrohr“ beim Erstellen einer Auswahl. Die Vergrößerungsfunktion mit Fadenkreuz erspart einem später das Zuschneiden des Screenshots in einer Bildbearbeitung oder im Bearbeitungsmodus. Für Gnome-User gibt es an dieser Stelle allerdings einen kleinen Haken: Das Fadenkreuz erscheint nur in einer klassischen X11-Sitzung, unter Wayland muss man sich mit dem roten Rahmen zufriedengeben. Auf einem Gnome-System gestartet, solltet Ihr auch unter Optionen » Einstellungen » Anwendung » Tray Icon den Haken bei Benutze Tray Icon entfernen, sonst verabschiedet sich Ksnip bei einem Klick auf das Schließen-Icon im Nirwana, da Gnome die Tray-Bar schon vor einer ganzen Weile abgeschafft hat.

Für viele Nutzer ist es sicherlich auch nützlich eigene Icons oder Wasserzeichen in die Screenshots zu integrieren. Dazu öffnet Ihr wieder die Einstellungen und geht dort in den Abschnitt Annotator » Aufkleber beziehungsweise Wasserzeichen. Als Aufkleber könnt Ihr eigene SVG-Dateien hinzufügen. Schaltet Ihr dann noch unten im Dialog die Option Standard-Aufkleber nutzen ab, könnt ihr diese Bilder über das Smiley-Icon links unten in der Werkzeugleiste in den Screenshot einbauen, ähnlich wie einen Stempel. Für das Wasserzeichen braucht ihr hingegen ein teiltransparentes PNG-Bild. Über Bearbeiten » Wasserzeichen hinzufügen legt Ihr das Bild dann über den Screenshot.

In Zukunft werde ich mit Ksnip arbeiten, auch wenn ich mich sehr freue, dass es mit Shutter wieder weiter geht. Das Programm bietet aktuell einfach das beste Paket unter den Screenshootern: Sehr gute Screenshot-Funktion, die beste integrierte Bildbearbeitung und kaum Probleme oder Einschränkungen beim Einsatz unter Wayland. Alternativen wie etwa Flameshot sind mir persönlich ein wenig zu bunt oder haben wie Shutter noch Schwierigkeiten mit Wayland. Die Entwickler von Flameshot etwa bezeichnen den Support für Wayland unter Gnome und KDE noch als experimentell. Wer nach noch mehr Alternativen sucht, der wird im Wiki von Arch Linux fündig. Der Artikel listet so gut wie jede Option auf, ob mit oder ohne grafische Oberfläche.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Bei der Oberfläche hat sich Peek ganz bewusst am Screencast-Tool LICEcap für Windows orientiert: Das Programm blendet ein skalierbares transparentes Fenster ein, alles, was in dessen Rahmen liegt, wird bei einem Klick auf Record beziehungsweise Aufnahme als Video erfasst. Nach einem Klick auf Stop sichert Peek das Ergebnis dann umgehend als animiertes GIF-Bild auf die Festplatte. „Richtige“ Videoformate unterstützt Peek bislang noch nicht, Support für WebM steht jedoch nicht nur auf der To-Do-Liste, der Code dafür ist bereits fertig und landet in der nächsten Version (aktuell steht der Zähler bei Peek 0.9.1).

Peek erstellt Screencasts als GIF

Die ersten Commits von Peek stammen aus dem Dezember 2015, seitdem wurde recht aktiv am Programm entwickelt. In den letzten zwei Monaten nahm die Entwicklung jedoch besonders viel Fahrt auf, über die Mailing-Funktion von Github kommen täglich News rein. Als noch recht junges Programm findet sich Peek noch nicht in den Paketquellen der großen Distributionen. Für Ubuntu gibt es jedoch eine PPA-Paketquelle, unter Arch Linux lässt sich die Anwendung recht einfach aus dem AUR installieren. Für andere Distributionen liefert Peek die entsprechenden Installationshinweise auf der Github-Seite.

### Peek unter Ubuntu installieren:
$ sudo add-apt-repository ppa:peek-developers/stable
$ sudo apt update
$ sudo apt install peek

### Peek unter Arch Linux installieren, natürlich
### könnt ihr einen anderen AUR-Helper verwenden:
$ pacaur -Ss peek
aur/peek 0.9.1-1 (20, 1,19)
$ pacaur -S peek

Aktuell funktioniert Peek nur mit X11: Wer also bereits ein aktuelles System mit Wayland einsetzen sollte, muss bei Start des Systems auf X11 umstellen. Ist diese Voraussetzung erfüllt, arbeitet es sich mit Peek sehr einfach. Programm starten, Rahmen ausrichten und den Screencast aufnehmen. Dabei sollte man beachten, dass animierte GIFs natürlich für längere Aufnahmen nicht das perfekte Format sind. Um die Dateigröße im Rahmen zu halten, sollte man daher nur das aufnehmen, was es abzubilden gilt. Auch sehr viele Änderungen im Bild blähen die Dateigröße schnell enorm auf. Schon während Peek den Dateidialog zum Speichern des Screencasts anzeigt, baut das Programm im Hintergrund das animierte GIF zusammen, was die auf der CPU liegende Last nach oben jagt. Je nach Größe der Aufnahme dauert dieser Vorgang schnell bis zu ein paar Minuten.

Demnächst Support für Screencasts als WebM-Video

In Zukunft stehen für Peek noch eine ganze Reihe von Neuerungen an, die Enhancement-Liste auf Github listet noch viele Ideen auf. Die wichtigste Neuerung ist mit dem Support eines „richtigen“ Video-Formats wie WebM bereits umgesetzt (wie gesagt, sollte die Funktion mit der nächsten Version kommen), doch andere nützliche Funktionen wie die Möglichkeit die Aufnahme zu pausieren, einen Fensterpicker zur Auswahl des Aufnahmebereichs oder eine Fortschrittsanzeige beim Rendern der Aufnahme stehen noch auf der To-Do-Liste. Für die Zukunft wäre noch Wayland-Support wichtig, allerdings sieht es in dieser Richtung eher schlecht aus, da Wayland die dafür nötigen Funktionen nicht bietet. Die entsprechenden Bugs wurden in den letzten Tagen auf Wontfix gesetzt.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Vieles auf der Seite ist noch auf Japanisch, das Programm lässt sich jedoch auf Englisch wie auch Italienisch oder Französisch installieren. Weitere Teile der Dokumentation werden aktuell ins Englische übersetzt. Deutsch fehlt noch als Sprache gänzlich, da das Programm nun aber unter einer BSD-Lizenz steht, wird sich daran mit Sicherheit in Zukunft etwas ändern. Eine Linux-Version gibt es nicht, aber auch hier wird sich in meinen Augen schnell eine Lösung finden lassen. Da sämtliche Bibliotheken, auf die das Programm aufsetzt (Qt, Boost, CMake), auch im Linux-Universum zuhause sind, hält sich der Aufwand wahrscheinlich in Grenzen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Intels Implementierung von OpenCL fasst das Beignet Projekt zusammen. Für Beignet braucht es allerdings einen Rechner mit Chips aus der 3. Generation der Intel-Core-Prozessoren oder später, also mindestens einen Ivy Bridge als Hardware, oder eben noch aktuellere CPUs aus der Haswell- oder Broadwell- aka Rockwell-Reihe. Seid ihr euch über euren Rechner nicht im Klaren, dann lest mit cat /proc/cpuinfo den CPU-Namen aus und schlagt schnell in der Wikipedia nach, zu welcher Generation der Prozessor in eurem Computer gehört. Ich habe Beignet hier mit einem Intel Core i5-3470T mitsamt Intel HD Graphics 2500 aus der Ivy-Bridge-Klasse getestet. Mit einem Haswell werdet ihr in meinen Augen noch bessere Ergebnisse erzielen.

$ cat /proc/cpuinfo | grep name
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
model name : Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz

Beignet findet ihr seit Jessie in den Paketquellen von Debian. Bei Ubuntu gibt es OpenCL in Form von Beignet seit Trusty in den Paketquellen, allerdings nur in einer sehr alten Version. Wenn ihr unter Ubuntu mit Intels OpenCL-Implementation arbeiten möchtet, würde ich daher eher zu einem Ubuntu 15.04 „Vivid Vervet“ greifen. Bei Arch muss man sich um sowas natürlich keine Gedanken machen, allerdings muss man zur Installation von Beignet auf das Arch User Repository zurückgreifen. Dabei gilt es zu beachten, dass das Paket llvm aktuell nicht in den Abhängigkeiten aufgeführt wird. Ohne dieses bricht der Build-Prozess allerdings ab. Installiert daher das Paket vor der Installation von Beignet manuell.

### Beignet unter Arch Linux installieren
$ sudo pacman -S llvm
$ pacaur -S beignet clinfo
### Beignet unter Debian/Ubuntu installieren
$ sudo apt-get install beignet clinfo

Anschließend könnt ihr mit einem Aufruf von clinfo direkt testen, ob OpenCL auf eurem System nun auch funktioniert. Irgendwelche Einstellungen im Xserver oder andere Treiber sollten, zumindest auf Systemen mit Intel-Chipsätzen ohne eine dedizierte Grafikkarte, nicht nötig sein.

$ clinfo
Number of platforms 1
Platform Name Intel Gen OCL Driver
Platform Vendor Intel
Platform Version OpenCL 1.2 beignet 1.0.3
Platform Profile FULL_PROFILE
Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd
Platform Extensions function suffix Intel
[...]

Das von Corel vertriebene RAW-Bildbearbeitungsprogramm AfterShot Pro unterstützt nun OpenCL schon seit mehreren Versionen. Die Ergebnisse des OpenCL-Turbos sind beachtlich. Tom’s Hardware hatte Mitte 2012 in einem ausführlichen Bericht eine Beschleunigung des Exports in das JPG-Format um den Faktor 2 ermittelt. Damals allerdings noch ohne Intel-Grafikkarten und nur mit AMD und Intel als Hardware.

Es lohnt sich daher einen Blick auf AfterShot zu werfen: Damit AfterShot auf OpenCL zurückgreift, müsst ihr im Programm unter Datei | Einstellungen | Hardware-Beschleunigung die Option OpenCL verwenden aktivieren und daraufhin das Programm neu starten. Führt AfterShot hier nicht eure Grafikkarte als OpenCL-Provider auf, dann hat etwas mit der Installation von Beignet nicht funktioniert. Bei Systemen mit anderen Grafikkarten müsst ihr euch selber in Richtung OpenCL und Nvidia oder AMD schlau machen.

Neben der Haupt-Einstellung müsst ihr unbedingt dem Schieberegler OpenCL-Nutzung Beachtung schenken. Mit diesem bestimmt ihr, wie stark AfterShot Pro bei der Berechnung der Bilddaten auf die Rechenfähigkeiten der Grafikkarte zurückgreifen soll: Mehr ist hier allerdings nicht immer von Vorteil, besonders bei Systemen mit Intel-Grafik. Zum Test sucht ihr euch am besten ein definiertes Set an RAW-Bildern heraus und exportiert dieses mit einem Druck auf [F] ins JPG-Format. AfterShot zeigt die Dauer des Vorgangs dann am Ende über ein kleines Popup an.

• Aus: 1:22,5 s
• Minimum: 58,5 s
• Niedrig: 1:29,6 s
• Standard: 1:27,2 s
• Hoch: 1:23,4 s

Notiert euch die Zeit, geht wieder in die Einstellung und stellt die OpenCL-Nutzung auf den nächsten Wert. Startet AfterShot daraufhin neu, ruft erneut den Export der selben Daten auf und notiert euch wieder das Ergebnis. Wiederholt den Vorgang nun so lange, bis ihr die optimalen Einstellungen ermittelt habt. Die Intel HD Graphics 2500 aus meinem Core i5 liefert das beste Ergebnis, wenn ich die OpenCL-Nutzung nach ganz links auf Minimum setze. Mit den anderen Settings wird AfterShot Pro auf meinem System eher langsamer als schneller. Es gilt die Fausregel: Je mehr Power eure Grafikkarte besitzt, desto höher solltet ihr den Regler ziehen können.

Gegenüber dedizierten Grafik-Chips von AMD oder Nvidia kommt Intels OpenCL-Implementation auf meinem „langsamen“ Core i5 mit Intel HD Graphics 2500 zwar nicht auf einen Geschwindigkeitszuwachs um Faktor 2, allerdings wird der Berechnungsvorgang dennoch deutlich schneller. Besonders weil die Installation von Beignet nicht wirklich viel Aufwand macht und in der Regel ohne Komplikationen gelingen sollte, lohnt sich der Beschäftigung mit dem Thema.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Gifify ist ein kleines, mit Node.js entwickeltes Tool, das ohne eine grafische Oberfläche auskommt. Es ist noch so neu, dass es sich nicht einmal aus dem Arch-User-Repository aka AUR installieren lässt. Man muss es sich daher mitsamt seinen Abhängigkeiten selber bauen bzw. über den Node.js-Package-Manager installieren. Ich habe den Prozess hier auf meinem Arch-System durchgetestet, auf anderen Distributionen sollten sich die Schritte allerdings — entsprechend angepasst — auch durchführen lassen.

Gifify installieren

In einem ersten Schritt holt ihr euch mit Node.js, Git und Ffmpeg die benötigten Programme und Werkzeuge aus dem Paketquellen. Anschließend installiert ihr dann Gifify über den Npm-Paketmanager. Damit ist die Installation des Programms abgeschlossen, allerdings fehlt euch noch eine wichtige Komponente auf dem System.

$ sudo pacman -Ss nodejs git ffmpeg
$ sudo npm install -g gifify

Giflossy installieren

Gifify nutzt mit Giflossy eine überarbeitete Version des Programms Gifsicle. Die Anwendung erzeugt aus den aus der Videovorlage extrahierten Einzelbildern eine GIF-Animation und somit letztendlich das Video. Die Lossy-Variante komprimiert dabei das GIF-Bild deutlich stärker, für Videos reicht die Qualität dabei aber nach wie vor aus.

$ cd /tmp
$ git clone https://github.com/pornel/giflossy
$ cd giflossy
$ autoreconf -i
$ ./configure
$ make
$ sudo make install

Screencast erstellen

Die Aufnahme eines Screencast unter Linux gehört nun eigentlich nicht zum Thema, dennoch hier ein kleiner Software-Tipp: Mit dem SimpleScreenRecorder könnt ihr recht einfach das Geschehen auf eurem Desktop aufnehmen. In Arch Linux lässt sich das Programm über das gleichnamige Paket aus dem Community-Repositories installieren.

Videos in GIF Konvertieren

Nun habt ihr sämtliche Werkzeuge und auch einen kurzes Video auf der Festplatte liegen, sodass ihr euch im das Konvertieren eures Videos kümmern könnt. In meinem Beispiel nutze ich einen mit dem SimpleScreenRecorder aufgenommen Screencast, ihr müsstet allerdings auch alle anderen Formate und Codecs, mit denen Ffmpeg zurecht kommt, konvertieren können. Zum Einstieg schaut ihr euch am besten einmal die Hilfe-Seite von Gifify an.

$ gifify -h

Usage: gifify [options] [file]

Options:

-h, --help output usage information
-V, --version output the version number
--colors <n> Number of colors, up to 255, defaults to 80
--compress <n> Compression (quality) level, from 0 (no compression) to 100, defaults to 40
--from <position> Start position, hh:mm:ss or seconds, defaults to 0
--fps <n> Frames Per Second, defaults to 10
-o, --output <file> Output file, defaults to stdout
--resize <W:H> Resize output, use -1 when specifying only width or height. `350:100`, `400:-1`, `-1:200`
--speed <n> Movie speed, defaults to 1
--subtitles <filepath> Subtitle filepath to burn to the GIF
--to <position> End position, hh:mm:ss or seconds, defaults to end of movie

Anschließend lasst ihr Gifify auf euer Video los, im Prinzip reicht es die Quelle zu nennen und mit -o zu sagen, wohin Gifify das Ergebnis schreiben soll. Ihr habt allerdings auch die Möglichkeit die Geschwinigkeit des GIF-Videos anzupassen oder Untertitel über eine Untertitel-Datei einblenden zu lassen. Längere Videos könnt ihr mit den Optionen from und to gleich mit Gifify auf den gewünschten Ausschnitt zurechtschneiden.

### Screencast als GIF konvertieren...
$ gifify screencast-beispiel.mkv -o screencast.gif
### Screencast als GIF konvertieren und Auflösung auf 590px reduzieren...
$ gifify screencast-beispiel.mkv -o screencast-590px-breit.gif --resize 590:-1

In meinem Test funktionierte Gifify sehr gut — solange das zu konvertierende Video allerdings nicht zu groß und zu lang ist. Man sollte natürlich nicht probieren mit Gifify ein Full-HD-Video ins GIF-Format zu übertragen. Das scheitert spätestens dann, wenn die Festplatte voll läuft. Aber auch schon mehrminütige Screencasts bringen einen Intel Core i3 während der Umrechnerei quasi zum erliegen. Ich würde Gifify nur auf wirklich kurze Klipps mit weniger als 10 Sekunden Laufzeit loslassen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Gelingt es in den nächsten 30 Tagen die anvisierten 15.000 US-Dollar einzusammeln, soll mit Dmitry Kazakov ein Krita-Entwickler 6 Monate Vollzeit an Krita arbeiten können. Schafft es die Krita-Community den Betrag zu verdoppeln, stößt mit Sven Langkamp noch ein zweiter Krita-Entwickler als Vollzeitkraft hinzu. So sollen in recht kurzer Zeit 24 (oder mehr) Features in Krita 2.9 implementiert werden, über deren Priorität die Krita-Backer entscheiden können, die mehr als 30 Dollar in das Projekt gesteckt haben.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.