GIMP 2.99.12 Veröffentlicht: Ein Riesenschritt Richtung GIMP 3.0

GIMP 2.99.12 markiert einen bedeutenden Meilenstein auf dem Weg zu GIMP 3.0. Viele der noch fehlenden Komponenten fügen sich nun zusammen, obwohl es sich nach wie vor um eine Arbeitsversion handelt. Wie üblich sind Probleme zu erwarten, insbesondere in dieser Version, die wichtige Aktualisierungen in Schlüsselbereichen wie der Interaktion auf der Leinwand, Skripten und dem Theming erhalten hat. Die fortlaufende Entwicklung von GIMP 2.99.12 zeigt das Engagement des Teams, ein leistungsstarkes und benutzerfreundliches Tool zu schaffen, das professionelle Ansprüche erfüllt und gleichzeitig quelloffen bleibt.

Animation, die einen virtuellen Kampf im CMYK-Farbraum mit Pixeln zeigt

Die bemerkenswertesten Änderungen sind im Folgenden aufgeführt. Eine vollständigere Liste der Änderungen finden Sie in der NEWS-Datei oder im Commit-Verlauf.

Kernfunktionen

Pinselgrößenänderung auf der Leinwand

Es gab Anfragen nach einer schnellen Änderung von Werkzeugeinstellungen wie Pinselgröße oder Deckkraft, ohne ständig zum Dock „Werkzeugeinstellungen“ navigieren zu müssen. Eine schnell erscheinende grafische Benutzeroberfläche auf der Leinwand (ähnlich wie in anderer Software) wurde in Betracht gezogen, doch es stellte sich heraus, dass viele Nutzer eine nicht workflow-störende Interaktion bevorzugen.

Deshalb haben wir uns für ein einfacheres und direkteres Design entschieden. Beispielsweise löst jetzt Alt + rechter Mausklick eine Aktion zur Pinselgrößenänderung auf der Leinwand aus.

Änderung der Pinselgröße mit Alt + Rechtsklick auf der Leinwand in GIMP 2.99.12

Beachten Sie, dass dieser Codebereich noch in Bearbeitung ist. Weitere Interaktionen, wie die Aktualisierung der Deckkraft und die Anpassbarkeit, werden noch entwickelt (siehe nächsten Abschnitt).

Anpassbare Modifikatoren auf der Leinwand

Viele Funktionen sind auf der Leinwand verfügbar, einige davon weniger bekannt als andere, zum Schwenken, Zoomen, Drehen der Leinwand (seit GIMP 2.10.0) oder sogar zum Auswählen von Ebenen direkt auf der Leinwand (seit GIMP 2.10.10).

Die aktuellen Funktionen sind:

Hinweis: Unter macOS wird Cmd anstelle von Strg verwendet. Dies ist in der Regel impliziert, wenn nur Strg erwähnt wird.

Diese basieren auf der folgenden Logik:

• Die Haupttaste ist für Werkzeuge reserviert. Obwohl einige von ihnen eine ähnliche Logik teilen (z.B. alle Auswahlwerkzeuge teilen Modifikatoren zum Hinzufügen, Subtrahieren oder Überschneiden von Auswahlen), werden einige Werkzeuge spezifische Anwendungsfälle haben.
• Die Sekundärtaste wird für die „Navigation“ verwendet, insbesondere die Leinwandnavigation, aber auch auf einer Art z-Achse mit Ebenennavigation (die jüngste Ebenenauswahlmöglichkeit seit GIMP 2.10.10).
• Die dritte Taste war immer nur für das Kontextmenü reserviert. Die neue Fähigkeit zur Pinselgrößenänderung bricht diese Tradition.

Da wir neue Funktionen hinzugefügt haben, wurde offensichtlich, dass uns irgendwann die Modifikatoren für andere nützliche Aktionen ausgehen würden. Auch ist jeder einzigartig und hat seinen eigenen bevorzugten Workflow, sodass einige Leute definitiv ein etwas anderes Aktionsverhalten wünschen würden. Als Beispiel kommt selbst die gerade implementierte Pinselgrößenänderung bereits in 2 Varianten (Größe von der Mitte oder von den Seiten ändern).

Ganz zu schweigen davon, dass wir Rückmeldungen von Leuten hatten, die unerwartete Leinwandänderungen ablehnten, zum Beispiel, weil sie Umschalt zu früh drückten und eine Leinwanddrehung erfolgte (zugegebenermaßen ist nicht jedem die Leinwanddrehung in seinem Workflow wichtig). Darüber hinaus sind einige ältere Aktionen, wie das Kontextmenü, heutzutage fragwürdig (insbesondere, da es dasselbe Menü ist, das oben im Fenster verfügbar ist).

Aus diesem Grund wurde der Leinwand-Interaktionscode dahingehend faktorisiert, dass anpassbare Modifikatoren anstelle von fest codierten verwendet werden. Die obige Tabelle stellt weiterhin die Standardeinstellungen dar, aber jetzt können Sie sie anpassen: Fügen Sie weitere Aktionen und Modifikatoren hinzu, entfernen Sie einige oder ändern Sie alle. Die Einstellungen finden Sie unter Bearbeiten > Einstellungen > Leinwand-Interaktion > Modifikatoren. Klicken Sie dann mit einer beliebigen Maus- oder Stifttaste auf die Schaltfläche „Klicken Sie hier, um die Modifikatoren einer Taste festzulegen“, um die Modifikatoren anzupassen.

Sie können sogar „benutzerdefinierte Aktionen“ hinzufügen, d.h. alles, dem Sie eine Tastenkombination zuweisen könnten. Möchten Sie die Vordergrund-/Hintergrundfarbe mit einem Rechtsklick tauschen? Jetzt können Sie das. Möchten Sie das Werkzeug für die Einheitliche Transformation mit Umschalt-Mittelklick aktivieren und die Leinwanddrehung entfernen? Auch das ist möglich.

Neuzuordnung von Modifikatoren für On-Canvas-Interaktionen in GIMP 2.99.12

Darüber hinaus sollte dies mit jeder Taste funktionieren (nicht nur mit der zweiten und dritten). Wenn Sie also eine Maus mit 20 Tasten haben, könnten Sie jede davon einer Aktion zuordnen (sowie jede Kombination mit Modifikatoren).

Weiterhin werden verschiedene Eingabegeräte erkannt, sodass Sie denselben Tasten mehrerer angeschlossener Mäuse oder Stifte unterschiedliche Aktionen zuordnen können (beachten Sie, dass unterschiedliche Geräte exakt desselben Modells noch nicht erkannt werden, aber irgendwann wahrscheinlich schon).

⚠️ Falls Sie Fehler bei der Leinwandinteraktion feststellen, ist dies ein guter Zeitpunkt, sie zu melden, da viele Code-Updates vorgenommen wurden, um den Code generischer zu gestalten, sodass bei frühen Testern Fehler zu erwarten sind.

Testen neuer Zoom-Verhaltensweisen

Eine neue Einstellung ist unter Bearbeiten > Einstellungen > Leinwand-Interaktion verfügbar, um das Zoom-Verhalten anzupassen, wenn Sie mit Strg + Mittelklick oder Strg-Leertaste zoomen.

Der alte Algorithmus zoomte kontinuierlich, solange eine Bewegung erfolgte. Er hing nicht von der Bewegungsspanne ab, weshalb wir ihn das „Nach Dauer“-Zoomverhalten nannten.

Das neue Verhalten ist das „Nach Distanz“-Zoom, da es mehr zoomt, wenn Sie große Bewegungen ausführen, oder feiner abgestimmt mit sehr kurzen Bewegungen. Wir haben beide Verhaltensweisen als Einstellung verfügbar gelassen, da wir nach Benutzertests entschieden haben, dass einige Leute das alte Verhalten bevorzugen könnten, obwohl das neu vorgeschlagene ebenfalls sinnvoll war.

Schließlich können Sie mit der „Zoomgeschwindigkeit per Ziehen“ die Geschwindigkeit einstellen, mit der der Zoom erfolgt, in Prozent des Standards (d.h., 100 ist die Standardgeschwindigkeit; Sie können sie erhöhen oder verringern).

Diese Zoom-Einstellungen wurden von woob beigesteuert.

Verbesserte Werkzeugzeiger

Unter Bearbeiten > Einstellungen > Eingabegeräte werden Sie zunächst feststellen, dass einige Einstellungen verschoben wurden. Insbesondere zeigerbezogene Einstellungen wurden von „Bildfenster“ auf die Registerkarte „Eingabegeräte“ verschoben und neu organisiert.

Die zweite Verbesserung besteht darin, dass das Verhalten der Einstellungen überdacht wurde:

• Wenn „Pinselkontur anzeigen“ aktiviert und „Zeiger für Malwerkzeuge anzeigen“ deaktiviert ist und die Pinselkontur nicht gezeichnet werden kann (zum Beispiel, weil Sie eine Dynamik verwenden, die die Größe mit dem Druck ändert), zeigt GIMP jetzt eine Ersatzkontur mit 4 Bögen an, die die eingestellte Größe anzeigt (früher wurde ein Fadenkreuz angezeigt, was keinen Sinn machte, da „Zeiger anzeigen“ explizit deaktiviert war).
• Wenn sowohl „Pinselkontur anzeigen“ als auch „Zeiger für Malwerkzeuge anzeigen“ deaktiviert sind, zeigen wir nur ein minimales visuelles Feedback von wenigen Pixeln an, so unauffällig wie möglich, anstelle eines Fadenkreuzes. Wieder einmal bitten die Leute explizit um nichts, daher fühlte sich das Anzeigen eines Fadenkreuzes kontraproduktiv an. Doch überhaupt nichts anzuzeigen, wäre auch verwirrend. Selbst bei Tablet-Displays ist das Parallaxenproblem leider sehr real. Deshalb haben wir uns für einen extrem kleinen, punktförmigen Cursor entschieden. Er zeigt immer noch Ihre genaue Position mit geringer Störung an.

Der punktförmige Cursor wurde ursprünglich von L Amander beigesteuert, dann von Aryeom modifiziert, die ihn sowohl auf dunklem als auch auf hellem Hintergrund sichtbar machte, und der neue Zeiger wurde in bestehende Einstellungen integriert, anstatt eine dedizierte Einstellung zu erstellen.

⚠️ Diese punktförmige Cursor-Funktion ist wirklich für Tablet-Displays angepasst und kann für jede andere Verwendung als sehr schwer zu bedienen und frustrierend erscheinen (nahezu unsichtbarer Zeiger).

Zeichnen mit einem punktförmigen Cursor in GIMP 2.99.12

Weitere Verbesserung der „Linienkunsterkennung füllen“ im Füllwerkzeug

Der Modus „Linienkunsterkennung füllen“ des Füllwerkzeugs ist für uns eine große Frage, da wir die Optionen regelmäßig anpassen, um die Benutzerfreundlichkeit zu verbessern.

Die Idee ist, wie man die Einstellungen leichter verständlich machen kann, ohne die sehr fortschrittliche Leistungsfähigkeit des Werkzeugs zu verlieren.

Daher haben wir etwas Neues ausprobiert und die Optionen in 3 Kategorien neu organisiert, die den 3 Hauptschritten des Linienkunstalgorithmus entsprechen:

1. Linienkunsterkennung: Die Einstellungen, die konfigurieren, wie die Linienkunst erkannt wird: Welche Quelle wird verwendet? Deckkraft oder Graustufen verwenden? Welcher Schwellenwert?
2. Linienkunstschluss: Die Einstellungen für den Schließalgorithmus offener Linienkunstbereiche.
3. Füllränder: Die Einstellungen für die Ränder der Füllung: Wie stark soll unter die erkannte Linienkunst gewachsen werden? Wie erhält man schönere Ränder?

Zusätzlich zur Verbesserung des Füllwerkzeugs und der Linienkunsterkennung bietet die Vorgängerversion GIMP 2.99.10 weitere nützliche Funktionen, die für viele Anwendungsfälle relevant sind.

Drei Schritte im Linienkunstalgorithmus: (1) Linienerkennung, (2) Linienschluss, (3) Randstil in GIMP 2.99.12

Wir haben auch ein Kontrollkästchen „Automatisch schließen“ hinzugefügt, das dem Setzen der „Maximalen Lückenlänge“ auf Null entspricht und einfach bedeutet, dass wir keine intelligente Schließung durch einen Algorithmus wünschen. Dies ist auf diese Weise verständlicher und erleichtert den Wechsel zwischen intelligenter und keiner Schließung.

Parallel dazu wurde die Option „Linienschließung in ausgewählter Ebene zulassen“ in „Manuelle Schließung in Füllebene“ umbenannt.

Schließlich haben wir einen „Kontur zeichnen“-Modus hinzugefügt, der ähnlich wie die Funktionen „Pfad nachziehen“ oder „Auswahl nachziehen“ funktioniert und nützlich sein kann, insbesondere für sichtbare Ränder ungeschlossener Bereiche.

Weitere Iterationen zur Verbesserung der Benutzerfreundlichkeit dieses sehr schönen Werkzeugs könnten auf dem Weg zu GIMP 3.0 erfolgen.

Anpassbare Schachbrettfarben

In GIMP stellen wir Transparenz in einem Bild durch das sehr gebräuchliche „Schachbrettmuster“ dar. Um verschiedene Anwendungsfälle zu bewältigen, boten wir eine Reihe von Farben an, von hellen bis zu dunklen Grautönen, und sogar rein weiße, graue oder schwarze Hintergründe. All diese hatten jedoch die gemeinsame Eigenschaft, Grauschattierungen zu sein.

Bearbeiten > Einstellungen > Anzeige > Transparenz > Schachbrett-Stil hat jetzt eine neue Option „Benutzerdefinierte Schachbretter“, die es ermöglicht, beliebige RGB-Farben für die 2 Farben auszuwählen, die „Transparenz“ darstellen. Wenn Sie Transparenz mit Regenbogenfarben 🌈 anzeigen möchten, liegt das ganz bei Ihnen!

Die neue Funktion gimp_checks_get_colors() wurde der Schnittstelle für Plug-ins hinzugefügt und ersetzt gimp_checks_get_shades(). Dies würde jedem Plug-in, das Transparenz-Schachbrettmuster nach Benutzerwahl rendern muss, dies ermöglichen.

Dies wurde ursprünglich von Ben Rogalski beigesteuert, dann verbessert, insbesondere für die korrekte API- und Plug-in-Unterstützung.

Willkommensdialog

Erinnern Sie sich an den „Willkommensdialog“, den Sie nach einem Update erhalten (Sie haben wahrscheinlich einen in GIMP 2.99.12 erhalten)? Wir haben etwas an der Registerkarte „Versionshinweise“ gearbeitet, um „Demo“-Elemente zu ermöglichen. Das heißt, einige Elemente (mit einem anderen Aufzählungspunkt gekennzeichnet) spielen jetzt ein kurzes Szenario ab, das zeigt, worauf sich eine neue Funktion bezieht.

Dies ist immer noch eine Arbeitsversion, die nicht für alle Arten von Funktionen funktioniert, und das Styling für die Demo-„Wiedergabe“ kann definitiv verbessert werden. So sieht es im Moment aus:

Demo-Elemente in den Versionshinweisen des Willkommensdialogs in GIMP 2.99.12

Pinch-Geste für mehr Nutzung

Es war bereits möglich, die Leinwand mit einer Pinch-Geste zu zoomen seit GIMP 2.99.6. Jetzt ist es auch möglich, die Leinwand mit einer Pinch-Geste zu drehen. Beachten Sie, dass wir uns dafür entschieden haben, Zoom und Rotation über Pinch exklusiv zu gestalten, d.h. die erste erkannte Bewegung wird die Geste entweder auf Zoom oder Rotation sperren, nicht beides gleichzeitig. Es schien uns, dass Benutzer es als störend empfinden könnten, zu drehen, wenn sie nur zoomen möchten (oder umgekehrt).

Darüber hinaus können Sie jetzt die Vorschaubilder in den Dockables für Elemente (Ebenen, Kanäle, Pfade) mit Pinch-Geste oder Mausrad zoomen.

Schließlich können Sie auch im Dockable Verläufe per Pinch-Geste zoomen.

All dies wurde von Povilas Kanapickas beigesteuert, der bereits das Zoomen über Pinch-Geste auf der Leinwand implementiert hatte.

CMYK

Dieses Thema verdient in diesem Nachrichtenbericht einen eigenen Abschnitt, denn dank unseres neuen GSoC-Studenten ging es hier, nicht nur für CMYK, sondern für das gesamte Farbraum-Invasionsprojekt, recht schnell voran. Wir mussten viele der Farbkonvertierungen und -anzeigen in verschiedenen Teilen des Programms überdenken.

Simulationsdaten sind jetzt Bilddaten

Die Hauptanwendung der „Simulation“ ist das Soft-Proofing, ein sehr häufiger Anwendungsfall ist der Druck. Z.B. könnten Sie in einem RGB-Farbraum arbeiten, aber das endgültige Format kennen (z.B. durch ein von einer Druckerei erhaltenes Profil, oft ein CMYK-Profil) und sehen wollen, wie Ihr Bild gerendert würde, insbesondere hinsichtlich des Farbumfangverlusts.

Es war bereits möglich, ein „Softproof-Profil“ sowie eine Render-Intention einzustellen und ob Sie Schwarzpunktkompensation wünschen oder nicht. Doch diese Informationen gingen bei jedem Neustart der Sitzung verloren.

Diese Daten werden nun direkt in der XCF-Datei gespeichert. Sie müssen sie also nicht jedes Mal neu einstellen. Wenn Sie an einem Druckauftrag arbeiten, kann das endgültige Ziel als Teil Ihres Workflows für diesen spezifischen Druckauftrag und somit als Teil des Bildes betrachtet werden.

Als Konsequenz wurden diese 3 Informationen (Softproof-Profil, Softproof-Render-Intention und Softproof-Schwarzpunktkompensation) vom Menü Ansicht > Farbmanagement in das Menü Bild > Farbmanagement verschoben (obwohl Ansicht > Farbmanagement immer noch einige Einstellungen enthält, z.B. ob das Farbmanagement aktiviert und ob Softproof aktiviert werden soll; dies sind keine Bilddaten, sondern spezifisch für eine Ansicht: ein und dasselbe Bild kann gleichzeitig in mehreren Ansichten angezeigt werden, z.B. eine proofed und die andere nicht).

Simulationsumschalter in der Statusleiste

Um die Simulation in Ihrem Workflow zu einem erstklassigen Bürger zu machen, wollten wir eine Möglichkeit schaffen, es offensichtlich zu machen, wann Sie ein proofed Bild betrachten oder nicht. Dies geschieht über ein neues Symbol rechts in der Statusleiste. Dieses Symbol hat 3 Zwecke:

• Es zeigt visuell an, ob wir uns im Simulationsmodus (auch Softproofing genannt) befinden oder nicht.
• Es ermöglicht, durch Klicken darauf zwischen Simulations- und nicht-simulierten Modi zu wechseln.
• Es ermöglicht, Simulationseinstellungen (Simulationsprofil, Simulations-Rendering-Intent, Schwarzpunktkompensation…) mit einem Popup-Dialog durch Rechtsklicken anzupassen.

Schnelles Ändern der Softproofing-Einstellungen mit einem Umschalter in der Statusleiste in GIMP 2.99.12

Verschiedene GUIs jetzt simulationsfähig

Die meisten GUIs, die CMYK-Daten anzeigten, zeigten „naive CMYK“-Farben. Dies ist ein generischer Algorithmus, der keinen spezifischen CMYK-Farbraum berücksichtigt.

Wenn Sie jetzt ein Simulationsprofil einstellen, und dieses Profil ein CMYK-Profil ist, dann zeigen diese Schnittstellen CMYK-Farben für diesen Farbraum an, vorausgesetzt, dass dies das ist, woran Sie interessiert sind.

Dies umfasst Schnittstellen wie das Farbpicker-Werkzeug, die Messpunkte und den CMYK-Farbwähler.

Exportformate mit neuer oder verbesserter CMYK-Unterstützung

Ähnlich haben mehrere unterstützte Bildformate nun neue oder verbesserte CMYK-Unterstützung erhalten. Wir sprechen hier nicht von nativer CMYK-Unterstützung als Backend-Kodierung; GIMP arbeitet immer noch nur in entweder RGB, Graustufen oder indiziert. Dennoch können Sie jetzt CMYK-Bilder in mehreren Formaten besser importieren oder exportieren, mit wesentlich geeigneteren Konvertierungen. Insbesondere bedeutet dies, dass:

• Das CMYK-Profil importierter CMYK-Bilder als Simulationsprofil gespeichert wird. Das heißt, das Bild ist jetzt RGB, aber das CMYK-Profil wird für die Simulation beibehalten.
• RGB-Bilder können als CMYK exportiert werden, wobei das Simulationsprofil (falls ein CMYK-Profil) für die Konvertierung verwendet und dann in der resultierenden CMYK-Datei gespeichert wird.

Die Annahme ist immer, dass das Simulationsprofil Ihr Zielfarbraum ist.

Die bisher aktualisierten Formate sind:

JPEG:

• CMYK-Export ist jetzt mit dem Softproofing-Profil des Bildes möglich.
• CMYK-Import wurde auf GEGL/babl-Konvertierung portiert. Das CMYK-Profil im JPEG-Bild wird als Softproofing-Profil im Bild gespeichert.

TIFF:

• 8- und 16-Bit CMYK(A)-Export ist jetzt mit dem Softproofing-Profil des Bildes möglich.
• CMYK-Import ist jetzt möglich. Das CMYK-Profil im TIFF-Bild wird als Softproofing-Profil im Bild gespeichert.

PSD:

• CMYK-Import wurde auf GEGL/babl-Konvertierung portiert. Das CMYK-Profil im PSD-Bild wird als Softproofing-Profil im Bild gespeichert.

Neue Plug-in-API

Plug-ins können jetzt das Softproofing-Profil eines Bildes mit neuen Funktionen abfragen oder setzen, wie z.B. gimp_image_get_simulation_profile() bzw. gimp_image_set_simulation_profile(). Dies sind wirklich neue Bilddaten, die von Plug-ins verwendet werden können und sollten, wenn sie CMYK-Farben im Kontext des aktiven Bildes anzeigen oder verarbeiten möchten.

Ähnlich wurden mehrere libgimpwidgets-Widgets (GimpColorNotebook, GimpColorSelection und GimpColorSelector) simulationsfähig gemacht, mit neuen dedizierten Funktionen zum Setzen des Simulationsbereichs von Interesse.

Themen

GTK erhielt in GTK+ 3 ein neues CSS-ähnliches Theming-System, was bedeutete, dass unsere 2.10-Themes nicht wiederverwendbar waren, und deshalb haben wir oft nach Theme-Designern gerufen, weil eine Grafikanwendung wirklich einen guten Satz neutraler Grautöne für eine Benutzeroberfläche mit möglichst geringer Farbverunreinigung haben sollte, da dies Ihre Farbwahrnehmung beeinflussen kann.

Erst vor einem Monat erhielten wir einen ersten Vorschlag für ein mittelgraues, neutrales Theme, obwohl dieses noch in Arbeit ist. Auf der anderen Seite löste es unseren langjährigen Mitwirkenden, Akkana Peck, dazu aus, ein helles Theme vorzuschlagen. Mit schnellem Hin und Her wurde dieses schnell fertiggestellt und in den Quellbaum integriert. Nikc half auch sehr dabei, Lösungen für lästige Fehler zu finden, bei denen wir feststeckten.

Am Ende machten wir das Theme generischer, indem wir Farben in Variablen mit semantischen Namen umwandelten und denselben Stilcode, aber unterschiedliche Farben verwendeten, um ein dunkles Theme zu erstellen.

Anstatt 2 Themes zu haben, haben wir diese in ein „Standard“-Theme mit sowohl einer hellen als auch einer dunklen Variante zusammengeführt, die je nach der Option „Dunkle Theme-Variante verwenden, falls verfügbar“ umgeschaltet wird.

Damit dies funktioniert, haben wir auch einen neuen Prozess für Theme-Ersteller entwickelt, der auf dem generischen GTK-Prozess basiert: Ihr Theme kann eine gimp-dark.css-Datei (zusätzlich zur Haupt-gimp.css) enthalten. Diese sekundäre Datei wird anstelle der ersten verwendet, wenn die Option „Dunkle Theme-Variante verwenden, falls verfügbar“ in den Einstellungen aktiviert ist.

Das neue Standard-Theme in hellen und dunklen Varianten in GIMP 2.99.12

Dateiformatunterstützung

PSD

Zusätzlich zur neuen CMYK-Unterstützung beim Import erhielt unsere PSD-Unterstützung die folgenden Verbesserungen:

• Verbesserte Fehlerprotokollierung während des Ladens.
• Unterstützung für zusätzliche Ebenenmasken hinzugefügt: Gemäß den Spezifikationen wird die zusätzliche Maske verwendet, „wenn sowohl eine Benutzermaske als auch eine Vektormaske vorhanden sind“. Wir haben kein Beispiel gesehen, das die zusätzliche Maske enthält, daher sind wir uns nicht sicher, welche der Masken zuerst erscheinen würde. Vorerst gehen wir davon aus, dass die zusätzliche Maske zuerst kommt. Der Vorteil, dies jetzt hinzuzufügen, besteht darin, dass wir nicht versuchen werden, einen Maskenkanal als normalen Kanal hinzuzufügen.
• Minimale Unterstützung für Duplex-Daten: Beim Import wird ein Duplex-Bild als Graustufenbild mit einer Warnung importiert, und die Farbinformationen werden in einem Parasiten gespeichert; beim Export wird ein Dialog vorgeschlagen, um die Duplex-Daten erneut aufzunehmen, wenn das Bild immer noch ein Graustufenbild ist. Dies ermöglicht einen Roundtrip in GIMP, ohne die Duplex-Informationen zu verlieren.

Neue Dialoge beim Importieren (links) und erneuten Exportieren (rechts) eines PSD-Duplex-Bildes in GIMP 2.99.12

SVG

Einige gültige SVG-Dateien können beim Import fehlschlagen, wenn sie riesige Daten (verschiedener Typen) enthalten. Dies ist keine Einschränkung des Parsers, sondern eine Sicherheitsbegrenzung, da böswillige SVG-Dateien absichtlich erstellt werden können, um zu viel Speicher zu verbrauchen.

Dennoch kann dies auch bei gültigen und nicht-bösartigen Dateien passieren, da einige Benutzer Probleme mit SVG-Dateien haben, die von Sweet Home 3D (einer schönen Freeware zum Zeichnen von Innenarchitekturplänen) exportiert wurden. Wenn der Ladevorgang einer SVG-Datei fehlschlägt, schlägt GIMP daher vor, es erneut zu versuchen, wobei die Sicherheitsbegrenzung entfernt wird.

Dialog zum Deaktivieren der Sicherheitsbeschränkung bei fehlgeschlagenem SVG-Import in GIMP 2.99.12

🛈 Beachten Sie, dass GIMP keine Informationen darüber hat, ob der Ladefehler aufgrund dieses spezifischen Problems aufgetreten ist oder nicht, daher kann ein erneuter Versuch ohne Sicherheitsbegrenzung immer noch fehlschlagen, wenn der Grund ein anderer war.

⚠️ Auch sehr WICHTIG: Wie erklärt, war dies eine Sicherheitsmaßnahme, was bedeutet, dass das Deaktivieren Sicherheitsimplikationen hat. Sie sollten es nur akzeptieren, um SVG-Dateien aus vertrauenswürdigen Quellen zu laden, wie das Pop-up ebenfalls erinnert. ☢️

GIF

Eine neue Option ist im GIF-Exportdialog erschienen: „Anzahl der Wiederholungen“. Sie legt eine bestimmte Anzahl von Wiederholungen für Schleifenanimationen fest. Zuvor hatten Sie nur die Wahl zwischen einer einmaligen Animation und einer Endlosschleife.

GIF-Exportdialog mit neuer Option „Anzahl der Wiederholungen“ in GIMP 2.99.12

PNG

Die folgenden Änderungen sind in unserer PNG-Unterstützung erfolgt:

• Das Format hat kein Flag für lineares RGB, kann aber einfach ein lineares Profil (oder einen 1.0 gAMA-Chunk) enthalten. Da wir daher beim Import immer das Profil anhängen (oder den gAMA-Chunk in ein Profil umwandeln), laden wir PNG-Bilder jetzt immer als nicht-lineares Backend.
• Beim Exportieren von indizierten Bildern wird, wenn die neue Option „Für kleinstmögliche Palettengröße optimieren“ aktiviert ist, eine PNG-Datei mit der niedrigsten möglichen Bit-Tiefe der Palette exportiert (weniger als eine 8-Bit-Palette mit 256 Einträgen, falls möglich).

DDS

Die folgenden Änderungen sind in unserer DDS-Unterstützung erfolgt:

• 16-Bit-Masken werden jetzt unterstützt.
• DDS-Bilder mit einem einzigen 16-Bit-Kanal werden jetzt unterstützt.
• DDS-Bilder mit zwei 16-Bit-Kanälen werden korrekt in 16-Bit-RGB-Bilder konvertiert.
• Robustere DDS-Ladung.

FLI

Die folgenden Änderungen sind in unserer FLI-Unterstützung erfolgt:

• 1-Frame-Animationen werden jetzt korrekt geladen (es ist nicht wirklich eine Animation, aber sie sollte trotzdem geöffnet werden!).
• Ebenennamen enthalten jetzt die Verzögerung in ms.
• Robustere FLI/FLC-Ladung, doppelte Datenprüfung anstatt anzunehmen, dass der Dateischreiber die Spezifikationen korrekt befolgt hat, bessere Fehlerbehandlung…

Rohdaten

🛈 Wir sprechen hier von „Rohdaten“, bei denen Sie Ihre Pixel direkt als zusammenhängende oder planare Daten exportieren, ohne einem bestimmten Dateiformat zu folgen, und nicht von RAW-Dateiformaten, wie sie üblicherweise Formate digitaler Kameras genannt werden (für diese ziehen wir es immer noch vor, gute Raw-Entwicklungssoftware wie darktable oder RawTherapee zu verwenden).

Eine große Neufassung des Rohdaten-Dialogs (und der API) hat stattgefunden.

Zunächst ist es jetzt möglich, jede Bit-Tiefe als Rohdaten zu exportieren (trotz der höheren Bit-Tiefe-Unterstützung wurden beim Export von 16- oder 32-Bit-Bildern diese immer noch als 8-Bit-Rohdaten exportiert). Dieser Teil wird auch in der zukünftigen stabilen Version GIMP 2.10.34 verfügbar sein.

Und insbesondere können alle exportierbaren Formate wieder geladen werden, und mehr. Da dies zu einer riesigen Liste führte, wurde die Art und Weise, wie der Importdialog Formate auflistete, die Einstellungen aufgeteilt. Datentyp (vorzeichenloser oder vorzeichenbehafteter Ganzzahl, Gleitkommazahl), Endianness oder planare Konfiguration (zusammenhängend oder planar) sind jetzt eigene Einstellungen, und der Code wurde verallgemeinert, um jede Kombination zu unterstützen. Die Liste „Pixelformat“ bezieht sich jetzt nur noch auf das Layout für verschiedene Komponenten.

Rohdaten-Importdialog mit mehr Einstellungen und viel mehr unterstützten Formaten in GIMP 2.99.12

Infolgedessen unterstützt GIMP jetzt viel mehr Rohdatenformate, während ein nutzbarer Dialog erhalten bleibt, ohne eine nicht enden wollende Liste von Formaten anzuzeigen.

Die PDB-API für dieses Plug-in wurde ebenfalls verbessert, um demselben Schema getrennter Argumente zu folgen.

Als letzte Änderung teilt sich das HGT-Format (seit der stabilen Version GIMP 2.10.0 unterstützt) dieselbe Codebasis, sodass wir den Rohdaten-Dialog immer angezeigt haben. Dennoch haben wir alle relevanten Informationen für eine ordnungsgemäß formatierte HGT-Datei, sodass wir diese jetzt direkt ohne Dialog laden (es sei denn, wir können den richtigen Abtastabstand nicht erkennen).

Neues Format: WBMP

GIMP unterstützt jetzt das Laden von WBMP-Bilddateien, bei denen es sich um monochrome Bilder handelt, die für das veraltete WAP-Protokoll optimiert wurden, das inzwischen weitgehend eingestellt ist.

Das Format selbst ist wahrscheinlich nicht wirklich nützlich für neue Bilder, aber es kann immer nützlich sein, vorhandene Bilder aus älteren Archiven laden zu können.

Beachten Sie, dass dies eine begrenzte Unterstützung ist, da nicht alle Funktionen von WBMP unterstützt werden, aber hoffentlich ausreichend für die meisten Anwendungsfälle.

Neues Format: ANI

GIMP unterstützt jetzt den Import und Export des ANI-Formats für animierte Mauszeiger.

Der Exportdialog ermöglicht es Ihnen, Hot-Spot-Koordinaten für jedes Bild in der Animation festzulegen.

Hot-Spot-Koordinaten von importierten ANI-Dateien werden als Parasit in der XCF-Datei gespeichert, um beim erneuten Export als Standard wiederverwendet zu werden.

Exportdialog des ANI-Formats in GIMP 2.99.12

Script-fu

Lloyd Konneker, unser neuer Script-fu-Maintainer, hat seine neue Verantwortung wirklich ernst genommen, da der Script-fu-Code seit Jahren keine solche Aktivität mehr gesehen hat.

Viele Fehler wurden behoben, mehr Dokumentation für Script-fu-Entwickler wurde geschrieben, aber auch große Änderungen haben stattgefunden.

Script-fu-Server jetzt ein eigenes Plug-in

Script-fu war früher ein sehr monolithisches Erweiterungs-Plug-in (d.h. ein Plug-in, das permanent im Hintergrund läuft), mit all seinen Funktionen in einer einzigen Binärdatei, was mehrere Nachteile hatte. Einer davon ist, dass der Script-fu-Server (script-fu-server), der die Kommunikation mit GIMP aus der Ferne ermöglicht, auch im selben Prozess ausgeführt würde.

Dies kann als Sicherheitsrisiko angesehen werden, weshalb es zu einem eigenen Plug-in gemacht wurde, das unabhängig und nur auf Anfrage ausgeführt werden kann.

Neuer separater Interpreter

GIMP installiert jetzt eine gimp-script-fu-interpreter-3.0-Binärdatei, die die Script-fu-Skripte ausführt. Dies hat enorme Vorteile:

• Script-fu-Skripte sind endlich richtige Plug-ins. Sie werden im Ordner plug-ins/ installiert (nicht mehr in scripts/) und funktionieren auf die gleiche Weise wie andere Bindungen. Beachten Sie, dass Script-fu keine GObject-Introspektionsbindung ist, im Gegensatz zu anderen Bindungen, und es hat seine eigene Art, das PDB-Protokoll oder libgimp*-Bibliotheken zu kapseln, aber abgesehen davon ist es jetzt konzeptionell viel näher gerückt.
• Es macht die Script-fu-Infrastruktur viel robuster, da ein einzelnes abstürzendes Skript nicht das gesamte Script-fu zum Absturz bringt. Jedes Script-fu-Plug-in läuft jetzt in einem eigenen dedizierten und unabhängigen Prozess.

Überdenken der API

Da viel an der Haupt-libgimp*-API passiert ist, konnte die Script-fu-spezifische API nicht mithalten. Wir versuchen nun, diese Lücke zu schließen und Script-fu viel näher an die Hauptschnittstelle heranzuführen.

Zu diesen Änderungen gehört die neue Funktion script-fu-register-filter, die zur Deklaration von PDB-Prozeduren der C-Klasse GimpImageProcedure verwendet wird. Sie wird auch die prozedurale Dialoggenerierung durch die Klasse GimpProcedureDialog wesentlich erleichtern.

Viele Diskussionen fanden auch zum Thema Argumentbehandlung für verschiedene Typen statt. Dies ist noch in Arbeit, da wir versuchen, einige Anwendungsfälle zu verbessern, zum Beispiel die Behandlung von Plug-in-spezifischen Optionslisten.

API

Die Anwendungsprogrammierschnittstelle für Plug-in-Entwickler erhielt in dieser Iteration verschiedene Verbesserungen und Änderungen.

Natürlich gibt es viele neue Funktionen, die neuen Funktionen in GIMP entsprechen, wie z.B. für das Simulations-Farbmanagement, anpassbare Schachbrettfarben und mehr. Siehe die Liste.

Eine neue gimp_image_metadata_save_filter() erscheint auch als Alternative zu gimp_image_metadata_save_finish(), wenn Sie Metadaten selbst speichern möchten und nur Filterverarbeitung benötigen. Sie gibt gefilterte Metadaten zurück, die dem Aufrufer ermöglichen, die finalisierten Metadaten auf andere Weise zu speichern (z.B. über die Bibliothek des nativen Formats). Diese API kann verwendet werden, um das Speichern von Metadaten von Bildformaten zu unterstützen, die nicht direkt von gexiv2/exiv2 unterstützt werden. Wir verwenden sie bereits für das HEIF/AVIF-Plug-in.

Wir haben uns auch endlich von verschiedenen Funktionen getrennt, die davon ausgingen, dass ein Bild nur eine einzige aktive Ebene oder einen Kanal hatte. Wir wissen, dass dies in GIMP 3.0 nicht mehr der Fall ist, mit der Mehrfachauswahl von Elementen.

Unter den vielen anderen Änderungen ist eine der wichtigsten Änderungen in dieser aktualisierten API die Art und Weise, wie wir die Lokalisierung von Plug-ins behandeln. Während die Übersetzung der meisten Zeichenketten dem Ermessen des Plug-ins überlassen wurde, wurden die Zeichenketten zum Registrierungszeitpunkt (Plug-in-Titel, Dokumentation…) vom Kern übersetzt, z.B. wenn sie in Menüs oder im PDB-Browser verwendet wurden, unter Verwendung des zum Registrierungszeitpunkt angegebenen gettext-Katalogs. Dies warf verschiedene Probleme auf, z.B. was passiert, wenn mehrere Plug-ins einen Katalog mit demselben Namen registrieren würden (was mit noch komplizierterer interner Logik hätte behoben werden können)? Oder was passiert, wenn ein Plug-in keinen Lokalisierungskatalog registriert, aber der Standardkatalog (falsche) Übersetzungen für übermittelte Zeichenketten enthält? Außerdem war es am Ende ziemlich verwirrend, da viele Plug-in-Entwickler sich fragten, was wo übersetzt wird, d.h. ob eine Zeichenkette von _() (allgemeines gettext-Makro) oder N_() (noop gettext-Makro) umgeben sein sollte.

Die neue Logik ist viel einfacher: Die Übersetzung liegt nun vollständig im Ermessen des Plug-ins, d.h. alle vom Kern empfangenen Zeichenketten werden als in der korrekten Zielsprache angenommen. Der Kern versucht nicht mehr, irgendetwas von Plug-ins kommendes zu übersetzen.

Um ein wenig bei der Lokalisierung zu helfen, schlägt unsere Infrastruktur eine Standard-Dateiorganisation vor, mit allen gettext-Katalogen im Ordner locale/ des Plug-in-Verzeichnisses und benannt wie das Plug-in selbst. Wenn der Katalog fehlt, gibt unser System eine Meldung auf stderr aus, um über dieses Standardverfahren zu informieren. Ein Plug-in, das diesem Verfahren folgt, muss nichts weiter tun, als die kompilierten gettext-Kataloge (*.mo-Dateien) mit dem richtigen Domainnamen im richtigen Ordner abzulegen.

Ein GimpPlugIn kann dieses Verhalten jederzeit durch Überschreiben der set_i18n()-Methode außer Kraft setzen, um entweder die Lokalisierung ganz zu deaktivieren, auf einen anderen Katalogpfad und -namen zu verweisen oder sogar ein anderes System als gettext zu verwenden.

Das einzige Überbleibsel der alten Logik, über das wir nachdenken und es verbessern müssen, ist die Lokalisierung von Menüpfaden, da wir immer noch eine Kernlokalisierung einiger Basis-Menüpfade wünschen. Z.B. sollten die Stammmenüs („Bearbeiten“, „Bild“, „Farben“, „Filter“…) aber auch einige Untermenüs („Weichzeichnen“, „Verbessern“, „Verzerren“…) weiterhin vom Kern lokalisiert werden, während Plug-ins neue Teile im Menüpfad verwalten müssen. Dies ist die einzige Ausnahme von der neuen „keine Kernübersetzung“-Logik für Plug-ins.

Stapelverarbeitung

Eine neue libgimp-Klasse GimpBatchProcedure wurde hinzugefügt, die die Erstellung von Batch-Interpreter-Plug-ins erleichtert, d.h. Plug-ins, die von der Kommandozeile aus ausgeführt werden sollen, um eine Reihe von Prozeduraufrufen zu verarbeiten. Derzeit existieren in GIMP 2 solcher Interpreter: der Script-fu (plug-in-script-fu-eval) und der Python (python-fu-eval) Interpreter.

Das Ausführen von Code auf diese Weise erfolgt mit der --batch-CLI-Option. Historisch wurde Script-fu als Standard verwendet, aber das ist nicht mehr der Fall. Jetzt müssen Sie einen Interpreter explizit mit --batch-interpreter angeben.

Darüber hinaus wurde eine neue Option --quit erstellt, und diese müssen Sie verwenden, wenn Sie GIMP unmittelbar nach dem Ausführen der Skripte beenden möchten. Rufen Sie "(gimp-quit 1)" nicht mehr auf. Eine schöne Verbesserung ist, dass GIMP jetzt unmittelbar nach einem Batch-Fehler beendet wird (d.h., wenn Sie eine Reihe von --batch-Aufrufen hatten, wird es beim ersten Fehler anhalten) und den Fehler in den Prozess-Exit-Code weitergibt. Die Exit-Codes sind von Linux-Fehlercodes inspiriert: 0 für Erfolg, 69 für Dienst nicht verfügbar (z.B. Setzen eines nicht existierenden Interpreternamens), 64 für Nutzung (z.B. keine Angabe eines Interpreters oder Aufruffehler), 70 für Ausführungsfehler (Bugs im Interpreter-Plug-in) und 130 für Abbruch des Aufrufs. Daher werden Sie jetzt wissen, wann Ihre Skripte fehlschlagen.

Als Beispiel für die Stapelverarbeitung, hier wie Sie ein PNG-Bild laden und es dann wieder als JPEG exportieren könnten:

$gimp-2.99 --batch-interpreter python-fu-eval -idf -b "img=Gimp.list_images()[0];layers=img.list_layers();c=Gimp.get_pdb().lookup_procedure('file-jpeg-save').create_config();c.set_property('image',img);c.set_property('file',Gio.file_new_for_path('/home/jehan/out.jpg'));c.set_property('drawables',Gimp.ObjectArray.new(Gimp.Drawable, layers, False));c.set_property('num-drawables',len(layers));Gimp.get_pdb().run_procedure_config('file-jpeg-save',c)" --quit /home/jehan/in.png

Diese lange Kommandozeile mag beängstigend wirken, aber es ist dasselbe Skript in einer Datei, benannt zum Beispiel gimp-script.py:

img = Gimp.list_images()[0]
layers = img.list_layers()
c = Gimp.get_pdb().lookup_procedure('file-jpeg-save').create_config()
c.set_property('image', img)
c.set_property('file', Gio.file_new_for_path('/home/jehan/out.jpg'))
c.set_property('drawables', Gimp.ObjectArray.new(Gimp.Drawable, layers, False))
c.set_property('num-drawables', len(layers))
Gimp.get_pdb().run_procedure_config('file-jpeg-save', c)

Führen Sie es im Batch-Modus über GIMP wie folgt aus:

gimp-2.99 --batch-interpreter python-fu-eval -idf -b - < gimp-script.py --quit /home/jehan/in.png

Natürlich können Sie in Ihren Skripten beliebige Filter oder Bildmanipulationen über die GEGL- oder libgimp-API hinzufügen.

Build und Dokumentation

Meson (Nachricht an Paketierer)

Das GIMP-Build-System verwendet traditionell GNU autotools. Ein anfänglicher, aber unvollständiger Port auf das neuere Meson-System wurde 2017 von Félix Piédallu beigesteuert.

Es dauerte einige Jahre, um die letzten Anpassungen abzuschließen und Meson-Skripte so zu optimieren, dass sie alle speziellen Fälle in unserem GIMP-Code verarbeiten konnten. Als wir in diesem Entwicklungszyklus die Fertigstellung näherten, begannen wir, Meson offiziell für Windows, dann macOS, und schließlich Anfang August für alle Plattformen zu empfehlen.

Dies ist noch eine Evaluierungsphase für dieses Build-System, obwohl wir jetzt zu intensiven Tests übergehen. Wenn Sie ein Paketierer sind, versuchen Sie bitte, jetzt unseren Meson-Build zu verwenden und uns alle Probleme zu melden.

Ausnahmsweise haben wir für diese Version 2 Tarballs auf unserem Download-Server veröffentlicht: gimp-2.99.12.tar.xz und gimp-2.99.12-autotools.tar.bz2. Wie Sie sich denken können, ist der erstere der Meson-generierte Tarball, doch wir haben einen Autotools-generierten Tarball als Fallback belassen, falls der Meson-Tarball größere Probleme aufweisen sollte.

Die INSTALL-Datei wurde ebenfalls mit Meson-Anweisungen neu geschrieben.

Natürlich werden alle unsere eigenen Pakete (Flatpak für Linux, Installer für Windows und DMG für macOS) jetzt mit Meson erstellt.

Gettext

Wie viele andere Projekte verwendete GIMP das intltool-Projekt, um lokalisierbare Zeichenketten zu extrahieren und verschiedene Dateien mit gettext zu übersetzen, nicht nur Code.

Seit etwa 2016 hat das upstream gettext die Fähigkeit erlangt, Zeichenketten für mehr Dateitypen und -formate zu extrahieren, Projekte wurden ermutigt, umzusteigen, und das intltool-Projekt wurde schrittweise aufgegeben. Aber GIMP verwendete es immer noch für verschiedene Dateitypen (XML, Desktop-Dateien, Inno Setup-Übersetzungsdateien und mehr…), sodass das Arbeitsfeld nicht klein war.

Nun nicht mehr, da Niels De Graef sich endlich um diesen Port gekümmert und diese technische Schuld beseitigt hat! 🥳

Natürlich führte dies zu verschiedenen Problemen, sogar bis zum Veröffentlichungstag, als wir beim Testen der Installer feststellten, dass einige Schaltflächen defekt waren (was einer der wenigen Gründe ist, warum diese Nachricht Tage nach der eigentlichen Quellcode-Veröffentlichung herauskam) und wir die Zeichenketten korrigieren mussten. Hoffentlich war dies das letzte diesbezügliche Problem!

Plattformunterstützung

Wayland

Wayland-Probleme werden langsam aber sicher beseitigt. Einige der Probleme, die wir hatten, verschwanden einfach mit neueren Versionen einiger Wayland-Compositoren. Wir hoffen, dass weitere Bugs in Upstream-Compositoren irgendwann behoben werden, da uns einige ernsthafte Probleme immer noch Rätsel aufgeben (wie Abstürze einiger GTK-Anwendungen, einschließlich GIMP, auf dem Sway-Wayland-Compositor).

Einige andere Probleme wurden in unserem Code behoben.

Eines davon ist, dass frühe Tester möglicherweise ein sehr nerviges Popup bemerkt haben, das Sie darauf hinweist, dass „gimp-2.99 Verknüpfungen unterdrücken möchte“ (zumindest auf Mutter, dem Wayland-Compositor von GNOME) in früheren 2.99-Versionen. Dies wurde behoben, indem verschiedene Tastatur-Grabbing-Codes entfernt wurden, die mit GTK+3.0 nicht mehr notwendig waren.

Einige Probleme bleiben bestehen, basierend auf dem frühen Zustand von Wayland im Allgemeinen, insbesondere weil es kein Farbmanagement hat. Uns wurde oft geraten, die „Portale“ für verschiedene Funktionen zu verwenden, wie z.B. die Farbauswahl, die uns leider keine farbverwalteten Farben zurückgeben (als Nebenproblem fehlen einigen Desktops – wie Cinnamon und Mate – einfach die Implementierung für das Farbauswahlportal, obwohl das Portal existiert, was GIMP verwirrt). Dies ist ein Regressionsproblem, da wir falsche Farben erhielten (leicht falsch oder sogar sehr falsch, wenn Sie ein Wide-Gamut-Display verwenden), selbst wenn man noch unter X11 lief. Daher werden wir jetzt die X11-Implementierung für die Farbauswahl bevorzugen, wenn Sie unter X11 laufen, und die Portale nur unter Wayland verwenden. Wir könnten zu Portalen für alle unter Linux zurückkehren, wenn sie verwaltete Farben zurückgeben.

In der Zwischenzeit befinden wir uns in Diskussionen mit den Entwicklern des Freedesktop-Portals, um eine neue Farbauswahl-API für Portale zu erhalten, die schließlich für die verschiedenen Desktops implementiert werden muss. Hoffen wir, dass dies eher früher als später geschieht! 😅

macOS

Wie üblich wurde viel Wartungsarbeit von Lukas Oberhuber geleistet. Die Verpackungsarbeit ist nicht so sichtbar und daher oft undankbar, was behoben werden sollte: Danke Lukas sowie allen anderen Paketierern!

Abgesehen davon erinnern Sie sich vielleicht an die Langsamkeitsprobleme, die bei neueren macOS-Versionen auftraten (seit Big Sur). Wir hatten bereits einige benutzerdefinierte Patches für GTK und einige schmutzige Tricks im GIMP-Code selbst seit GIMP 2.99.10.

All dies führte zu verschiedenen Verbesserungen im GTK-Code, die die früheren Patches übernahmen. Es dauerte Monate des Testens, mehrere Codevorschläge in verschiedene Richtungen (mindestens 3 verschiedene Merge-Requests, möglicherweise wurde mehr Code verworfen) und es führte zu einem sehr zufriedenstellenden Ergebnis, da Lukas bestätigte, dass es jetzt viel schneller ist und GIMP völlig nutzbar ist. Unsere GIMP-internen „schmutzigen Tricks“ konnten ebenfalls entfernt werden. Für all diese Verbesserungen möchten wir insbesondere John Ralls danken, der die endgültigen Korrekturen lieferte, und Christian Hergert für seine ständigen Beiträge. Natürlich sollten wir die zahlreichen anderen Mitwirkenden nicht vergessen, die vorbeikamen, um zu helfen und nützliche Beiträge zu liefern. Hoffentlich wird GTK unter macOS weiterhin noch besser werden!

Auf jeden Fall ist dies eine großartige Nachricht für alle anderen Multiplattform-GTK-Software, obwohl noch keine GTK+3-Veröffentlichung diese Korrekturen enthält. Sie werden in GTK+ 3.24.35 verfügbar sein.

Wir fügen auch einen Patch für Cairo hinzu (wieder von John Ralls) für verbesserte Leistung unter macOS, obwohl die gewonnene Leistung nicht so offensichtlich war wie der GTK-Fix.

Zusätzlich zu den Entwicklungsversionen bieten wir jetzt auch nächtliche Builds für macOS an. Beachten Sie den Abschnitt „Automatische Entwicklungs-Builds“ auf der Entwickler-Download-Seite für eine Anleitung. ⚠️ Wie üblich erinnern wir daran, dass nächtliche Builds bedeuten, dass sie noch experimenteller sind als Entwicklungs-Builds: Diese Pakete entstehen zu zufälligen Zeitpunkten im Entwicklungsprozess, und die Builds werden nicht einmal von Menschen getestet. ☢

Jedenfalls ist viel passiert, seit den Tagen, vor nicht allzu langer Zeit, als wir verzweifelt waren über den traurigen Zustand von GIMP unter macOS, mit Langsamkeit (bis zur Unbrauchbarkeit) und Oberflächenproblemen. Jetzt erreichen wir endlich einen Punkt, an dem wir hoffen können, dass GIMP 3.0 unter macOS großartig sein wird, obwohl wir immer noch sehr wenige Mitwirkende für dieses Betriebssystem haben. Wir begrüßen jeden Entwickler, der sich uns anschließen möchte!

Letzter Punkt für Leute, die auf M1-Builds warten: Es wurde in dieser Richtung gearbeitet, aber wir werden hauptsächlich durch CI-Hardwarebeschränkungen blockiert. Wir werden Sie natürlich über Verbesserungen zu diesem Thema auf dem Laufenden halten.

Für Personen, die einen M1 Mac besitzen und bereit sind, lokal zu bauen, gibt es Build-Skripte im gimp-macos-build-Repository, obwohl das Starten vom README ideal sein könnte. Beachten Sie, dass Lukas bereits seine gesamte Arbeit auf M1-Maschinen erledigt, sodass wir nur noch auf CI-Unterstützung warten, um entsprechende Pakete bereitzustellen.

babl und GEGL

Wie üblich wird diese Veröffentlichung durch die Veröffentlichungen von babl 0.1.94/0.1.96 und GEGL 0.4.38 ergänzt.

babl 0.1.94/0.1.96

babl 0.1.94 behebt einen Absturz bei nicht ausgerichteten Daten für SIMD und verbessert die Vala-Kompatibilität von Introspektionsinformationen.

Es bringt auch ein neues Kommandozeilenprogramm zum Konvertieren einzigartiger Farben von einem Format und/oder Farbraum in einen anderen. Dies ist für uns sehr nützlich, um unsere Farbkonvertierungen zu testen und zu überprüfen, ob der GIMP-Code auch die richtigen Konvertierungen vornimmt, weshalb wir dieses Tool im Rahmen des Color-Invasion-Projekts geschrieben haben.

Zum Beispiel, um eine Farbe von sRGB in den CIELAB-Farbraum zu konvertieren:

$ babl -f "R'G'B' u8" -t 'CIE Lab float' 100 100 100
Converting from "R'G'B' u8" to "CIE Lab float": -42.374615 -0.000000 -0.000009

Die Verwendung ist:

$ babl --help
Usage: babl [options] [c1..]
  Convert color data from a specific Babl format and space to another.

Options:
  -h, --help                this help information
  -f, --from                input Babl format
  -t, --to                  output Babl format
  -i, --input-profile       input profile
  -o, --output-profile      output profile
  -r, --intent              rendering intent, it only works with an output profile
  -b, --brief               brief output, it can be re-entered as input for chain conversions

All parameters following -- are considered components values. This is useful to input negative components.
The tool expects exactly the number of components expected by your input format.
The default input and output formats are "R'G'B' float" and default space is sRGB for RGB formats, or the naive CMYK space for CMYK formats.

Natürlich soll dieses Tool noch weiterentwickelt werden.

Beachten Sie, dass babl 0.1.96 funktional dasselbe ist wie babl 0.1.94, außer einer Korrektur im Build-System, die das Bauen von babl aus einem Tarball verhinderte. Paketierer sollten daher die neueste Version verwenden.

GEGL 0.4.38

Eine neue Rauschunterdrückungsoperation namens „Denoise DCT“ ("denoise-dct") wurde von Thomas Manni eingeführt. Sie zerlegt den Eingabepuffer in gleitende überlappende Patches, berechnet die DCT-Rauschunterdrückung in jedem Patch und aggregiert dann die rauschunterdrückten Patches zum Ausgabepuffer, indem die überlappenden Pixel gemittelt werden.

Bei bestehenden Operationen wurden folgende verbessert:

• ff-load und ff-save: große API-Bereinigung, jetzt ffmpeg-5.0-kompatibel.
• gif-load: aktualisiert auf die neueste Upstream-Libnsgif-Version.
• slic: Fortschrittsanzeige und verbesserte Parameterbehandlung.
• vector-fill: aktualisiert auf die neueste Upstream-Ctx-Version.
• oilify: Eingaben klemmen, um nan im Ausgabe zu vermeiden.
• gegl:load: mögliches doppeltes Freigeben beheben.
• rgbe-write: Lecks in Fehlerpfaden beheben.

Neben Fehlerbehebungen sind weitere interessante Punkte, dass der Build vereinfacht wurde, indem GEGL als Unterprojekt verwendet wurde, und die kontinuierliche Integration überarbeitet wurde, um zuverlässiger zu sein.

Team-Nachrichten

Aryeom erhielt Reporterzugriff auf GIMP und gimp-web, um bei verschiedenen designbezogenen Problemen zu helfen.

Daniel Novomeský, Maintainer unserer JPEG-XL- und HEIF/AVIF-Plug-ins, wurde Zugriff auf unser Flathub-Repository (für unsere stabilen und Entwicklungs-Flatpaks) gewährt, um bei der Wartung zu helfen.

Wir möchten einer Kategorie von Mitwirkenden danken, die historisch gesehen nicht viel im Licht stehen: den Release-Testern. Insbesondere in letzter Zeit, da wir unsere kontinuierliche Integration und den Release-Prozess verbessern, versuchen wir auch, manuelle Überprüfungen vor der Veröffentlichung zu optimieren. Benutzer sind herzlich eingeladen, sich während des Release-Fiebers mit uns auszutauschen und auf unseren Diskussionskanälen zu verweilen, um die finalen Builds zu testen.

Für unseren Windows-Installer möchten wir zusätzlich zu den Paketierern (Jernej Simončič) und Entwicklern (Jacob Boerema) Sevenix danken, der seit einigen Releases immer in Bereitschaft war, unsere Installer zu testen. Sevenix hilft uns auch bei der Moderation unseres jüngsten Discord-Diskussionskanals.

Dies gilt auch für das Linux-Flatpak und das macOS-DMG, da in diesen Fällen nur ihre Paketierer (bzw. Jehan und Lukas Oberhuber) sie vor der Veröffentlichung getestet haben. Welches auch immer Ihre bevorzugte Plattform ist, bitte schließen Sie sich uns an!

Es ist eine gute Erinnerung daran, dass man kein Entwickler sein muss, um einen Beitrag zu leisten. Es gibt Aufgaben für Designer, Paketierer, Tester, Übersetzer, Dokumentatoren und mehr! 🤗

Websites

Dokumentations-Website

Wir schreiben hier regelmäßig darüber: Der neue Betreuer des gimp-help-Repositories (unsere Dokumentation), Jacob Boerema, hat es seit über einem Jahr verbessert, dringend benötigte Wartungsarbeiten durchgeführt, technische Schulden abgebaut und Bestehendes verbessert. Aber man konnte nicht viel davon sehen… bis heute!

Tatsächlich hat er erst vor kurzem die Online-Dokumentationswebsite aktualisiert. Wie Sie bereits auf der Startseite sehen können, werden endlich alle Sprachen angezeigt, und jede zeigt jetzt ihr Übersetzungsverhältnis an. Wir hoffen, dass dies mehr Menschen dazu anregen wird, bei der Übersetzung zu helfen und einen Beitrag zu leisten! 😸

Ein täglicher Aktualisierungsprozess wurde ebenfalls eingerichtet, damit wir nie wieder in die schlechte Situation veralteter Online-Dokumentation für Jahre geraten (obwohl einige Inhalte bereits im Repository korrigiert wurden).

Das PDF „Kurzreferenz“ ist jetzt auch in jeder unterstützten Sprache verfügbar (wiederum mit Angabe des Übersetzungsfortschritts in Prozent).

Natürlich verdienen viele Originalinhalte immer noch mehr Aufmerksamkeit, entweder sind sie veraltet, oder Informationen zu neuen Funktionen fehlen möglicherweise. Ein Mann allein kann einfach so viel tun. Doch jetzt ist die Infrastruktur vorhanden, um einen viel schnelleren Aktualisierungs- und Feedback-Prozess zu ermöglichen. Wenn also jemand zur Dokumentation beitragen möchte, sollte er sich das Repository ansehen und Merge-Requests vorschlagen. Das Beitragsformat ist DocBook.

Für Übersetzungsbeiträge sollten Sie sich an die GNOME-Übersetzungsteams wenden, da diese ihre eigene Plattform haben. Weitere Informationen finden Sie hier.

Eine spezielle Nachricht mit weiteren Details könnte bald veröffentlicht werden, möglicherweise wenn wir uns entscheiden, eine neue getaggte Veröffentlichung des Handbuchs vorzunehmen, was neue Installer für Windows und Tarballs für andere Plattformen und für Paketierer bedeuten wird, die aktuelle Inhalte für die Offline-Nutzung enthalten.

Entwickler-Website

In der Zwischenzeit befand sich unsere Entwickler-Website in einer noch schlimmeren Lage, da sie seit über 10 Jahren nicht aktualisiert worden war!

Dies wird sich ändern, da eines unserer Ziele für GIMP 3.0 darin besteht, das Plug-in-Ökosystem zu verbessern, nicht nur mit einer bevorstehenden Erweiterungsplattform, sondern auch mit einer besseren und aktuelleren Dokumentation.

Die Arbeit an der neuen Entwickler-Website beginnt endlich, dank des Anstoßes von Robin Swift, einem neuen Mitwirkenden, und der Hilfe von Pat David (dem langjährigen Mitwirkenden, der bereits durch die Neugestaltung unserer Website half und die PIXLS.US-Community für FLOSS-Fotografie-Tools gründete).

Wir haben die Website-Inhalte bereits von DocBook auf die Hugo-Plattform portiert. Dies sollte die Beiträge vereinfachen. Wir haben auch die meisten veralteten Inhalte bereinigt und begonnen, einige Inhalte zu portieren, die im Quell-Repository selbst und aus dem Wiki gespeichert waren.

Ach, das Wiki! Einige Leute könnten bemerkt haben, dass es jetzt weg ist. Wir hatten dort die Roadmap, Build-Anweisungen für Neulinge und weitere technische oder historische Dinge. Sagen wir, unglückliche Ereignisse sind eingetreten und wir haben es verloren. 😱

Glücklicherweise konnten alle Inhalte gerettet werden, und wir planen, die wertvollen Teile in die kommende Entwickler-Website zu portieren, schön organisiert. Schließlich erfüllten sowohl das Wiki als auch die Entwickler-Website einen ähnlichen Zweck (mit der Ausnahme, dass eines größtenteils aufgegeben wurde). Am Ende ist das also eine gute Sache, organisatorisch gesehen, oder? 😅).

Es ist noch sehr früh im Migrationsprozess, daher werden wir Sie bald mit weiteren spannenden Nachrichten auf dem Laufenden halten.

Mirror-Nachrichten

Ein neuer Mirror hat sich uns angeschlossen, um GIMP zu verteilen.

Vielen Dank an SandyRiver.NET in Pikeville, Kentucky USA, für die Unterstützung bei der Verteilung der Downloads!

Buch-Nachrichten

Drei deutsche und drei polnische Bücher über GIMP wurden der Bücherseite hinzugefügt:

Wir erinnern daran, dass wir Buchergänzungen begrüßen. Egal ob Sie es geschrieben oder nur gelesen haben, wenn Sie ein Buch über GIMP kennen, melden Sie einfach dieselben Informationen wie andere Bücher in der Liste. Danke!

Veröffentlichungsstatistik

61 Personen haben zum Haupt-Repository für GIMP 2.99.12 beigetragen:

• 23 Entwickler haben zur GIMP-Codebasis für diese Mikroversion beigetragen:
  • 1 Entwickler mit mehr als 300 Commits: Jehan.
  • 4 Entwickler mit 10 bis 50 Commits: Jacob Boerema, Nikc, Loyd Konneker, Niels De Graef.
  • 18 Entwickler mit weniger als 10 Commits: Povilas Kanapickas, Kevin Cozens, Lukas Oberhuber, woob, Simon Budig, Anders Jonsson, Axel Viala, Ben Rogalski, Claude Paroz, Daniel Novomeský, GokhanKabar, Jan Tojnar, L amander, azetoy, houda, Øyvind Kolås, ktoyle und Sonia Habtiche.
• 25 Übersetzungen wurden aktualisiert: Baskisch, Brasilianisches Portugiesisch, Bulgarisch, Katalanisch, Chinesisch (China), Dänisch, Niederländisch, Finnisch, Französisch, Galizisch, Georgisch, Deutsch, Griechisch, Ungarisch, Isländisch, Koreanisch, Persisch, Polnisch, Portugiesisch, Russisch, Slowenisch, Spanisch, Schwedisch, Türkisch, Ukrainisch.
• 35 Übersetzer haben beigetragen: Yuri Chornoivan, Hugo Carvalho, Martin, Rodrigo Lledó, Zurab Kargareteli, Luming Zh, Anders Jonsson, Fran Dieguez, Sveinn í Felli, Nathan Follens, Asier Sarasua Garmendia, Balázs Úr, Matej Urbančič, Alan Mortensen, Aleksandr Melman, Alexandre Prokoudine, Claude Paroz, Jordi Mas, Sabri Ünal, Balázs Meskó, MohammadSaleh Kamyab, Alexander Shopov, Jiri Grönroos, Piotr Drąg, dimspingos, Charles Monzat, Hannie Dumoleyn, Jürgen Benvenuti, Tim Sabsch, Alexandre Franke, Aryeom, Boyuan Yang, Danial Behzadi, Maíra Canal und Rafael Fontenelle.
• 4 Personen haben bei der In-Code-Dokumentation geholfen: Jehan, Lloyd Konneker, Niels De Graef und Akkana Peck.
• 1 Person hat zu den Icons beigetragen: Stanislav Grinkov.
• 3 Personen haben zu den Cursorn beigetragen: Aryeom, Jehan und L Amander.
• 3 Personen haben zu den Themes beigetragen: Jehan, Akkana Peck und Nikc.
• 12 Personen haben Build-bezogene Updates beigesteuert: Jehan, Lloyd Konneker, Akkana Peck, Anders Jonsson, Jan Tojnar, ktoyle, Øyvind Kolås, Lukas Oberhuber, Bartłomiej Piotrowski, Ondřej Míchal, Daniel Novomeský und Jacob Boerema.

Dies sind die Statistiken zu den babl, GEGL und ctx Repositories:

• 7 Mitwirkende an babl 0.1.94 und 0.1.96:
  • 3 Mitwirkende mit mehreren Commits: Axel Viala, Øyvind Kolås und Jehan.
  • 4 Mitwirkende mit einzelnen Commits: Eli Schwartz, Lukas Oberhuber, Sergey Torokhov und Xavier Claessens.
• 24 Mitwirkende an GEGL 0.4.38:
  • 7 Mitwirkende mit mehreren Commits: Øyvind Kolås, Behnam Momeni, Thomas Manni, Michael Drake, Xavier Claessens, Axel Viala und Anders Jonsson,
  • 3 Mitwirkende mit einzelnen Commits: Felix Schwarz, Jehan und darnuria.
  • 15 Übersetzer: Hugo Carvalho, Piotr Drąg, Rodrigo Lledó, Yuri Chornoivan, Anders Jonsson, Luming Zh, Martin, Zurab Kargareteli, dimspingos, Alan Mortensen, Jordi Mas, Marcia van den Hout, Marco Ciampa, Sabri Ünal und Tim Sabsch.
• ctx hat keine eigenen Releases, da es sich um projektinternen Code handelt. Zählen wir also die Commits im Zeitraum zwischen GIMP 2.99.10 und 2.99.12:
  • 1 Mitwirkender mit 396 Commits: Øyvind Kolås.

Im Dokumentations-Repository haben im selben Zeitraum wie GIMP 2.99.12 26 Personen beigetragen:

• 1 Mitwirkender mit mehr als hundert Commits an Dokumentation und Skripten: Jacob Boerema.
• 7 Mitwirkende an der Dokumentation selbst oder an Skripten, mit weniger als 30 Commits: Jehan, Anders Jonsson, Andre Klapper, Balázs Úr, Daniele Forsi, Jernej Simončič und Marco Ciampa.
• 21 Übersetzer: Rodrigo Lledó, Jordi Mas, Nathan Follens, Yuri Chornoivan, Marco Ciampa, Anders Jonsson, Tim Sabsch, Hugo Carvalho, Balázs Úr, dimspingos, Alan Mortensen, Aleksandr Melman, Charles Monzat, Claude Paroz, Danial Behzadi, Kjartan Maraas, Luming Zh, Martin, Matheus Barbosa, Milo Ivir und Ulf-D. Ehlert.

Im Haupt-Website-Repository:

• 1 Mitwirkender hat 76 Commits beigesteuert: Jehan.
• 5 Mitwirkende haben 1 bis 10 Commits beigesteuert: Alexandre Prokoudine, Anders Jonsson, Tom Gooding, Alberto Garcia Briz und Babs Keeley.

Im macOS Build Repository:

• 1 Mitwirkender hat 71 Commits beigesteuert: Lukas Oberhuber.
• 1 Mitwirkender hat 2 Commits beigesteuert: Jehan.

Im Entwickler-Website-Repository:

• 3 Mitwirkende: Jehan, Pat David und Robin Swift.

Hinweis: Angesichts der vielen Teile in und um GIMP und der Art und Weise, wie wir Statistiken durch git-Skripte und manuelle Anpassungen erhalten, können Fehler in diese Statistiken gelangen. Fühlen Sie sich frei, uns mitzuteilen, wenn wir einige Mitwirkende oder Beiträge übersehen oder falsch kategorisiert haben, denn wir versuchen, jeden Mitwirkenden für seinen Beitrag zu GIMP zu würdigen!

GIMP 2.99.12 herunterladen

Wie üblich ist GIMP 2.99.12 auf der offiziellen GIMP-Website (gimp.org) in 3 Paketformaten erhältlich:

• Linux-Entwicklungs-Flatpak
• Windows-Installer
• macOS DMG-Paket

Andere Pakete von Drittanbietern werden voraussichtlich folgen (Linux-, BSD-Distributionen, etc.). Das MSYS2-Projekt plant anscheinend auch, die Entwicklungsversion bald zu paketieren.

Was kommt als Nächstes

Diese Version ist wieder einmal ein wichtiger Meilenstein auf dem Weg zu GIMP 3.0. Alle 2.99-Entwicklungsversionen waren große Meilensteine, aber wir haben wirklich das Gefühl, dass wir uns den Release Candidates nähern, mit einigen großartigen Verbesserungen an dringend benötigten Stellen:

• wir erhalten endlich ordentliche neutral-graue Themes;
• unser Wayland-Build wird endlich etwas stabiler (obwohl Probleme bleiben);
• unser macOS-Build ist jetzt wirklich auf der nutzbaren Seite;
• unsere letzten verbleibenden GTK-Port-Probleme werden langsam, aber sehr sicher, behoben;
• das Space-Invasion-Projekt macht große Fortschritte dank des CMYK-Projekts (das uns zwingt, Farbraumprobleme insgesamt zu überprüfen);
• Script-fu und die API im Allgemeinen erhalten viel Aufmerksamkeit;
• mehrere unserer langjährigen Verbesserungsprojekte neigen sich dem Ende zu;
• und vieles mehr, da so viele Dinge in Arbeit sind!

Wir können Ihnen immer noch kein Datum für GIMP 3.0 nennen, aber wir nähern uns! 🤩 Für die zukünftige Entwicklung von GIMP, einschließlich der weiteren Schritte im Jahr GIMP 2023, können Sie sich auf spannende Neuerungen freuen.

Vergessen Sie nicht, dass Sie spenden und GIMP-Entwickler persönlich finanzieren können, um etwas zurückzugeben und die Entwicklung von GIMP zu beschleunigen. Die Maintainer von GEGL und GIMP sammeln Spenden, um Vollzeit an freier Software arbeiten zu können, was dank der Community geschehen könnte! 💪🥳