Batch-Bearbeitung

[cicollus]

Soll ein Ordner voll Bilder oder eine ausgewählte Anzahl in einem Rutsch durch ein Gimp-Filter bearbeitet werden, so gibt es dafür auf GitHub das nettes Programm Gimp-Plugin bimp vom User alessandrofrancesconi.

Hier ist die Installation unter Linux, MacOS und Windows beschrieben.
Gehen wir diese mal kurz für Ubuntu durch:

In der Webseite oben rechts befindet sich die grüne Schaltfläche.
Durch einen Klick auf dieser gelangen wir zu einer URL. Diese wird nun kopiert.
In einem Verzeichnis unserer Wahl geben wir auf der Konsole diese nach der Eingabe von git clone ein:

git clone https://github.com/alessandrofrancesconi/gimp-plugin-bimp.git

Außerdem sollten libgimp-dev und libgl-dev installiert sein:

sudo apt-get install libgimp2.0-dev libgegl-dev

In das ausgepackte Archiv wird make und make install ausgeführt:

cd gimp-plugin-bimp
make && make install

Dies führt dazu, dass im Gimp-Plugin-Ordner ~/.config/GIMP/2.10/plug-ins sinch nun der Ordner bimp mit dem Binary bimp und einem locale-Ordner befindet.
Wird eine andere Gimp-Version benutzt, z.B. auds ein App-Image von appimage.org, so muss dann halt nur noch der Ordner bim in dessen Plugin-Verzeichnis kopiert werden.
In diesem Fall dann nach ~/.config/GIMP-AppImage/2.10/plug-ins.

Wir nun Gimp gestartet, so befindet sich unter Datei nun das Menue Batch Image Manipulation.
Hier können dann mit wenigen Klicks eine Auswahl von Bildern in einem Durchgang bearbeitet werden.

 

[mischel]

Hallo, das funktioniert auch unter OpenSuSE Tumbleweed. Hier muß man allerdings anstelle des für SuSE nicht vorhandenen gimp-tool-2.0 das Paket gimp-devel installieren. Danach make, make install und dann steht das plugin unter Datei - Bath Image Manipulation zur Verfügung.
Tschüß
der Michael

 

[cicollus]

Fein, das sollte doch mir jeder Distribution funktionieren.
Installieren ist auch nicht unbedingt erforderlich, nutzt man AppImages von https://appimage.github.io/, z.B. GIMP_AppImage-git-2.10.25-20210610-withplugins-x86_64.AppImage.

VG Jörn

 

[mischel]

Guten Abend,

na ja, für rpm-basierte Distris würde ich eigentlich schon eher einen systemkonformeren Weg bevorzugen (zypper, YAST, Discover o.ä.). Damit kann man sicher ausschließen, daß irgendwelche Abhängigkeiten nicht erfüllt werden, weil diese von den genannten Tools gleich aufgelöst und mitinstalliert werden. Gerade zypper ist da, auch wenn es ein Konsolenprogramm ist, unglaublich vielseitig und leistungsfähig und nimmt einem so viel ab - bei gleichzeitig sehr einfacher Bedienung.

@cicollus : Das von Dir verlinkte AppImage konnte weder von zypper, noch von YAST verarbeitet werden, ist also wohl nur für Debian-Derivate. Für die kann ich nicht sprechen, weil Null Ahnung.

Tschüß
der Michael

 

[cicollus]

Moin Michel, zwei mal falsch.

AppImages haben einmal die Eigenschaft ihre Abhängigkeiten mitzubringen und anderseits werden werden diese auch nicht per Paketverwaltung installiert, sondern einfach heruntergeladen und ausgeführt.

have a lot of fun
Cicollus

 

[mischel]

Moin Michel, zwei mal falsch.

...

Hallo,
da bin ich mir nicht so sicher. Wenn jedes Programm seine Abhängigkeiten selbst mitbringt, braucht man unglaublich viel Platz zum Speichern (gimp-rpm 62MB gegenüber Appimage 142MB), eigentlich das Gegenteil von Datensparsamkeit... Darüber hinaus widerspricht das ja der in Linux viel besser als in Win umgesetzten Idee von gemeinsam genutzten Dateien (libs etc.) wo immer möglich. Ein Versionswirr-Warr wird eigentlich nachhaltig ausgeschlossen, folgt man der System-Strategie.

Nicht zuletzt deshalb ist ein frisch installiertes Linux-System mitsamt aller benötigten Anwendersoftware nur einen Bruchteil so groß, wie beim "Kollegen voin Microsoft" allein das Betriebssystem belegt. Das Ganze setzt sich ja dann im Speicher fort. Im Zweifelsfall lädt sich dann jedes AppImage seine eigenen mitgebrachten Bibliotheken in irgend einer Version, obwohl diese bereits im System vorhanden wären.

Diesen großen Vorteil der Datenkonsistenz und möchte ich mir nicht dadurch zunichte machen, daß ich mir "einfach schnell mal" irgend eine Software als Image installiere und dadurch das System umgehe und außer Kraft setze... Bei Windows jammert man über fehlerhafte Installations- und Deinstallationsroutinen, weil nach einer Installation oder Deinstallation immer irgendwo ein paar Dateileichen übrigbleiben und sei es "nur" in der Registry. Das kann einem mit Linux, egal ob rpm- oder apt-gesteuert, nicht passieren. Auch der Apfel ist seit OSX mittlerweile ein unixoides System und profitiert davon. Die haben halt nur die Pfade und Pointer nachhaltig verbogen, um sich abzugrenzen.

Was Du dann mit AppImages in einem eigentlich gut gepflegten und flott laufenden Linux-System eigenhändig anrichten kannst, läuft dann im Zweifel eher in Richtung Windows-Salat...

Meinem super gut funktionierenden Paketmanager vertraue ich zu 100% - und er mir auch... ;-)

Aber alles gut und egal, jeder hat da so seine Vorlieben.

Tschüß
der Michael

P.S. Es geht ja wie zur Bestätigung des oben Geschriebenen beispielsweise schon damit los, daß nach dem Start des von Dir verlinkten AppImages zu aller erst mal gefragt wird, ob man das im System verankert haben will... Wehret den Anfängen...

 

[cicollus]

Erzähl das alles mal den Leuten, welche z. B. unter Docker programmieren.

AppImages erlaubt aktuellere Programme auszuführen, als auf das System aufgrund Abhängigkeiten installiert werden kann.
In diesem Fall von Gimp auch rückwärts.
Hier ist das Plugin health selection aktiv, welches beim Distribution Gimp wegen ausgelaufenen Python 2.7 fehlt.

Mit Verankern ist nichts weiter als eine Destop-Start-Verknüpfung gemeint.