GIMP 2023: Bahnbrechende Entwicklung mit Version 2.99.16 auf dem Weg zu 3.0

Wir freuen uns, die neueste Entwicklungsversion vorstellen zu dürfen: GIMP 2.99.16! Damit rückt ein Release Candidate für GIMP 3.0 näher denn je. Dieser Artikel beleuchtet einige der bemerkenswertesten und interessantesten Neuerungen dieses Updates. Wir sind begeistert, diese Fortschritte präsentieren zu können, die Gimp 2023 zu einem aufregenden Jahr für die Bildbearbeitung machen.

Die Entwicklung von GIMP 2.99.16 wurde intern als „Wilber Week 2023 Edition“ bezeichnet, eine Hommage an unser sehr erfolgreiches Entwicklertreffen. Die in diesem Artikel aufgeführten Änderungen konzentrieren sich auf die sichtbarsten und wichtigsten Neuerungen. Kleinere Verbesserungen oder reine Fehlerbehebungen sind hier nicht vollständig aufgelistet. Eine umfassendere Übersicht finden Sie in der NEWS-Datei oder im Commit-Verlauf.

Neuer Entwicklungs-Splashscreen für GIMP 2.99.16

GTK+3-Portierung offiziell abgeschlossen

GIMP 3.0 ist seit Langem als die Version bekannt, die auf GTK+3 portiert wurde. Es ist erfreulich zu verkünden, dass diese Portierung nun endlich abgeschlossen ist. Zwar gibt es noch vereinzelt kleinere Deprecation-Warnungen, doch sind diese nicht mehr vergleichbar mit den hunderten, die wir einst hatten.

GimpAction-Infrastruktur

Eine unserer letzten großen Aufgaben war die Portierung der „Aktions“-Behandlung. Im GTK-Vokabular bedeutet dies Tastenkürzel und deren Mechanismus, aber auch die Menüführung und die schnelle Zuweisung von gemeinsamem Aktionscode zu generischen Widgets. Ab GTK+3 wanderten Aktionen zu GLib (GtkAction wurde zu GAction), verloren dabei aber viele benutzerorientierte Funktionen (wie Labels, Beschreibungen, Icons) oder wurden aufgespalten (das Konzept des Tastenkürzels selbst blieb in GTK).

Daher mussten wir das Ganze als Wrapper um GAction neu implementieren, genannt GimpAction. Für uns sind diese benutzerorientierten Funktionen wesentliche Bestandteile einer Aktion. Insbesondere, da wir viel GUI- und Code-Generierung betreiben, müssen Labels oder Icons nicht an ein Widget (sei es ein Button, ein Menüpunkt oder etwas anderes) gebunden sein, sondern an die dem Widget zugewiesene Aktion, um eine einfache und generische Wiederverwendung zu ermöglichen.

Wir mussten auch eine Reihe weiterer Widgets wrappen, wie unsere eigenen Menüs (hauptsächlich, weil von Menümodellen generierte Menüs in GTK+3 keine Tooltips mehr haben, wir aber Tooltips intensiv nutzen) und Menümodelle (GimpMenu und GimpMenuModel), unsere eigene Toolbar und Menüleiste (GimpToolbar und GimpMenuBar) und mehr.

Diese Arbeit nahm etwa zwei Monate in Anspruch, parallel zu anderen Code-, Wartungs- und üblichen Fehlerbehebungsaufgaben. Es war langwierig und anstrengend, aber es ist nun geschafft!

Dies eröffnet uns auch eine völlig neue Welt von Möglichkeiten. Wir haben neue Konzepte hinzugefügt, die wir uns lange gewünscht hatten, wie die Fähigkeit, einem Aktionsobjekt ein kurzes und ein langes Label zuzuordnen (z. B. wenn es in einer kontextuellen Schnittstelle wie einem Menü verwendet wird, im Gegensatz zur Verwendung ohne Kontext, wie bei der Aktionensuche). Es ist auch der Weg für geplante zukünftige Verbesserungen (z. B. für eine zukünftige anpassbare Symbolleiste).

Es liegt noch etwas Arbeit vor uns, um unseren neuen Menü- und Aktionscode genau so zu gestalten, wie wir ihn uns wünschen, aber wir sind in einem guten genug Zustand, um ihn zu präsentieren. Für die meisten von Ihnen wird es sich nicht wesentlich anders anfühlen (und Sie könnten auch Probleme finden), aber das Ziel war auch, dass es sich nicht zu anders anfühlt.

Doch es gibt auch unmittelbarere Verbesserungen, die es wert sind, erwähnt zu werden. Um die beste Software für Ihre Bedürfnisse zu wählen, sollten Sie verschiedene Optionen vergleichen, so wie Sie auch überlegen würden, microsoft edge oder firefox für Ihr tägliches Surfen zu nutzen.

Mehrere Tastenkürzel pro Aktion

Die neuen Glib/GTK+3-Aktionen ermöglichen es, einer einzelnen Aktion mehrere Tastenkürzel zuzuweisen. Obwohl der Tastenkürzel-Dialog dies derzeit noch nicht zulässt, nutzen wir diese Fähigkeit intern bereits für Standard-Tastenkürzel. So sind beispielsweise die Tasten des Ziffernblocks nicht identisch mit denen der Ziffernreihe. Früher mussten wir eine doppelte Aktion erstellen, die dasselbe tut, um beide zu unterstützen (da für die meisten Leute Strg-1 sowohl vom Ziffernblock als auch von der oberen Reihe gleich funktionieren sollte). Jetzt können wir einfach beide Varianten derselben Aktion zuweisen.

Ein weiteres Beispiel ist die Möglichkeit, spezielle semantische Medientasten (wie die Medientasten Kopieren, Ausschneiden und Einfügen, die auf einigen Tastaturen zu finden sind) zu unterstützen. Ein aktualisierter Tastenkürzel-Dialog, der es Ihnen ermöglicht, Ihre eigenen multiplen Tastenkürzel festzulegen, wird möglicherweise nicht für GIMP 3.0 erscheinen, aber hoffentlich nicht allzu lange danach.

Verbesserungen der Aktionensuche

Da wir nun einen eigenen Aktions-Wrapper haben, haben wir ihn so konzipiert, dass er auch seine eigene Menüposition verfolgt. Dadurch können wir diesen Menüpfad im Aktionensuche-Dialog anzeigen. Dies wird Personen helfen, die Menüs bevorzugen, sich besser zurechtzufinden.

Aktionensuche-Dialog in GIMP 2.99.16 zeigt Menüpfade für verbesserte Navigation an.

Möglicherweise bemerken Sie in diesem Screenshot auch ein kleines „Manual“ 📓-Symbol. Wenn Sie darauf klicken, wird die Handbuchseite für die jeweilige Aktion geöffnet (falls für diese spezifische Aktion noch kein Hilfeabschnitt existiert, werden Sie zur Hilfeseite der Aktionensuche weitergeleitet). Alternativ öffnet das Drücken der F1-Taste die Hilfeseite der ausgewählten Aktion.

Verbesserte GUI-Integration von GEGL-Operationen

GEGL ist unsere Bildverarbeitungs-Engine. Filter werden als separate Module implementiert, die wir „Operationen“ nennen. Obwohl GEGL mit einer langen Liste von Standardoperationen veröffentlicht wird, können Drittentwickler ihre eigenen Filter implementieren und profitieren dabei von der automatischen Dialoggenerierung, der Live-Vorschau auf der Arbeitsfläche, der Vorhangvorschau, der Speicherung von Voreinstellungen, der Historie der zuvor verwendeten Einstellungen und vielem mehr.

GEGL ist seit GIMP 2.10 eine Hauptkomponente, dennoch benötigten wir bisher spezifischen Code, um GEGL-Operationen in Menüs zu platzieren. Für Drittanbieter-Filterentwickler bedeutete dies, entweder ein Dummy-Plug-in zu implementieren, um ihre GEGL-Operation zu wrappen, oder sich damit zufriedenzugeben, nur in der langen Liste der Filter im GEGL-Operationstool sichtbar zu sein.

Dies hat sich geändert, da GEGL-Filter nun direkt und einfach über Menüs zugänglich sind, genau wie Plug-ins.

Von nun an liest GIMP den GEGL-Schlüssel "gimp:menu-path", um eine Operation in Menüs hinzuzufügen. Nehmen wir zum Beispiel an, ich habe einen künstlerischen Filter geschrieben, um ein Bild zu stilisieren, und ich möchte ihn unter dem Untermenü Filter > Künstlerisch platzieren. Mein Operationscode könnte dann den folgenden Code enthalten:

<span>gegl_operation_class_set_keys</span><span>(</span><span>operation_class</span><span>,</span> <span>"name"</span><span>,</span><span>"Jehan:my-style"</span><span>,</span> <span>"title"</span><span>,</span><span>_</span><span>(</span><span>"My Super Cool Style"</span><span>),</span> <span>"description"</span><span>,</span><span>_</span><span>(</span><span>"Stylize an image the way I like it"</span><span>),</span> <span>"gimp:menu-path"</span><span>,</span><span>"<image>/Filters/Artistic"</image></span><span>,</span> <span>NULL</span><span>);</span> 

Und hier ist es:

Benutzerdefinierter Filter mit "gimp:menu-path" in GIMP 2.99.16 wird in der Menüstruktur angezeigt.

GIMP generiert die GUI automatisch gemäß den in Ihrer Operation deklarierten Eigenschaften.

Natürlich können Sie auch eigene Menüordner erstellen. Wenn ich zum Beispiel eine Reihe von Filtern erstelle, die wir speziell für unser Filmprojekt verwenden, könnte ich ein Untermenü "<image>/Filters/ZeMarmot"</image> erstellen (oder sogar ein Top-Level-Menü. Sie werden das „Girin“-Menü in meinem Screenshot bemerken, wo wir unsere benutzerdefinierten Plug-ins bereits installieren).

Wir werden dies auch nutzen, um den GIMP-Kerncode zu vereinfachen, auch wenn derzeit nur zwei neue GEGL-Filter diese Funktion nutzen.

ℹ️ Hinweis zu GEGL-Operations-Namespaces: Möglicherweise bemerken Sie, dass ich meinen hypothetischen Filternamen mit „Jehan:“ präfigiert habe. Dies ist eine Möglichkeit, Ihre Filter mit einem eindeutigen Namen zu „namespaces“ und Konflikte zu vermeiden, falls jemand einen Filter mit demselben Namen implementieren sollte. Wählen Sie diesen Namespace sorgfältig, und verwenden Sie insbesondere nicht die Namespaces „gegl:“ oder „svg:“, die für GEGL-Kernoperationen reserviert sind (und eines Tages sogar für Drittanbieter-Operationen verboten werden könnten).

Die zweite große Verbesserung ist, dass Ihre benutzerdefinierten Filter jetzt in der Aktionensuche (standardmäßig /-Taste) erscheinen, unabhängig davon, ob Sie sie einem Menü hinzugefügt haben oder nicht. Dies ermöglicht ein sehr einfaches Suchen und Ausführen!

Screenshot der GIMP 2.99.16 Aktionensuche, die nun auch Drittanbieter-GEGL-Filter auflistet.

Werkzeuge

Textwerkzeug

Obwohl der On-Canvas-Editor des Textwerkzeugs sehr praktisch ist, war er manchmal störend, da er im Weg war. Es gibt Fälle, in denen man das reine Arbeitsfenster sehen möchte, während man Text bearbeitet. Dies ist nun dank der neuen Option „On-Canvas-Editor anzeigen“ möglich, um dessen Sichtbarkeit umzuschalten.

GIF, das das Ausblenden des On-Canvas-Texteditors im GIMP 2.99.16 Textwerkzeug zeigt.

Ausrichten- und Verteilen-Werkzeug

Das Werkzeug wurde bereits in GIMP 2.99.14 vollständig überarbeitet. In dieser Version haben wir die Option „Inhaltsgrenzen der Ebene verwenden“ so modifiziert, dass sie auch auf die Ausrichtungsreferenz angewendet wird (nicht nur auf die Zielobjekte).

Vereinheitlichtes Transformationswerkzeug

Es wurde ein Patch eingereicht, um die Transformationsmatrix im On-Canvas-Dialog des Werkzeugs auswählbar zu machen. Dies erleichtert die Wiederverwendung der Matrix in anderer Software (während man die Transformation zuerst in GIMP für eine sofortige Vorschau testet und dann die Matrix kopiert und einfügt).

Space Invasion (Farbmanagement)

„Space Invasion“ ist unser Projekt, um die Farbkorrektheit überall dort zu gewährleisten, wo wir Farben anzeigen oder verwenden, geeignete Farbstandards zu wählen und relevante Farboptionen anzubieten. In dieser Version wurden einige Arbeiten am internen Code vorgenommen, der immer noch sRGB-Input oder -Output annahm und in einigen Situationen verwendet wurde. Es ist nun einfacher möglich, Vordergrund- und Hintergrundfarben außerhalb des sRGB-Bereichs zu wählen, und das Farbwahlwerkzeug zeigt Farbwerte aus dem richtigen Bildfarbraum an.

Im Farbwahlwerkzeug (und im andockbaren Fenster „Abtastpunkte“) wurde ein neuer Anzeigemodus „Graustufen (%)“ hinzugefügt. Dieser zeigt den Graustufenwert des Pixels an, wenn das ausgewählte Bild in den Graustufenmodus konvertiert würde.

Es gibt noch viel mehr in Arbeit bezüglich dieser Schnittstellen, wie z. B. die Gewährleistung, dass die Farben in den verschiedenen Farbfeldern korrekt angezeigt werden (nicht nur auf der Arbeitsfläche), dass wir ein vernünftiges Verhalten bei gemeinsam genutzten Farb-Widgets erhalten, wenn wir von einem Bildfarbraum zu einem anderen wechseln, und so weiter. Auch planen wir, den aktuell verwendeten Farbraum auf all diesen gemeinsam genutzten Schnittstellen, wo man Farben wählen oder anzeigen kann (Farben-Andockfenster, Vorder-/Hintergrundfarben, Farbwahlwerkzeug, Abtastpunkte-Andockfenster…), expliziter zu machen. Dies wird einer der größten Teile der nächsten Entwicklungsversion sein.

Grafische Benutzeroberfläche

Neue Option „Menüleiste und Titelleiste zusammenführen“

Im Einstellungen-Dialog, unter Bildfenster, finden Sie ein neues Kontrollkästchen mit der Bezeichnung „Menüleiste und Titelleiste zusammenführen“. Dies ist im Grunde eine Option, um für die Bildfenster auf Client Side Decoration (CSD) umzuschalten, was hauptsächlich bedeutet, dass das Menü in die Titelleiste integriert wird, wodurch vertikaler Platz gespart wird.

Hinweis: Diese Option funktioniert nicht für macOS, das immer seinen eigenen plattformspezifischen Menüstil hat.

Da die Kopfzeile beim Maximieren ausgeblendet wird, wird das Menü, wenn Sie unter Einstellungen > Bildfenster > Erscheinungsbild die Option „Menüleiste anzeigen“ für die „Standarddarstellung im Vollbildmodus“ aktiviert haben, vorübergehend aus der Titelleiste verschoben. Dadurch bleibt das Menü auch im Vollbildmodus sichtbar (wenn die entsprechende Option aktiviert ist, was die Standardeinstellung ist).

Wir wissen, dass Client-Side Decoration eine recht umstrittene Funktion ist. Es gibt Leute, die sie aus tiefstem Herzen lieben, ebenso wie das Gegenteil (insbesondere weil man die Konsistenz des Fensterstils verliert, da Dekorationen nicht mehr vom Fenstermanager gehandhabt werden). Außerdem wird uns berichtet, dass in einigen spezifischen Fällen das System sich weigert, seine eigene Fensterdekoration fallen zu lassen, und man möglicherweise am Ende zwei Titelleisten hat (eine vom System gezeichnete und eine von GIMP). Aus diesen Gründen ist diese Option standardmäßig deaktiviert.

Designs

Die dunkle Variante des Standard-Designs wurde überarbeitet, weil sie etwas zu dunkel war. Die ältere Version wurde vorübergehend als neues Design mit dem Titel Darker verschoben, obwohl wir uns nicht sicher sind, ob wir sie behalten werden.

Während unseres letzten persönlichen Entwicklertreffens, bei dem diese Arbeit stattfand, wurde auch das Konzept eines „High Contrast“-Designs angesprochen. Zu einem bestimmten Zeitpunkt diskutierten wir sogar die Möglichkeit, Einstellungen für die Farbanpassung des Designs zu implementieren. Wir sind uns derzeit nicht sicher, was davon für GIMP 3.0 umgesetzt wird. Dies hängt wirklich davon ab, ob wir bis zur Veröffentlichung weitere Design-Beiträge erhalten.

Verbesserungen bei Auswahl/Pfad füllen und konturieren

Die Dialoge „Auswahlkonturieren/füllen“ oder „Pfadkonturieren/füllen“ boten früher an, entweder mit einer „Einfarbig“ (tatsächlich die Vordergrundfarbe) oder mit einem „Muster“ zu konturieren (bzw. zu füllen). Wir haben „Einfarbig“ in „Vordergrundfarbe“ und „Hintergrundfarbe“ aufgeteilt, damit Sie deren Positionen nicht ständig wechseln müssen.

Darüber hinaus wurden die Dialoge „Auswahl konturieren“ und „Pfad konturieren“ insbesondere in einem Stapelschalter neu organisiert, wodurch die beiden Optionen „Linie“ und „Malwerkzeug“ einfacher zu bedienen sind. Als Ergebnis der Platzeinsparung im Dialog blenden wir die Einstellungen für den „Linienstil“ nicht mehr unter einem Expander aus, um die Optionen für die Linienwiedergabe prominenter anzuzeigen.

Option „Mittelgrau (CIELAB)“ für Ebenenfüllung

Beim Erstellen eines neuen Bildes oder einer neuen Ebene gibt es das Feld „Füllen mit“, in dem Sie die Farbe der erstellten Ebene aus den Vordergrund-/Hintergrundfarben, Weiß, Schwarz, Transparenz oder einem Muster auswählen können. Wir haben „Mittelgrau (CIELAB)“ hinzugefügt, das 50% der wahrnehmbaren Helligkeit (das L* von CIELAB oder CIELCh) oder 18,42% Luminanz entspricht. Obwohl das Konzept von „Mittelgrau“ je nach gewählter Definition unterschiedliche Werte haben kann, ist dies eine der gebräuchlichsten, die als wahrnehmbar auf halbem Weg zwischen Dunkelheit und Licht für das durchschnittliche menschliche Auge betrachtet wird.

Dateiformate

Ein Großteil der Arbeit an Dateiformaten stammt von Alx Sa (in früheren Nachrichten als Nikc bekannt), der ein Talent dafür hat, die Unterstützung für verschiedene Formate hinzuzufügen und die bestehenden zu verbessern. Eine wirklich großartige Leistung, also Bravo Alx! 👍

FITS

FITS ist ein Bildformat, das am häufigsten in der Astronomie verwendet wird. Während wir früher unseren eigenen Code für die FITS-Unterstützung integriert hatten, haben wir diesen nun auf cfitsio portiert, eine von der NASA gepflegte Bibliothek. Dies ermöglicht es uns, komprimierte FITS-Dateien (GZIP, HCOMP, PLIO, RICE) in 8/16/32-Bit und mit einfacher/doppelter Genauigkeit zu importieren. Im Allgemeinen wird dies unser Unterstützungsniveau für dieses Format erheblich verbessern.

Da wir nun eine externe Bibliothek verwenden, wird die FITS-Unterstützung optional (besonders relevant für Linux-Distributionspakete; in unseren eigenen Paketen ist sie immer vorhanden). Zusätzlich möchten wir uns bei Siril (dem astronomischen Bildverarbeitungsprogramm) bedanken, dessen Entwickler mit uns zusammengearbeitet haben, um die Unterstützung in GIMP zu verbessern.

PSD (und ein bisschen TIFF und JPEG)

Beschneidungspfade können jetzt aus PSD-Dateien importiert und in diese exportiert werden! Wenn Ihr Bild einen Pfad enthält, schlägt ein PSD-Exportdialog vor, einen „Beschneidungspfad zuzuweisen“, und ein Dropdown-Menü ermöglicht Ihnen die Auswahl des zu verwendenden Pfades.

Dialog in GIMP 2.99.16 zum Exportieren eines Beschneidungspfads in einer PSD-Datei.

Dieser Beschneidungspfad kann in Programmen verwendet werden, die Beschneidungspfade unterstützen, z. B. Scribus (Desktop Publishing). Scribus listet bereits alle Pfade als nutzbare Beschneidungspfade auf, hebt aber den ausgewählten Beschneidungspfad grün hervor, wodurch der gewünschte Pfad besser für diesen Zweck gekennzeichnet werden kann.

GIF zeigt die Verwendung eines Beschneidungspfads, erstellt in GIMP 2.99.16, in Scribus.

Ähnlich wird beim Import jede in der PSD gespeicherte Beschneidungspfadinformation als Standard für den Export wiederverwendet.

Eine weitere interessante Änderung ist, dass beim Import, falls einige PSD-Funktionen nicht unterstützt werden, ein Kompatibilitätswarnungsdialog angezeigt wird, der alle fehlenden Funktionen auflistet:

PSD-Kompatibilitätswarnungen in GIMP 2.99.16 beim Import einer PSD-Datei mit nicht unterstützten Funktionen.

Auf diese Weise können Sie beim Arbeiten mit ausgetauschten PSD-Dateien eine fundierte Entscheidung treffen. Beachten Sie, dass der Exportdialog auch einen neuen „Kompatibilitätshinweis“ bezüglich älterer Ebenenmodi enthält, da einige Leute festgestellt haben, dass sie eine bessere Kompatibilität haben, wenn sie PSDs exportieren und in Photoshop wieder öffnen.

Zu guter Letzt wurde eine neue PDB-Prozedur "file-psd-load-metadata" erstellt, um anderen Plug-ins zu ermöglichen, das Laden von PSD-Metadaten an das PSD-Plug-in zu delegieren. Tatsächlich ist eine gängige Nutzung in verschiedenen Dateiformaten die Selbst-Erweiterung durch Speicherung benutzerdefinierter Metadaten im proprietären Photoshop-Metadatenformat. Wir haben bereits zwei solche Anwendungen implementiert:

• TIFF-Bilder können proprietäre Ressourcen auf Bildebene in den TIFFTAG_PHOTOSHOP-Metadaten sowie Ressourcen auf Ebenenebene (z. B. PSD-Ebenen anstelle von TIFF-Seiten) in den TIFFTAG_IMAGESOURCEDATA-Metadaten enthalten. GIMP unterstützt nun beides und lädt, was es unterstützt.
• JPEG-Bilder können PSD-Metadaten nur auf Bildebene enthalten, wie z. B. Pfade. Diese werden nun ebenfalls geladen.

Wie im PSD-Plug-in selbst wird ein Kompatibilitätsdialog angezeigt, wenn einige dieser Metadaten nicht unterstützt werden. Dies wird eine völlig neue Welt der Unterstützung für JPEG und TIFF (bezüglich der spezifischen proprietären PSD-Ressourcen) ermöglichen, da sie sich an das Unterstützungsniveau des PSD-Plug-ins anpassen, anstatt Code zu duplizieren.

JPEG

Zusätzlich zu den verschiedenen Metadaten-bezogenen Verbesserungen wurde die Option „4:2:2 horizontal (Chroma halbiert)“ in „4:2:2 (Chroma horizontal halbiert)“ und die Option „4:2:2 vertikal (Chroma halbiert)“ in „4:4:0 (Chroma vertikal halbiert)“ umbenannt. Untersuchungen zeigen, dass dies heutzutage die gebräuchlichsten Notationen für diese Optionen sind.

JPEG-XL

Wir haben die anfängliche Unterstützung für den CMYK(A)-Export hinzugefügt: Key- und Alpha-Daten werden in zusätzlichen Kanälen gespeichert und das Simulationsprofil wird ebenfalls gespeichert. Gemäß den Spezifikationsentwicklern unterstützt das Format keine „naive“ CMYK-Konvertierung, daher ist ein Profil für den Export erforderlich. Die Option „Als CMYK exportieren“ wird deaktiviert, wenn kein CMYK-Simulationsprofil festgelegt ist.

DDS

Wir haben die OpenMP-Unterstützung aktiviert, sofern auf dem Build-Rechner verfügbar. Dies bedeutet insbesondere, dass die parallele Verarbeitung aktiviert ist, was in einigen Fällen die Verarbeitungsgeschwindigkeit verbessern sollte.

Neue Bildformat-Unterstützung: PAM, QOI, Amiga IFF/ILBM, DCX

Wir haben kürzlich sowohl den Import als auch den Export für die folgenden Formate hinzugefügt:

• PAM (Portable Arbitrary Map)
• QOI (Quite OK Image) – ein modernes, verlustfreies Format
• Amiga IFF/ILBM (Import und Export)
• DCX (Zsoft Multiple Page PCX)

Wir haben nur Import-Unterstützung für die folgenden Formate hinzugefügt:

• DPX (Digital Picture Exchange)
• EXR (OpenEXR)
• HDR (Radiance HDR)
• PIX (Alias PIX)
• PSC (Photoshop Custom Shapes)
• SGI (Silicon Graphics Image)
• Sun rasterfile
• XBM (X BitMap)
• XPM (X PixMap)

Es mag nutzlos erscheinen, seltsame, alte, wenn nicht manchmal vergessene Formate zu unterstützen, aber dies ist tatsächlich wichtig (zumindest die Importfunktion). Dies kann nützlich für die Archivierung sein, um alte Bilder, die man vor Jahren erstellt hat, anzeigen, wiederverwenden und bearbeiten zu können. Letztendlich zielt GIMP darauf ab, jedes Format laden zu können, das jemals existiert hat! Hinweis: Einige dieser neuen Unterstützungen sind möglicherweise noch nicht in unseren offiziellen Paketen enthalten (z. B. Amiga IFF/ILBM), sollten aber bald folgen.

Plug-in-API

Die Entwicklungsschnittstelle für Plug-ins entwickelt sich weiterhin zu ihrem Endzustand, obwohl sie nun, da die GTK+3-Portierung abgeschlossen ist, noch eine der letzten großen Baustellen darstellt.

Ressourcen-Daten erhalten eigene Klasse

GIMP-Plug-ins bezogen sich früher auf verschiedene Ressourcen (Pinsel, Schriftarten, Verläufe, Paletten, Muster usw.) anhand ihres Namens. Wir sind dazu übergegangen, spezifische Klassen (GimpBrush, GimpFont, GimpGradient, GimpPalette und GimpPattern entsprechend) in libgimp für diese Daten zu erstellen, unter einer gemeinsamen Elternklasse GimpResource. Dies verschiebt diesen Teil der API zu einer objektorientierten Schnittstelle (wie andere bestehende Typen für Bilder, Ebenen…), was für Bindings viel angenehmer sein wird.

Darüber hinaus gehen wir zu eindeutigen IDs für jede Ressource über, die nicht auf Namen basieren. Während dieser Teil noch größtenteils libgimp-seitig ist, planen wir, Namen auch im Kerncode weniger als Bezeichner zu verwenden. Dies führt tatsächlich viel zu leicht zu Namenskollisionen, insbesondere wenn Sie Daten mit anderen Personen austauschen (es ist sehr einfach, benutzerdefinierte Pinsel oder Schriftarten zu finden, die von verschiedenen Personen erstellt wurden und denselben Namen verwenden). Wir arbeiten daran, GIMP robuster gegenüber solchen realen Namenskollisionen zu machen.

Verbesserte Plug-in-Lokalisierung

Es wurde an der Überprüfung unserer Plug-in-Lokalisierungsregeln gearbeitet. Während die Menü-Strings früher von der Kernanwendung selbst lokalisiert wurden, wurde der Rest vom Plug-in-Prozess lokalisiert. Dies war für Drittanbieter-Entwickler immer verwirrend („Soll ich _() oder N_() zum Übersetzen von Strings verwenden?“). Jetzt ist es sehr einfach: Die Plug-ins kümmern sich vollständig um ihre eigene Lokalisierung und senden daher immer bereits übersetzte Strings an den Kernprozess. Es bedeutet auch, dass das Ändern der GIMP-Spracheinstellungen ein Neuladen aller Plug-in-Registrierungen auslöst (um Strings zu aktualisieren).

Abgesehen von der Vereinfachung der Regel verhindert dies auch eine mögliche Kollision für die gettext-Katalognamen (falls zwei Plug-ins denselben Katalognamen verwenden würden, spielt dies keine Rolle mehr, da jeder Prozess seine eigenen verwaltet). Und schließlich, obwohl wir gettext weiterhin empfehlen (wir bieten auch Infrastrukturfunktionen für Plug-ins, um die Plug-in-Lokalisierung mit gettext einfach einzurichten), gibt es Drittanbieter-Plug-in-Entwicklern mehr Freiheit, ihre eigene Lokalisierungsinfrastruktur zu wählen, wenn sie etwas anderes bevorzugen. All diese Änderungen sind auch Teil einer längerfristigen Arbeit, Plug-ins in eigenständige Erweiterungen zu überführen, die einfach teilbar und installierbar sein werden.

Spezialisiertere Plug-in-Argumenttypen

Während GStrv in GIMP 2.99.10 hinzugefügt wurde, wurde es bis zu dieser Version nicht in Konfigurationsdateien (unsere Infrastruktur zum Speichern von Plug-in-Einstellungen über mehrere Ausführungen hinweg) serialisiert. Eine sehr coole erste Nutzung dieser Fähigkeit ist für die Script-fu-Konsole, die sich jetzt an den Verlauf der ausgeführten Befehle erinnert.

Darüber hinaus haben Plug-ins jetzt Zugriff auf GBytes-Argumente für all jene Fälle, in denen wir stattdessen Arrays von vorzeichenlosen 8-Bit-Ganzzahlen missbraucht haben, um Binärdaten (oder allgemeiner benutzerdefinierte Daten, die alles von Text bis Binär sein können) darzustellen. Der Typ GimpUint8Array wurde als möglicher Plug-in-Argumenttyp entfernt und alle seine Verwendungen ersetzt.

Und mehr…

Es wurden weitere Funktionen hinzugefügt, zum Beispiel zur Verbesserung der GUI-Generierungsfähigkeiten für Plug-ins. Einige Codierungsprobleme wurden behoben und die Anmerkungen und die Verwendung verschiedener Funktionen wurden geklärt. Für eine umfassendere Liste der hinzugefügten, entfernten oder geänderten Funktionen empfehlen wir einen Blick in die NEWS-Datei.

GEGL, babl

Wie üblich wird diese Version von GIMP von neuen Versionen von babl und GEGL begleitet:

babl 0.1.104 und 0.1.106 verbesserten den LUT-Code und sorgen für einen schnelleren Start durch das Caching von ausgeglichenen RGB-zu-XYZ-Matrizen.

GEGL 0.4.44 und 0.4.46 begannen zusätzlich zu den üblichen Fehlerbehebungen, den "gimp:menu-path"-Schlüssel zu einigen Operationen hinzuzufügen, verbesserten gegl:ff-load, gegl:ff-save, um sie mit FFmpeg 6.0 zu kompilieren (obwohl gegl:ff-save mit dieser Version von FFmpeg immer noch nicht richtig funktioniert), und fügten 2 neue Operationen hinzu:

• gegl:chamfer Eine neue Operation im Workshop, die gegl:distance-transform und gegl:emboss verwendet, basierend auf LinuxBeavers Forschung zur Modellierung verschiedener Fasen mit Kombinationen von Unschärfen.

• gegl:local-threshold Nachbarschaftsbewusste und optional geglättete Schwellenwertbildung eines Bildes. Die Operation ist äquivalent zu einer Unscharfmaskierung mit einem großen Radius, gefolgt von einer Skalierung des Bildes nach oben, Anwendung des Schwellenwerts und Skalierung nach unten um den inversen Skalierungsfaktor. Wenn Sie ein Foto haben und einen anständigen Glanz- und Schatten-Schwellenwert erstellen möchten, liefert es wesentlich bessere Ergebnisse als der integrierte Schwellenwert. Es findet pro Pixel angepasste Schwellenwertstufen für einen Gaußschen Durchschnitt aus dem Nachbarschaftsradius. Zusätzlich ermöglicht es die Erstellung von Antialiasing-Schwellenwertmasken (wenn der Radius auf 0 gesetzt wird, ist das Verhalten ähnlich der integrierten Schwellenwertoperation). Aus UX-Sicht fehlt diesem neuen Filter nur noch die Angabe der rgb⇒gray-Konvertierung, dann wären die zusätzlichen Teile der Benutzeroberfläche Optionen für den Schwellenwert. Beachten Sie jedoch, dass das Antialiasing durch Hoch- und Herunterskalieren des Inputs erreicht wird – hohe Einstellungen führen also zu viel Rechenaufwand mit relativ geringem Qualitätsgewinn.

Bildvergleich in GIMP 2.99.16: Original, Ergebnis mit aktuellem Schwellenwertfilter, Ergebnis mit neuem "gegl:local-threshold".

Statistik zur Veröffentlichung

Seit GIMP 2.99.14:

• 105 Berichte wurden in 2.99.16 als BEHOBEN geschlossen.
• 123 Merge Requests wurden zusammengeführt.
• 1115 Commits wurden gepusht.
• 25 Übersetzungen wurden aktualisiert: Baskisch, Bulgarisch, Katalanisch, Chinesisch (China), Chinesisch (Taiwan), Dänisch, Esperanto, Französisch, Georgisch, Deutsch, Griechisch, Ungarisch, Isländisch, Italienisch, Litauisch, Persisch, Polnisch, Portugiesisch, Rumänisch, Russisch, Slowenisch, Spanisch, Schwedisch, Türkisch, Ukrainisch.

67 Personen haben Änderungen oder Fehlerbehebungen zur GIMP 2.99.16 Codebasis beigetragen (Reihenfolge bestimmt durch Anzahl der Commits):

• 34 Entwickler: Jehan, Alx Sa, Michael Natterer, Jacob Boerema, Simon Budig, Luca Bacci, Niels De Graef, Daniel Novomeský, Lloyd Konneker, Øyvind Kolås, Lukas Oberhuber, Ian Martins, programmer-ceds, Andras Timar, Andre Klapper, Carlos Garnacho, Idriss Fekir, Jordi Mallach, Sabri Ünal, Shubham, Stanislav Grinkov, Stephan Lenor, Venkatesh, kotvkvante, lapaz, lillolollo, programmer_ceds, valadaptive, 依云, Anders Jonsson, Jordi Mas, Richard Szibele, Tomasz Golinski und Florian Weimer.
• 31 Übersetzer: Martin, Yuri Chornoivan, Ekaterine Papava, Alexander Shopov, Hugo Carvalho, Jordi Mas, Sabri Ünal, Rodrigo Lledó, Asier Sarasua Garmendia, Anders Jonsson, Alan Mortensen, Cristian Secară, Sveinn í Felli, dimspingos, Alexandre Prokoudine, Balázs Úr, Chao-Hsiung Liao, Piotr Drąg, Tim Sabsch, Kristjan SCHMIDT, Luming Zh, Marco Ciampa, Alexandre Franke, Aurimas Černius, Balázs Meskó, Christian Kirbach, Danial Behzadi, Emin Tufan Çetin, MohammadSaleh Kamyab, Zurab Kargareteli und حجت‌اله مداحی.
• 10 Ressourcen-Ersteller (Icons, Themes, Cursor, Splashscreen, Metadaten…): Jehan, Michael Natterer, Alx Sa, Stanislav Grinkov, Lloyd Konneker, Ville Pätsi, Aryeom Han, Daniel Novomeský, Anders Jonsson und Mark.
• 5 Dokumentations-Mitarbeiter: Jehan, Lloyd Konneker, Anders Jonsson, Corey Berla und Michael Natterer.
• 15 Build- oder CI-Mitarbeiter: Jehan, Alx Sa, Jacob Boerema, Michael Natterer, Daniel Novomeský, Lloyd Konneker, Michael Schumacher, Stanislav Grinkov, Niels De Graef, Simon Budig, Lukas Oberhuber, Florian Weimer, Luca Bacci, lillolollo und Jordi Mallach.

Beiträge zu anderen Repositories im GIMPverse (Reihenfolge bestimmt durch Anzahl der Commits):

• 1 Mitwirkender an babl 0.1.104 und 0.1.106: Øyvind Kolås.
• 13 Mitwirkende an GEGL 0.4.44 und 0.4.46: Øyvind Kolås, Marco Ciampa, Martin, Asier Sarasua Garmendia, Ekaterine Papava, Piotr Drąg, Yuri Chornoivan, Alexandre Prokoudine, Jan Tojnar, Rodrigo Lledó, Sabri Ünal, Tim Sabsch und dimspingos.
• 2 Mitwirkende an ctx seit der 2.99.14 Veröffentlichung: Øyvind Kolås und Carlos Eduardo.
• 3 Mitwirkende an gimp-macos-build (macOS Build-Skripte) seit der 2.99.14 Veröffentlichung: Lukas Oberhuber, Kyungjoon Lee und Mingye Wang.
• 2 Mitwirkende (und ein Bot) am Beta-Flatpak: Jehan, Daniel Novomeský und flathubbot.
• 7 Mitwirkende an unserer Haupt-Website (die Sie gerade lesen) seit der 2.99.14 Veröffentlichung: Jehan, Sabri Ünal, Jacob Boerema, Aryeom Han, Michael Schumacher, lillolollo und Tim Spriggs.
• 9 Mitwirkende an unserer Entwickler-Website seit der 2.99.14 Veröffentlichung: Jehan, Bruno Lopes, Jacob Boerema, Krek Krek, Mark, Alx Sa, GoldenWon, Michael Schumacher und kotvkvante.
• 16 Mitwirkende an unserer 3.0-Dokumentation seit der 2.99.14 Veröffentlichung: Andre Klapper, Jacob Boerema, Anders Jonsson, dimspingos, Yuri Chornoivan, Jordi Mas, Nathan Follens, Tim Sabsch, حجت‌اله مداحی, Alexander Shopov, Balázs Úr, Danial Behzadi, Hugo Carvalho, Martin, Piotr Drąg und Rodrigo Lledó.

Vergessen wir nicht, all den Leuten zu danken, die uns beim Triage in Gitlab helfen, Fehler melden und mögliche Verbesserungen mit uns diskutieren. Unsere Community ist auch den Internet-Kriegern zutiefst dankbar, die unsere verschiedenen Diskussionskanäle oder Social-Media-Konten wie Ville Pätsi, Liam Quin, Michael Schumacher und Sevenix verwalten!

Team-Neuigkeiten und Veröffentlichungsprozess

Unser Veröffentlichungsprozess wird mit jeder neuen Version immer besser. Ich möchte unseren Testern danken, die eine großartige Arbeit geleistet haben, indem sie die wenigen veröffentlichungsblockierenden Probleme für GIMP 2.99.16 aufdeckten, sowie den Personen, die diese Probleme verfolgten, technische Antworten gaben, Pakete erstellten oder aktualisierten und vieles mehr.

Ein besonderer großer Dank geht an (in alphabetischer Reihenfolge) Alx Sa, Anders Jonsson, Daniel Novomeský, Hubert Figuière, Jacob Boerema, Liam Quin, lillolollo, Luca Bacci, Lukas Oberhuber, Mark Sweeney, Sevenix, ShiroYuki_Mot und Uzugijin!

Zur Erinnerung: Wenn jemand uns bei der Verbesserung von GIMP helfen möchte, indem er am Release Testing teilnimmt, eröffnen Sie bitte einen Bericht im Entwickler-Website-Tracker mit den folgenden Informationen:

• Die Betriebssysteme (Linux, Windows, macOS, *BSD…), auf denen Sie testen werden, mit Details, falls möglich (welche Linux-Distribution und Version? Welche Version von Windows oder macOS?…).
• Die Architekturen, auf denen Sie testen werden (x86, ARM… 32 oder 64-Bit).
• Ob Sie unsere vorab erstellten Pakete oder aus dem Quellcode (benutzerdefinierte Builds) testen werden.

Wir werden Sie dann in der nächsten Release-Testphase (stabile und Entwicklungsversionen) benachrichtigen. Unsere Erwartungen an Tester:

• Stellen Sie sicher, dass Sie Gitlab-Benachrichtigungen erhalten, wenn Ihr Nickname zitiert wird (wir empfehlen, Ihr globales Benachrichtigungslevel auf „Participate“ oder „On mention“ einzustellen).
• Verfolgen Sie den Release-Bericht, um zu wissen, was passiert und wann Sie benötigt werden.
• Release-Berichte sind kein Ort, an dem wir den Leuten beibringen, wie man grundlegende Computerfunktionen bedient. Tester müssen keine Entwickler sein, aber sie müssen in der Lage sein, grundlegende technische Richtlinien zu befolgen, nützlicheres Feedback als „es funktioniert nicht“ zu geben und global in der Lage zu sein, mit Entwicklern zu interagieren.
• Seien Sie nett und einladend: Jeder hier ist ein Freiwilliger, Tester genauso wie Entwickler. Dies ist Community, Freie Software, kein seelenloser Job.

Rund um GIMP

Spiegelserver-Neuigkeiten

Der Fremont Cabal Internet Exchange hat einen neuen Download-Spiegelserver zur Verteilung von GIMP beigesteuert, der sich in Sheffield, South Yorkshire (Vereinigtes Königreich) befindet. Mit 11 von insgesamt 41 Spiegelservern sind sie eindeutig unser größter Spiegelserver-Sponsor! Vielen Dank, FCIX!

Spiegelserver sind wichtig, da sie das Projekt entlasten, indem sie die Last von Zehntausenden täglichen Downloads teilen. Darüber hinaus stellen wir durch die weltweite Verteilung der Spiegelserver sicher, dass jeder schnellen Download-Zugriff auf GIMP erhält.

Buch-Neuigkeiten

Sabri Ünal hat eine fantastische bibliografische Recherche durchgeführt, 39 Bücher hinzugefügt und noch mehr auf unserer Seite „Bücher über GIMP“ aktualisiert. Wir werden nicht alle Änderungen auflisten, da es einfach zu viele sind, aber Sie können die detaillierten Merge-Request-Beschreibungen (!93 und !98) lesen.

Wir beginnen, eine aktuellere Buchseite mit neueren Veröffentlichungen zu erhalten. Super! Wir erinnern alle daran, dass wir Buchergänzungen begrüßen. Wenn Sie ein noch nicht gelistetes Buch über GIMP kennen, melden Sie bitte dieselben Informationen wie andere Bücher in der Liste. Danke!

GIMP 2.99.16 herunterladen

GIMP 2.99.16 ist derzeit nur für Linux und Windows verfügbar. Unsere macOS-Paketierung ist derzeit blockiert, da wir die Pakete nicht notarisieren können, bis die GNOME Foundation ihr Apple-Konto repariert hat. Wir werden Sie auf dem Laufenden halten. Update vom 11. Juli: GIMP 2.99.16 ist jetzt auf Linux, Windows und macOS verfügbar!

Sie finden alle unsere offiziellen Builds auf der offiziellen GIMP-Website (gimp.org):

• Linux Development Flatpak
• Windows Installer
• macOS DMG-Pakete für Intel-Hardware
• macOS DMG-Pakete für Apple Silicon-Hardware

Es wird natürlich erwartet, dass weitere Pakete von Drittanbietern folgen (Linux- oder *BSD-Distributionspakete usw.).

Was kommt als Nächstes

Obwohl die Roadmap noch einige unvollendete Punkte zeigt, sind die beiden größten Arbeitsbereiche für die nächste Version die Neugestaltung der API – die gut vorankommt, aber wichtig genug ist, dass wir uns wirklich auf Details konzentrieren müssen – und das Space Invasion Projekt (um sicherzustellen, dass jede bestehende farbbezogene Funktion zuverlässig ist).

Da wir uns wirklich der „Stabilisierungsphase“ unserer Entwicklung nähern und unsere Anforderungsregel auf „Debian testing“ (was auch immer es war) basierte, haben wir kürzlich unsere Abhängigkeits-Updates auf das gerade veröffentlichte Debian 12 (Bookworm) eingefroren. Das bedeutet, dass wir keine Mindestanforderungen über das hinaus erhöhen werden, was in Debian 12 enthalten ist (außer für optionale Abhängigkeiten, und selbst dann nur in Ausnahmefällen und mit sehr guten Gründen). Dies liegt daran, dass wir planen, bald genug zu veröffentlichen, um sicherzustellen, dass GIMP auf allen einigermaßen aktuellen Distributionen paketiert werden kann. Für unsere eigenen Pakete (Windows, macOS und Flatpak) werden wir natürlich ohnehin immer die neuesten Abhängigkeitsversionen verwenden.

Vergessen Sie nicht, dass Sie GIMP-Entwickler persönlich unterstützen und finanzieren können, um etwas zurückzugeben und die Entwicklung von GIMP zu beschleunigen. Das Engagement der Gemeinschaft hilft dem Projekt, stärker zu werden!

Fazit

Die Veröffentlichung von GIMP 2.99.16 ist ein beeindruckender Meilenstein auf dem Weg zu GIMP 3.0 und ein klares Zeichen für die Dynamik, die GIMP 2023 prägt. Von der vollständigen GTK+3-Portierung und der revolutionären GimpAction-Infrastruktur bis hin zu den tiefgreifenden Verbesserungen bei Dateiformaten und der Plug-in-API zeigt dieses Update, dass GIMP nicht nur mit modernen Standards Schritt hält, sondern diese aktiv mitgestaltet. Besonders hervorzuheben sind die verbesserte Integration von GEGL-Operationen, die erweiterten Werkzeugfunktionen und die Fortschritte im Farbmanagement, die alle dazu beitragen, GIMP zu einem noch leistungsfähigeren und benutzerfreundlicheren Grafikprogramm zu machen.

Diese Entwicklung unterstreicht das Engagement der GIMP-Community, eine robuste und innovative Open-Source-Bildbearbeitungssoftware bereitzustellen. Wer auf dem neuesten Stand der digitalen Bildbearbeitung bleiben möchte, sollte die kontinuierliche Entwicklung von GIMP im Auge behalten. Laden Sie GIMP 2.99.16 noch heute herunter und erleben Sie die Zukunft der kostenlosen Bildbearbeitung selbst. Ihre Rückmeldungen und Ihre Unterstützung sind entscheidend, um GIMP noch weiter zu verbessern.

Referenzen:

• GIMP Offizielle Website: https://www.gimp.org/news/2023/07/09/gimp-2-99-16-released/