Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Gimp 2.9.6 mit Multi-Threading in GEGL

20 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Hondo am Fr, 25. August 2017 um 12:56 #

Mir fehlt immernoch eine Funktion, mit welcher ich Arbeitsschritte in Gimp aufzeichnen kann und diese dann auf hunderte Bilder anwenden kann.

  • 0
    Von Alfredo Neumano am Fr, 25. August 2017 um 16:04 #

    Ja das wäre cool.
    Auch sind nicht alle Schritte und Funktionen als Shortcut belegbar, bzw. als batch ausführbar.

    Was natürlich der Hammer wäre, wenn es eine Schnittstelle zu externen LR/ PS Plugins hätte, dann wäre es auf ein Mal eine sehr gute Alternative zu PS

    0
    Von Stanley Switek am Fr, 25. August 2017 um 18:30 #

    Für die Massenbearbeitung von Fotos eignet sich dann vielleicht 'Darktable' besser als GIMP.

    Wenn Darktable mit LUA kompiliert wird, soll es (nicht selber probiert) sogar ab GIMP 2.9.4 als Plugin für GIMP arbeiten.
    Dann braucht es keine Schnittstellen für LR/PS. Sind doch sowieso für eine ganz andere Plattform. 8)

0
Von Bolle vom Berg am Sa, 26. August 2017 um 18:49 #

wie ich die neue Gimp-Version unter Linux testen kann, ohne vor unlösbaren Abhängigkeiten zu stranden?
apt-get build-dep gimp schleudert mir unter debian über 400 mb auf die Festplatte, wobei der Compiler dann an fehlender lib-krackelbum aufgibt, die in der distri nicht vorkommt, deren Kompilervorgang an lib-klacklackklack scheitert, die auch nicht vorhanden ist. Spätestens da hatte ich keine Lust mehr, und den ganzen Kram wieder händisch entfernt.

  • 0
    Von Bolle vom Berg am Sa, 26. August 2017 um 18:51 #

    damit sich niemand verarscht vorkommt: es scheiterte an libmypaint.

    • 1
      Von Michael Schumacher am So, 27. August 2017 um 12:07 #

      Falls du übrigens den Grund dafür suchst, warum apt-get build-dep gimp die nicht installiert hat:

      Das bringt die Abhängigkeiten des GIMP-Paket im Debian-Repository ins System. Selbiges ist aber GIMP 2.8.x, und da wird die libmypaint noch nicht benötigt.

      Der Rest der Abhängigkeiten passt, da GIMP hier eher konservativ agiert und nicht meint, bei einer neu veröffentlichen Bibliotheksversion diese gleich voraussetzen zu müssen - und falls doch, dann weil es ursächlich am Erscheinen einer solchen Version beteiligt war.

      • 0
        Von Bolle vom Berg am So, 27. August 2017 um 15:51 #

        Das war mir schon klar. Ich hatte nur die Hoffnung, dass die Abhängigkeiten für die 2.9er Versionen langen würden, da doch stretch noch nicht soo fürchterlich alte Bibliotheken besitzt. Würde das einbinden von backports-repositories was bringen?

      0
      Von nachbarnebenan am So, 27. August 2017 um 14:32 #

      Mit der libmypaint ist Vorsicht geboten und man sollte auf jeden Fall die aktuelle stabile Version 1.3 verwenden und nicht Head, da es nach der 1.3 (momentan) inkompatible Änderungen gab.
      Auch ist es eine gute Idee, das Zielverzeichnis für babl, gegl und gimp (bei mir ist das /usr/local/gimp), vor jedem Compilerlauf komplett zu entsorgen, damit keine alten Plugins oder Bibliotheken übrigbleiben, die ansonsten für schwer zu findende Probleme sorgen können.

      • 0
        Von Bolle vom Berg am So, 27. August 2017 um 15:47 #

        libmypaint ließ sich nicht kompilieren, weil "Jogl" nicht vorhanden. ist. Selbstverständlich habe ich es mit der Version 1.3 versucht. Es ist halt schade, dass es so verzwickt ist, die Entwicklerversionen von gimp zu testen.
        Das verbesserte Farbmanagement durch gegl klingt verlockend.

        0
        Von Michael Schumacher am So, 27. August 2017 um 18:12 #

        Och, das ist bei mir ungefähr einmal jährlich dran - ansonsten reicht es, jeweils bis zum autogen/configure-Schritt zurückzugehen. Es wäre auch äußerst lästig, mehrmals täglich das Verzeichnis komplett zu löschen :)

        • 0
          Von nachbarnebenan am Di, 29. August 2017 um 03:35 #

          Na ja, ich mache das per Skript, dass auch jeweils die ganzen git clean/pull, autogen, make usw. mit erledigt. Vor dem Löschen kommt alles in ein Tar und wenn am Ende nicht exit 0 rauskommt, kommt alles weg und das alte Tar wird wieder ausgepackt. Ist vielleicht nicht die schlaueste Lösung, aber funktioniert und hat mir schon manchen Ärger erspart. Allerdings mache ich das auch nur einmal in der Woche oder so…

      0
      Von Stanley Switek am So, 27. August 2017 um 21:02 #

      Ich habe das gleiche Problem mit der libmypaint. (Debian Testing)
      (Ehrlich gesagt habe ich es schon oft probiert aber noch nie geschafft GIMP 2.9.x zu bauen.)

      Laut eines Blogbeitrags auf gimp.org "GIMP 2.10 blockers and the road to 3.0"
      von Alexandre Prokoudine am 2.2.2017 sollte es 'soon' eine Flatpak Version
      von den Developer Builds geben.

      Ich habe zugegebenermassen auch keine Erfahrung mit Flatpak diesen Weg aber
      trotzdem mal verfolgt. Auf der Flatpak Seite finde ich unter 'Applications' kein solches Flatpak
      und Forumsbeiträge die auf entsprechende GIMP- bzw. das benötigte 'nightly-graphics' Flatpak
      verweisen (offensichtlich bei Red Hat lt. whois) sind nicht erreichbar.

      Wie ist also der Stand mit den Flatpacks für GIMP? Jemand auf dem Laufenden?

      • 0
        Von Michael Schumacher am Mo, 28. August 2017 um 14:58 #

        Der aktuelle Stand ist das da:

        https://git.gnome.org/browse/gimp/tree/build/flatpak/flatpak-howto.txt

        TL;DR
        Es gibt eine Anleitung, wie man ein GIMP-Flatpak bauen kann (oder konnte) und wie man diese dann verteilen könnte. Aktiv verfolgt wird das meines Wissens zur Zeit nicht.

        Aus Entwicklersicht ist es Zusatzaufwand, der die ohnehin knappe Zeit für die Entwicklung von GIMP weiter einschränkt.


        Es wäre hier also hilfreich, wenn sich jemand findet, der selbst Flatpaks haben will, und Wissen, Motivation und Zeit mitbringt und z.B. einfach mal ausprobiert, ob die zugehörige Konfigurationsdatei für GIMP noch funktioniert (bis auf die Aktualiserung der Versionsangaben von ein paar Abhängigkeiten sieht es so aus, als müsste sie: https://git.gnome.org/browse/gimp/tree/build/flatpak/org.gimp.GIMP.json).

        Für die nachhaltige Bereitstellung von Flatpaks würde es sich dann anbieten, ein Docker-Image zu haben, in dem man diese bauen kann - das kann auf der Infrastruktur die z.B. auch www.gimp.org betreibt dann mitlaufen.

    0
    Von Broker am Sa, 26. August 2017 um 19:06 #

    Ja, habe ich. Lade es hier runter und installiere "gimp-2.9.6.git.20170824" mit einem Klick:

    build.opensuse.org/package/show/home%3Amrbadguy%3Agimp-unstable/gimp

    Hat bei mir ca. 20 Sekunden gedauert.

0
Von Bolle vom Berg am Sa, 26. August 2017 um 18:49 #

wie ich die neue Gimp-Version unter Linux testen kann, ohne vor unlösbaren Abhängigkeiten zu stranden?
apt-get build-dep gimp schleudert mir unter debian über 400 mb auf die Festplatte, wobei der Compiler dann an fehlender lib-krackelbum aufgibt, die in der distri nicht vorkommt, deren Kompilervorgang an lib-klacklackklack scheitert, die auch nicht vorhanden ist. Spätestens da hatte ich keine Lust mehr, und den ganzen Kram wieder händisch entfernt.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung