> automatische Verwaltung von Ebenen-Grenzen (dies ist wohl das sogenannte nichtdestruktive Editieren)
Nein. Die Ebengrenzen sind in Gimp die gelb-schwarz gestrichelten Linien. Wenn man eine neue Ebene in ein Bild einfügt nicht automatisch so groß wie das eigentliche Bild sondern kann auch größer oder kleiner sein. Dies kann ziemlich nerven, wenn man außerhalb der Ebengrenze z.B. etwas Malen möchte. Dann muss man nämlich erst von Hand die Ebenen Größe ändern. Dies soll so umgebaut werden, das es automatisch passiert.
Das sogenannte nichtdestruktive Editieren verbirgt sich ehr in den Punkten: 6. Filter layers (brightness/contrast, blur, etc) 10. "Smart objects" 11. "Layer effects" (bevel/emboss, draw line at edges, etc)
Das sogenannte nichtdestruktive Editieren verbirgt sich ehr in den Punkten: ...
und vor allem in den hohen Farbtiefen (16bit und mehr), die für die Version 3.0 geplant sind. Damit ist Gimp dann endlich für die Photobearbeitung geeignet. Bei 8 Bit Farbtiefe bekommt man nämlich bei jeder Farbkorrektur sofort Tonwertabrisse. Das macht GIMP völlig ungeignet für die Korrektur von Photos weil man nicht mehrere Filter hintereinander anwenden kann.
Ich fürchte allerdings, dass die Version 3.0 noch sehr lange auf sich warten lassen wird oder dieses Feature mal wieder verschoben wird. Das schieben sie jetzt schon seit zig Versionen vor sich her. Daher verstehe ich auch nicht, warum sie den Einfenster-Modus bevorzugt haben. Mit einer eigenartigen GUI kann man sich anfreunden, wenn allerdings ein wichtiges Feature fehlt, dann nützt auch die beste GUI nichts.
Weil viele das von dir beschriebene Problem so vermutlich nicht haben, z.B. weil sie die Veränderung nicht bemerken / sie nicht stört, oder weil die Grafiken editieren, bei denen das kein Problem ist.
Tools wie GIMP werden auch oft für das Erstellen von Web-Grafiken genutzt, da ist die Farbtiebe eher kein Problem.
Ich kann mit der Fenster-GUI von GIMP übriegens auch gut arbeiten, hätte also auf die Änderung auch verzichten können.
Die GEGL Integration ist auch halb fertig und das schon jetzt in der aktuellen Version. Die hätten sich lieber erstmal darauf konzentrieren sollen anstatt eine neue Baustelle anzufangen.
Von Senior Releasemanager am Mi, 2. März 2011 um 09:47 #
Ich plädiere für feste, zeitbasierte Releasezyklen. Man nimmt sich Features a, b, c, d, e, f, g vor, und wenn man innerhalb eines festen Zeitabschnitts dann nur a, b, c, d fertig hat, dann releast man trotzden und e, f, g werden eben in den nächsten Releasezyklus verschoben. Dazu muss man eventuell granularer aufteilen und natürlich mit Feature-Branches arbeiten.
Das geht bei Gimp nicht, da der Prozess dermaßen kaputt ist, dass man erst die Entwicklung umkrempeln müsste. Man stelle sich zum Beispiel vor, dass bei Gimp _alle_ in einem und den selben Main arbeiten. Alle Funktionen kommen also, nicht wie bei anderen Projekten üblich in einen Branch, sondern werden von jedem in einem Master-Branch entwickelt. Hat jemand etwas massiv geändert, müssen Andere warten, bis es wieder geht. Das selbe gilt auch für ein Release. Das hat auch Martin Nordholts gemerkt, nur ändern wird sich da nichts.
Aber siicccheeeeeerrrrr... Deswegen wurde es auch als besonders priorisiert und wichtig bei dem Treffen angesprochen und eine Änderung beschlossen. So wie du mich als Troll bezeichnest, nehme ich mir die Freiheit dich als Fanboi zu titulieren.
Wann kommt endlich CMYK? Ich verstehe das nicht, höhere Farbtiefen usw sind gut und schön, aber mit nur RGB ist das natürlich überhaupt nicht für die Erstellung von Printmedien geeignet.
Unsinn! Es gibt schon dutzende Systeme und Applikationen unter Linux, die CMYK unterstützen. Sollte es wirklich ausnahmsweise bei Gimp, und zwar nur bei Gimp, an den Patenten liegen, so frage ich mich, warum Gimp auch nicht in der Vergangenheit Probleme hatte, als es patentbehaftete Technologien, Dateiformate oder Funktionen einsetzte.
Von EgalBuntMussEsSein am Sa, 5. März 2011 um 20:55 #
Ich höre immer nur CMYK. Warum können sich die CMYK-Fetischisten ihren Farbraum nicht mal dorthin stecken, wo man ihn nicht mehr von RGB unterscheiden kann.
Lauthals gefordert scheint die Implementierung des Ein-Fenster-Modus nun eine ganze Menge an Unwägbarkeiten bereitet zu haben. Ich habe den Eindruck, geschrieen haben hier vor allen Dingen die Leute, die Gimp überhaupt nicht wirklich benutzen, sondern vielleicht mal ein Photo beschneiden. Trotzdem sollte Gimp gefälligst so aussehen, wie Photoshop Pro Elite Ultimate (aus der Tauschbörse?) unter Windows.
Na gut, jetzt also ein einzelnes Fenster, an den Bildbearbeitungsfunktionen ändert das zunächst einmal nichts. Als praktisch könnte sich die Umstellung in Verbindung mit der Gnome-Shell dennoch erweisen, ich weiß nicht inwiefern der Workflow dort mit den Einzelfenstern harmoniert hätte. Jetzt haben wir also die Fensterverwaltung in der Anwendung unter der Fensterverwaltung, denn Widgets für Werkzeuge und Ebenen benötigt man ja trotzdem weiterhin.
Gimp könnte vielleicht ferner unter Windows etwas an Popularität gewinnen, aber ich hoffe nicht, dass jetzt jeder Ruf von wegen "in Photoshop ist das aber anders" die eigentliche Entwicklung aufhält und der kreativen Ausgestaltung eigener Konzepte einen de facto Standard überstülpt, der wohlgemerkt auch nicht durchgängig stringent, sondern vielfach einfach im Laufe der Jahre gewachsen und teilweise konfus ist.
Volle Zustimmung. Der Einfenster-Modus ist völlig sinnlos solange essentielle Features fehlen. Die Popularität wird das nur sehr begrenzt steigern. Unter Linux müssen eh alle Gimp benutzen und unter Windows werden sie nicht viele neue Nutzer anlocken können. Im professionellen Bereich gibt es eh nur Photoshop und die Privaties kopieren sich lieber den Photoshop aus der Tauschbörse anstatt sich mit einem "minderwertigen" Programm abzugeben. Schliesslich braucht man unbedingt möglichst viele Features, selbst wenn man keine Ahnung hat was man damit machen kann.
Das hat sich langsam geändert. Für Bilderkorrektur benutzte ich mittlerweile kein Gimp mehr, da es funktionell mit Digikam oder Bibble nicht mehr mithalten kann. Für Bildkomposition werden Krita oder Pixel immer interessanter und haben Gimp in manchen Bereichen bereits überholt. Hier liegt der Einsatz bei mir bei ca. 50 Prozent.
Ich finde es hier ein bisschen degutant wie alle Leute, die den 1-Fenster-Modus gerne sehen würden, als Gelegenheits-Urlaubsfotobeschneider eingestuft werden (diese sind doch mit Digikam, F-Spot oder ImageMagick viel schneller bedient als mit Gimp). Ich finde Gimp in einem Fenster viel besser zu benutzen und habe Gimpbox, das Python Skript, dass Gimp in ein Fenster schmeißt, schon länger auf der 2.6-er Version. Ich finde es noch degutanter Menschen, die gewisse Features von Gimp wollten für die Entwicklungsarbeit von Gimp verantwortlich zu machen. Wenn es denn so buggy war, dann hätten die es doch ganz einfach lassen oder verschieben können. Wir haben uns schon länger mit Xnest, Xephyr oder eben Gimpbox zum 1-Fenster-Modus beholfen, da hätte man noch ruhig ein Paar Jahre warten können. Gimp ist Communityarbeit, aber keiner der Alle beisammen hat macht für mich Feature Foo wenn dies bedeutet, dass man Regressionen einführt.
Das wahre Problem bei Gimp war und bleibt die schwindende Entwicklerzahl. Also, lieber mitmachen oder spenden als trollend Annahmen über Benutzer des 1-Fenster-Modus zu machen.
Gimp ist ein perfektes Beispiel dafür, wie man ein erfolgreiches Projekt durch Missmanagement und Ignoranz gegenüber den Usern und an die Wand fahren kann. Das muss man sich vorstellen: Das Projekt war nicht mal in der Lage in groben Zügen die eigene Strategie zu umreißen. Wie sollen da andere dran arbeiten, wenn nicht mal die Herren Gimp wissen, was sie vorhaben. Es ist außerdem bezeichnend, wenn die Entwickler nicht mal in der Lage sind ein paar Mentoren zu finden, damit andere für sie _bezahlt_ arbeiten. Dann brauchen sie sich aber nicht wundern, wenn keiner an ihrem Krempel mitarbeiten mag. Und jammern sollen sie denn erst recht nicht.
Das ist so nicht richtig, es gibt schon seit 2006 eine "product vision":
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:
* GIMP is Free Software; * GIMP is a high-end photo manipulation application and supports creating original art from images; * GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements; * GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists; * GIMP is user-configurable to automate repetitive tasks; * GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.
Und anhand dieser "product vision" können neue Programmierer neue Funktionen einbauen? Da steht doch nichts konkretes drin, was irgendwie eine Richtung Gimp geben würde. Die von dir zittierte Stelle ist schlichtes Marketingsgeblubber, das nichts über die Zukunft aussagt.
"Das Projekt war nicht mal in der Lage in groben Zügen die eigene Strategie zu umreißen."
Jetzt willst du eine Liste von Aufgaben für neue Programmierer. Die gibt es z.B. im Bugzilla, da werden einfache Aufgaben für neue Programmierer mit einem Kennzeichen versehen:
von daher ist es schön das man das mittlerweile erkannt hat nur so kanns wieder aufwärts gehen mit Gimp
-der Mehrfenstermodus ist zumindest unter Windows eine Zumutung -der Quellcode für professionelle Nutzung ("high" Farben, CMYK) existiert sogar schon in einer früheren Abspaltung -warum müssen Betaversionen ein Zwangs Debug Fenster enthalten (das demonstriert schonmal die Denkweise)
lange Jahre weigerten sich die Programmierer das mal umzusetzen
für Einsteiger wäre auch ein paar einfache Werkzeuge sinnvoll wie zb einen Kreis zeichnen anstatt "‘one-click’ installation of plug-ins. "
alles eigentlich einfache Sachen, welche die Nutzerbasis verbessern könnten dann gäbs auch wieder mehr Entwickler ansonsten beisst sich nur die Katze in den Schwanz
ich erwarte kein High End Plugin das bei Photoshop 500,-EUR kostet für lau
> -der Quellcode für professionelle Nutzung ("high" Farben, CMYK) existiert sogar schon in einer früheren Abspaltung
Jain. CMYK gab es bisher noch in keiner Abspaltung 16 Bit Farbtiefe gab es in FimGimp/Cinepaint, war aber ein übler Hack. Wie schlimm sieht man daran, des es das Projekt mittlerweile nicht mehr gibt.
> -warum müssen Betaversionen ein Zwangs Debug Fenster enthalten (das demonstriert schonmal die Denkweise)
Welche Denkweise? Beta-Versionen sind nicht fürs produktive arbeiten gedacht, sondern nur zum testen. Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
> lange Jahre weigerten sich die Programmierer das mal umzusetzen
Es gab keine Weigerung, viel mehr wird schon lange an einer ordentlichen 16 Bit Farbunterstützung gearbeitet. Allerdings soll es ja ordentlich werden und nicht wie bei Fimgimp sein. Und das Gimp Team ist auch schon seit langem ein sehr kleines Team, also dauert es.
> für Einsteiger wäre auch ein paar einfache Werkzeuge sinnvoll wie zb einen Kreis zeichnen
Gimp soll, wie du an der "product vision" oben siehst, nicht für Einsteiger sondern für Profis sein.
> alles eigentlich einfache Sachen, welche die Nutzerbasis verbessern könnten > dann gäbs auch wieder mehr Entwickler
Das es einen Zusammenhang zwischen der Anzahl der Benutzer und der Anzahl der Entwickler gibt halte ich für eine gewagte These. Gimp für Windows wurde allein in diesem Jahr schon über 4 Millionen mal heruntergeladen, aber es gibt keinen einzigen aktiven Windowsentwickler für Gimp. Ab wie vielen Benutzern entsteht denn so ein Entwickler deiner Meinung nach?
Jain. CMYK gab es bisher noch in keiner Abspaltung
Klar gab es die. Erstmals mit Gimp 2.0 (eine einfache). Mit Separate+ gab es auch ein auf liblcms basierendes Plugin, das per Default auch in Gimphoto zu finden ist.
16 Bit Farbtiefe gab es in FimGimp/Cinepaint, war aber ein übler Hack. Wie schlimm sieht man daran, des es das Projekt mittlerweile nicht mehr gibt.
Wie kommst du darauf? Die letzte stabile Version von Cinepaint ist jünger, als die von Gimp.
Und wie hieß die? Hast du einen Namen oder einen Link?
> Erstmals mit Gimp 2.0 (eine einfache). Mit Separate+ gab es auch ein auf liblcms basierendes Plugin, das per Default auch in Gimphoto zu finden ist.
Wenn dir Separate+ reicht, dann nim doch das Plugin. Das gibt es ja schon länger für Gimp. Das ist aber nicht das was ich unter einer CMYK Unterstützung verstehe.
> Die letzte stabile Version von Cinepaint ist jünger, als die von Gimp.
Und wie kommst du da drauf? Die letzte Cinepaint Version ist laut http://sourceforge.net/projects/cinepaint/files/ vom 15.04.2008. Die letzte stabile Gimp Version (2.6.11) ist laut gimp.org vom 04.10.2010.
> Jain. CMYK gab es bisher noch in keiner Abspaltung
ok zurückgezogen
>Welche Denkweise? Beta-Versionen sind nicht fürs produktive arbeiten gedacht, sondern nur zum testen. Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
log Datei ? so machens jedenfalls 99% der anderen Programme
ich bin selber Programmierer, für mich zeigt sich da schon eine bestimmte Denkweise, die auch andere kritisiert haben
>Es gab keine Weigerung, viel mehr wird schon lange an einer ordentlichen 16 Bit Farbunterstützung gearbeitet. Allerdings soll es ja ordentlich werden und nicht wie bei Fimgimp sein. Und das Gimp Team ist auch schon seit langem ein sehr kleines Team, also dauert es.
das las sich bei Cinepaint etwas anders wie auch immer
> >Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
> log Datei ?
OK, könnte man machen. Allerdings ist das Logfenster, was man bei der Entwicklerversion von Gimp sieht ja nichts extra programmiertes, sondern nur das was Windows öffnet, wenn man Debugnachichten nach stdout schreibt. Unter Linux werden die nur angezeigt, wenn man die Entwicklerversion aus einer Konsole heraus startet. Also ehr ein Windows Problem. Und wie gesagt gibt es zur Zeit keinen aktiven Windows Entwickler. Also fällt es auch keinem auf.
> ich bin selber Programmierer, für mich zeigt sich da schon eine bestimmte Denkweise, > die auch andere kritisiert haben
ich weiss nicht genau wo du hinwillst sicher kann man jeden einzelnen punkt sezieren und dafür begründungen finden oder relativierungen
ich sags hier nochmal ich mag gimp und benutze gimp und empfehle es weiter
deshalb sollte man doch trotzdem bestimmte sachen kritisieren können deshalb bleibe ich auch dabei dass die probleme hausgemacht sind aber ab nun wird ja alles besser
--------------------------------------- und zu der denkweise: "ich bin der programmierer, fuck the rest" oder zumindest "ich entscheide was für die anwender richtig ist" die denkweise ist leider nicht so selten zum teil möglicherweise richtig, aber nicht in der gesamtkonsequenz
Vielleicht mal Krita probieren. Krita ist zwar nicht direkt auf Fotobearbeitung spezialisiert, aber es könnte ja reichen. Dafür hat Krita eine Einfenster-Oberfläche, CMYK, bis zu 32-bit Farbtiefe und kein Debug-Fenster. Außerdem gibt es Werkzeuge für Rechtecke, Kreise usw.
Um ehrlich zu sein fühlt man sich etwas verschaukelt. Vielleicht sollte man erstmal sehen, das man 2.8 über die Bühne bringt, auf die die Community sehnsüchtigst seit ewigen Zeiten wartet, bevor man sich Gedanken über 3.8 macht. Aus meiner Sicht Utopie.
Ich finde die Aussichten auf eine konsequente Weiterentwicklung von Gimp sehr erfreulich. Aus meiner Sicht ist Gimp ein sehr weit entwickeltes Werkzeug, bei dem ich mich über eine Weiterentwicklung in dem in der Roadmap angedeuteten Sinne außerordentlich freuen würde. Genau genommen gibt es kaum ein für Linux erhältliches Bildbearbeitungsprogramm, dass diese Möglichkeiten bietet, effektive Arbeit mit Ebenen und Masken. Krita habe ich schon vielfach probiert, komme aber nicht bisher noch nicht damit zurecht; vielleicht tut sich da ja auch noch was. Die Alternative zu Gimp, die ich derzeit - mangels 16-Bit-Unerstützung - nutze, ist das totgesagte Cinepaint, die Entwicklung mag hier stagnieren, aber das Programm ist brauchbar. Für mich brauchbarer als Photoshop, das sich für mich längst nicht so intuitiv bedienen lässt und sich abgesehen davon gegen Linux abschottet. Was ich mir wünschen würde, wäre eine gezielte Spendenkampagne von Seiten der Gimp-Entwickler, aus der hervorgeht, dass die Entwicklung, wie in der Raoadmap angekündigt in einem überschaubaren Zeitraum auf die 3.0 zielt und die GEGL-16-Bit-Unterstützung einschließt. Dafür würde ich sofort spenden, denn was den Workflow betrifft finde ich Gimp mit Abstand das beste Programm für Linux. Mag der Code sein wie er will und wer es beurteilen kann - es funktioniert wahrlich gut und bietet auf der 8-Bit Ebene inclusive der Erweiterungen sehr ausgereifte Funktionen. Dafür und für die angekündigte Weiterentwicklung möchte ich den Entwicklern Dank sagen.
Ich habe vor ca. anderthalb Jahren gespendet, da seither die Entwicklung etwas stagnierte und ich zunehmend auf andere Programme ausgewichen bin, habe ich gezögert, werde es aber, wie gesagt erneut tun, sobald die Entwicklungsperspektive aus meiner Sicht noch etwas klarer wird.
Konkret bin ich mit dem Maskenwerkzeug nicht zurechtgekommen, dass heißt, ich habe es nicht geschafft, für eine Ebene eine Maske anzulegen und da hinein die Fotografie selbst als Maske zu kopieren, was bei Gimp überhaupt kein Problem ist. Ich habe auch keine Anleitung gefunden, wie ich so etwas mit Krita ausführen könnte, bin dann allerdings auch nicht in Foren gegangen, da ich auf Cinepaint ausweichen konnte und Krita bei mir auch etwas instabil operierte. Ich kam dann zu dem (vorläufigen) Schluss, dass Krita wohl mehr als Zeichenprogramm, denn als Fotobearbeitungsprogramm konzipiert wäre. (opensuse 11.3)
Die neuste Krita Version 2.3 ist wesentlich stabiler als die Version 2.1 die mit OpenSuse 11.3 kommt. Masken können über den Ebenen-Docker angelegt werden.
eine Maske anzulegen ist das eine, bisher ist mir noch nie gelungen, sie zu benutzen; d.h. konkret in die Maske eine Kopie des Bildes einzufügen, um damit z.B. nur die hellen Bereiche des Bildes zu nutzen. Bin ab heute bis Ende nächster Woche ohne PC und Internet unterwegs, für einen Hinweis, ob und wie das mit Krita funktioniert, wäre ich aber sehr dankbar. Grüße
> automatische Verwaltung von Ebenen-Grenzen (dies ist wohl das sogenannte nichtdestruktive Editieren)
Nein. Die Ebengrenzen sind in Gimp die gelb-schwarz gestrichelten Linien. Wenn man eine neue Ebene in ein Bild einfügt nicht automatisch so groß wie das eigentliche Bild sondern kann auch größer oder kleiner sein. Dies kann ziemlich nerven, wenn man außerhalb der Ebengrenze z.B. etwas Malen möchte. Dann muss man nämlich erst von Hand die Ebenen Größe ändern.
Dies soll so umgebaut werden, das es automatisch passiert.
Das sogenannte nichtdestruktive Editieren verbirgt sich ehr in den Punkten:
6. Filter layers (brightness/contrast, blur, etc)
10. "Smart objects"
11. "Layer effects" (bevel/emboss, draw line at edges, etc)
und vor allem in den hohen Farbtiefen (16bit und mehr), die für die Version 3.0 geplant sind. Damit ist Gimp dann endlich für die Photobearbeitung geeignet. Bei 8 Bit Farbtiefe bekommt man nämlich bei jeder Farbkorrektur sofort Tonwertabrisse. Das macht GIMP völlig ungeignet für die Korrektur von Photos weil man nicht mehrere Filter hintereinander anwenden kann.
Ich fürchte allerdings, dass die Version 3.0 noch sehr lange auf sich warten lassen wird oder dieses Feature mal wieder verschoben wird. Das schieben sie jetzt schon seit zig Versionen vor sich her. Daher verstehe ich auch nicht, warum sie den Einfenster-Modus bevorzugt haben. Mit einer eigenartigen GUI kann man sich anfreunden, wenn allerdings ein wichtiges Feature fehlt, dann nützt auch die beste GUI nichts.
"warum sie den Einfenster-Modus bevorzugt haben"
Weil viele das von dir beschriebene Problem so vermutlich nicht haben, z.B. weil sie die Veränderung nicht bemerken / sie nicht stört, oder weil die Grafiken editieren, bei denen das kein Problem ist.
Tools wie GIMP werden auch oft für das Erstellen von Web-Grafiken genutzt, da ist die Farbtiebe eher kein Problem.
Ich kann mit der Fenster-GUI von GIMP übriegens auch gut arbeiten, hätte also auf die Änderung auch verzichten können.
"warum sie den Einfenster-Modus bevorzugt haben"
Weil er halb fertig ist. und die 2.8 raus soll.
> Weil er halb fertig ist. und die 2.8 raus soll.
Die GEGL Integration ist auch halb fertig und das schon jetzt in der aktuellen Version. Die hätten sich lieber erstmal darauf konzentrieren sollen anstatt eine neue Baustelle anzufangen.
Ich plädiere für feste, zeitbasierte Releasezyklen. Man nimmt sich Features a, b, c, d, e, f, g vor, und wenn man innerhalb eines festen Zeitabschnitts dann nur a, b, c, d fertig hat, dann releast man trotzden und e, f, g werden eben in den nächsten Releasezyklus verschoben. Dazu muss man eventuell granularer aufteilen und natürlich mit Feature-Branches arbeiten.
Das geht bei Gimp nicht, da der Prozess dermaßen kaputt ist, dass man erst die Entwicklung umkrempeln müsste. Man stelle sich zum Beispiel vor, dass bei Gimp _alle_ in einem und den selben Main arbeiten. Alle Funktionen kommen also, nicht wie bei anderen Projekten üblich in einen Branch, sondern werden von jedem in einem Master-Branch entwickelt. Hat jemand etwas massiv geändert, müssen Andere warten, bis es wieder geht. Das selbe gilt auch für ein Release. Das hat auch Martin Nordholts gemerkt, nur ändern wird sich da nichts.
Aha. Du trollst also.
Klar: http://www.chromecode.com/2011/02/why-gimp-28-is-not-released-yet.html
Dein Trollen liegt darin, dass du behauptest es wird sich nichts ändern, obwohl die Entwickler sich des Problems bewusst sind.
Aber siicccheeeeeerrrrr... Deswegen wurde es auch als besonders priorisiert und wichtig bei dem Treffen angesprochen und eine Änderung beschlossen. So wie du mich als Troll bezeichnest, nehme ich mir die Freiheit dich als Fanboi zu titulieren.
Wenn ich ein Fanboi bin, dann bist du ein Hateboi.
Nee, selber doof!
Triefnase
Wann kommt endlich CMYK? Ich verstehe das nicht, höhere Farbtiefen usw sind gut und schön, aber mit nur RGB ist das natürlich überhaupt nicht für die Erstellung von Printmedien geeignet.
Wenn die Patente auslaufen?
Unsinn! Es gibt schon dutzende Systeme und Applikationen unter Linux, die CMYK unterstützen. Sollte es wirklich ausnahmsweise bei Gimp, und zwar nur bei Gimp, an den Patenten liegen, so frage ich mich, warum Gimp auch nicht in der Vergangenheit Probleme hatte, als es patentbehaftete Technologien, Dateiformate oder Funktionen einsetzte.
.. wohl als Scherz gemeint.
Ich höre immer nur CMYK. Warum können sich die CMYK-Fetischisten ihren Farbraum nicht mal dorthin stecken, wo man ihn nicht mehr von RGB unterscheiden kann.
Lauthals gefordert scheint die Implementierung des Ein-Fenster-Modus nun eine ganze Menge an Unwägbarkeiten bereitet zu haben. Ich habe den Eindruck, geschrieen haben hier vor allen Dingen die Leute, die Gimp überhaupt nicht wirklich benutzen, sondern vielleicht mal ein Photo beschneiden. Trotzdem sollte Gimp gefälligst so aussehen, wie Photoshop Pro Elite Ultimate (aus der Tauschbörse?) unter Windows.
Na gut, jetzt also ein einzelnes Fenster, an den Bildbearbeitungsfunktionen ändert das zunächst einmal nichts. Als praktisch könnte sich die Umstellung in Verbindung mit der Gnome-Shell dennoch erweisen, ich weiß nicht inwiefern der Workflow dort mit den Einzelfenstern harmoniert hätte. Jetzt haben wir also die Fensterverwaltung in der Anwendung unter der Fensterverwaltung, denn Widgets für Werkzeuge und Ebenen benötigt man ja trotzdem weiterhin.
Gimp könnte vielleicht ferner unter Windows etwas an Popularität gewinnen, aber ich hoffe nicht, dass jetzt jeder Ruf von wegen "in Photoshop ist das aber anders" die eigentliche Entwicklung aufhält und der kreativen Ausgestaltung eigener Konzepte einen de facto Standard überstülpt, der wohlgemerkt auch nicht durchgängig stringent, sondern vielfach einfach im Laufe der Jahre gewachsen und teilweise konfus ist.
Volle Zustimmung. Der Einfenster-Modus ist völlig sinnlos solange essentielle Features fehlen. Die Popularität wird das nur sehr begrenzt steigern. Unter Linux müssen eh alle Gimp benutzen und unter Windows werden sie nicht viele neue Nutzer anlocken können. Im professionellen Bereich gibt es eh nur Photoshop und die Privaties kopieren sich lieber den Photoshop aus der Tauschbörse anstatt sich mit einem "minderwertigen" Programm abzugeben. Schliesslich braucht man unbedingt möglichst viele Features, selbst wenn man keine Ahnung hat was man damit machen kann.
Das hat sich langsam geändert. Für Bilderkorrektur benutzte ich mittlerweile kein Gimp mehr, da es funktionell mit Digikam oder Bibble nicht mehr mithalten kann. Für Bildkomposition werden Krita oder Pixel immer interessanter und haben Gimp in manchen Bereichen bereits überholt. Hier liegt der Einsatz bei mir bei ca. 50 Prozent.
Pixel (Image Editor) ist leider tot oder wird nicht wirklich aktiv weiterentwickelt. Das letzte "Lebenszeichen" von Kanzelsberger stammt von 2009.
Schade! Dafür hätte ich ein paar € ausgegeben.
Ich finde es hier ein bisschen degutant wie alle Leute, die den 1-Fenster-Modus gerne sehen würden, als Gelegenheits-Urlaubsfotobeschneider eingestuft werden (diese sind doch mit Digikam, F-Spot oder ImageMagick viel schneller bedient als mit Gimp). Ich finde Gimp in einem Fenster viel besser zu benutzen und habe Gimpbox, das Python Skript, dass Gimp in ein Fenster schmeißt, schon länger auf der 2.6-er Version. Ich finde es noch degutanter Menschen, die gewisse Features von Gimp wollten für die Entwicklungsarbeit von Gimp verantwortlich zu machen. Wenn es denn so buggy war, dann hätten die es doch ganz einfach lassen oder verschieben können. Wir haben uns schon länger mit Xnest, Xephyr oder eben Gimpbox zum 1-Fenster-Modus beholfen, da hätte man noch ruhig ein Paar Jahre warten können. Gimp ist Communityarbeit, aber keiner der Alle beisammen hat macht für mich Feature Foo wenn dies bedeutet, dass man Regressionen einführt.
Das wahre Problem bei Gimp war und bleibt die schwindende Entwicklerzahl. Also, lieber mitmachen oder spenden als trollend Annahmen über Benutzer des 1-Fenster-Modus zu machen.
degoutant != degutant
Gimp ist ein perfektes Beispiel dafür, wie man ein erfolgreiches Projekt durch Missmanagement und Ignoranz gegenüber den Usern und an die Wand fahren kann. Das muss man sich vorstellen: Das Projekt war nicht mal in der Lage in groben Zügen die eigene Strategie zu umreißen. Wie sollen da andere dran arbeiten, wenn nicht mal die Herren Gimp wissen, was sie vorhaben. Es ist außerdem bezeichnend, wenn die Entwickler nicht mal in der Lage sind ein paar Mentoren zu finden, damit andere für sie _bezahlt_ arbeiten. Dann brauchen sie sich aber nicht wundern, wenn keiner an ihrem Krempel mitarbeiten mag. Und jammern sollen sie denn erst recht nicht.
Das ist so nicht richtig, es gibt schon seit 2006 eine "product vision":
Ultimately, every decision taken by our UI team is about realising the product vision. At the LGM 2006, peter sikking held a workshop with the GIMP team, and helped them to formulated their product vision:
* GIMP is Free Software;
* GIMP is a high-end photo manipulation application and supports creating original art from images;
* GIMP is a high-end application for producing icons, graphical elements of web pages and art for user interface elements;
* GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;
* GIMP is user-configurable to automate repetitive tasks;
* GIMP is easily user-extendable, by ‘one-click’ installation of plug-ins.
Und anhand dieser "product vision" können neue Programmierer neue Funktionen einbauen? Da steht doch nichts konkretes drin, was irgendwie eine Richtung Gimp geben würde. Die von dir zittierte Stelle ist schlichtes Marketingsgeblubber, das nichts über die Zukunft aussagt.
Eben war deine kritik noch:
"Das Projekt war nicht mal in der Lage in groben Zügen die eigene Strategie zu umreißen."
Jetzt willst du eine Liste von Aufgaben für neue Programmierer. Die gibt es z.B. im Bugzilla, da werden einfache Aufgaben für neue Programmierer mit einem Kennzeichen versehen:
https://bugzilla.gnome.org/buglist.cgi?quicksearch=keywords%3Agnome-love+product%3A%22GIMP%22+
von daher ist es schön das man das mittlerweile erkannt hat
nur so kanns wieder aufwärts gehen mit Gimp
-der Mehrfenstermodus ist zumindest unter Windows eine Zumutung
-der Quellcode für professionelle Nutzung ("high" Farben, CMYK) existiert sogar schon in einer früheren Abspaltung
-warum müssen Betaversionen ein Zwangs Debug Fenster enthalten (das demonstriert schonmal die Denkweise)
lange Jahre weigerten sich die Programmierer das mal umzusetzen
für Einsteiger wäre auch ein paar einfache Werkzeuge sinnvoll wie zb einen Kreis zeichnen
anstatt "‘one-click’ installation of plug-ins. "
alles eigentlich einfache Sachen, welche die Nutzerbasis verbessern könnten
dann gäbs auch wieder mehr Entwickler
ansonsten beisst sich nur die Katze in den Schwanz
ich erwarte kein High End Plugin das bei Photoshop 500,-EUR kostet für lau
Matze
> -der Quellcode für professionelle Nutzung ("high" Farben, CMYK) existiert sogar schon in einer früheren Abspaltung
Jain. CMYK gab es bisher noch in keiner Abspaltung
16 Bit Farbtiefe gab es in FimGimp/Cinepaint, war aber ein übler Hack. Wie schlimm sieht man daran, des es das Projekt mittlerweile nicht mehr gibt.
> -warum müssen Betaversionen ein Zwangs Debug Fenster enthalten (das demonstriert schonmal die Denkweise)
Welche Denkweise? Beta-Versionen sind nicht fürs produktive arbeiten gedacht, sondern nur zum testen. Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
> lange Jahre weigerten sich die Programmierer das mal umzusetzen
Es gab keine Weigerung, viel mehr wird schon lange an einer ordentlichen 16 Bit Farbunterstützung gearbeitet. Allerdings soll es ja ordentlich werden und nicht wie bei Fimgimp sein. Und das Gimp Team ist auch schon seit langem ein sehr kleines Team, also dauert es.
> für Einsteiger wäre auch ein paar einfache Werkzeuge sinnvoll wie zb einen Kreis zeichnen
Gimp soll, wie du an der "product vision" oben siehst, nicht für Einsteiger sondern für Profis sein.
> alles eigentlich einfache Sachen, welche die Nutzerbasis verbessern könnten
> dann gäbs auch wieder mehr Entwickler
Das es einen Zusammenhang zwischen der Anzahl der Benutzer und der Anzahl der Entwickler gibt halte ich für eine gewagte These. Gimp für Windows wurde allein in diesem Jahr schon über 4 Millionen mal heruntergeladen, aber es gibt keinen einzigen aktiven Windowsentwickler für Gimp. Ab wie vielen Benutzern entsteht denn so ein Entwickler deiner Meinung nach?
Klar gab es die. Erstmals mit Gimp 2.0 (eine einfache). Mit Separate+ gab es auch ein auf liblcms basierendes Plugin, das per Default auch in Gimphoto zu finden ist.
Wie kommst du darauf? Die letzte stabile Version von Cinepaint ist jünger, als die von Gimp.> Klar gab es die.
Und wie hieß die? Hast du einen Namen oder einen Link?
> Erstmals mit Gimp 2.0 (eine einfache). Mit Separate+ gab es auch ein auf liblcms basierendes Plugin, das per Default auch in Gimphoto zu finden ist.
Wenn dir Separate+ reicht, dann nim doch das Plugin. Das gibt es ja schon länger für Gimp. Das ist aber nicht das was ich unter einer CMYK Unterstützung verstehe.
> Die letzte stabile Version von Cinepaint ist jünger, als die von Gimp.
Und wie kommst du da drauf? Die letzte Cinepaint Version ist laut http://sourceforge.net/projects/cinepaint/files/ vom 15.04.2008. Die letzte stabile Gimp Version (2.6.11) ist laut gimp.org vom 04.10.2010.
> Jain. CMYK gab es bisher noch in keiner Abspaltung
ok
zurückgezogen
>Welche Denkweise? Beta-Versionen sind nicht fürs produktive arbeiten gedacht, sondern nur zum testen. Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
log Datei ?
so machens jedenfalls 99% der anderen Programme
ich bin selber Programmierer, für mich zeigt sich da schon eine bestimmte Denkweise,
die auch andere kritisiert haben
>Es gab keine Weigerung, viel mehr wird schon lange an einer ordentlichen 16 Bit Farbunterstützung gearbeitet. Allerdings soll es ja ordentlich werden und nicht wie bei Fimgimp sein. Und das Gimp Team ist auch schon seit langem ein sehr kleines Team, also dauert es.
das las sich bei Cinepaint etwas anders
wie auch immer
schaun wir mal und sind optimistisch
> >Wie willst du ohne Debug-Fenster ordentliche Fehlerberichte schreiben?
> log Datei ?
OK, könnte man machen. Allerdings ist das Logfenster, was man bei der Entwicklerversion von Gimp sieht ja nichts extra programmiertes, sondern nur das was Windows öffnet, wenn man Debugnachichten nach stdout schreibt. Unter Linux werden die nur angezeigt, wenn man die Entwicklerversion aus einer Konsole heraus startet.
Also ehr ein Windows Problem. Und wie gesagt gibt es zur Zeit keinen aktiven Windows Entwickler. Also fällt es auch keinem auf.
> ich bin selber Programmierer, für mich zeigt sich da schon eine bestimmte Denkweise,
> die auch andere kritisiert haben
Welche Denkweise ist das denn nun, die das Zeigt?
ich weiss nicht genau wo du hinwillst
sicher kann man jeden einzelnen punkt sezieren und dafür begründungen finden
oder relativierungen
ich sags hier nochmal
ich mag gimp und benutze gimp und empfehle es weiter
deshalb sollte man doch trotzdem bestimmte sachen kritisieren können
deshalb bleibe ich auch dabei dass die probleme hausgemacht sind
aber ab nun wird ja alles besser
---------------------------------------
und zu der denkweise:
"ich bin der programmierer, fuck the rest"
oder zumindest "ich entscheide was für die anwender richtig ist"
die denkweise ist leider nicht so selten
zum teil möglicherweise richtig, aber nicht in der gesamtkonsequenz
> 16 Bit Farbtiefe gab es in FimGimp/Cinepaint, war aber ein übler Hack. Wie schlimm sieht man daran, des es das Projekt mittlerweile nicht mehr gibt.
Das ist gelogen.
Cinepaint gibt es nach wie vor noch.
Die Webseite www.cinepaint.org ist online und die Dateien gibt's bei sf.net zum Download.
Vielleicht mal Krita probieren. Krita ist zwar nicht direkt auf Fotobearbeitung spezialisiert, aber es könnte ja reichen. Dafür hat Krita eine Einfenster-Oberfläche, CMYK, bis zu 32-bit Farbtiefe und kein Debug-Fenster. Außerdem gibt es Werkzeuge für Rechtecke, Kreise usw.
danke für den Tip
Krita sieht tatsächlich ziemlich gut aus
meine Kritik sollte aber tatsächlich nicht bedeuten das ich Gimp nicht gut finde
Um ehrlich zu sein fühlt man sich etwas verschaukelt.
Vielleicht sollte man erstmal sehen, das man 2.8 über die Bühne bringt, auf die die Community sehnsüchtigst seit ewigen Zeiten wartet, bevor man sich Gedanken über 3.8 macht.
Aus meiner Sicht Utopie.
Sole Roadmaps sind ja nichts fixes. Aber es ist halt so was wie ein roter Faden.
Ich finde die Aussichten auf eine konsequente Weiterentwicklung von Gimp sehr erfreulich. Aus meiner Sicht ist Gimp ein sehr weit entwickeltes Werkzeug, bei dem ich mich über eine Weiterentwicklung in dem in der Roadmap angedeuteten Sinne außerordentlich freuen würde. Genau genommen gibt es kaum ein für Linux erhältliches Bildbearbeitungsprogramm, dass diese Möglichkeiten bietet, effektive Arbeit mit Ebenen und Masken. Krita habe ich schon vielfach probiert, komme aber nicht bisher noch nicht damit zurecht; vielleicht tut sich da ja auch noch was. Die Alternative zu Gimp, die ich derzeit - mangels 16-Bit-Unerstützung - nutze, ist das totgesagte Cinepaint, die Entwicklung mag hier stagnieren, aber das Programm ist brauchbar. Für mich brauchbarer als Photoshop, das sich für mich längst nicht so intuitiv bedienen lässt und sich abgesehen davon gegen Linux abschottet.
Was ich mir wünschen würde, wäre eine gezielte Spendenkampagne von Seiten der Gimp-Entwickler, aus der hervorgeht, dass die Entwicklung, wie in der Raoadmap angekündigt in einem überschaubaren Zeitraum auf die 3.0 zielt und die GEGL-16-Bit-Unterstützung einschließt. Dafür würde ich sofort spenden, denn was den Workflow betrifft finde ich Gimp mit Abstand das beste Programm für Linux. Mag der Code sein wie er will und wer es beurteilen kann - es funktioniert wahrlich gut und bietet auf der 8-Bit Ebene inclusive der Erweiterungen sehr ausgereifte Funktionen. Dafür und für die angekündigte Weiterentwicklung möchte ich den Entwicklern Dank sagen.
Du kannst wenn du möchtes jetzt schon spenden, mehr Infos findest du hier:
http://www.gimp.org/donating/
Ich habe vor ca. anderthalb Jahren gespendet, da seither die Entwicklung etwas stagnierte und ich zunehmend auf andere Programme ausgewichen bin, habe ich gezögert, werde es aber, wie gesagt erneut tun, sobald die Entwicklungsperspektive aus meiner Sicht noch etwas klarer wird.
Grüße
Woran lag es das du mit Krita nicht zurecht kamst?
Konkret bin ich mit dem Maskenwerkzeug nicht zurechtgekommen, dass heißt, ich habe es nicht geschafft, für eine Ebene eine Maske anzulegen und da hinein die Fotografie selbst als Maske zu kopieren, was bei Gimp überhaupt kein Problem ist. Ich habe auch keine Anleitung gefunden, wie ich so etwas mit Krita ausführen könnte, bin dann allerdings auch nicht in Foren gegangen, da ich auf Cinepaint ausweichen konnte und Krita bei mir auch etwas instabil operierte. Ich kam dann zu dem (vorläufigen) Schluss, dass Krita wohl mehr als Zeichenprogramm, denn als Fotobearbeitungsprogramm konzipiert wäre. (opensuse 11.3)
Die neuste Krita Version 2.3 ist wesentlich stabiler als die Version 2.1 die mit OpenSuse 11.3 kommt. Masken können über den Ebenen-Docker angelegt werden.
eine Maske anzulegen ist das eine, bisher ist mir noch nie gelungen, sie zu benutzen; d.h. konkret in die Maske eine Kopie des Bildes einzufügen, um damit z.B. nur die hellen Bereiche des Bildes zu nutzen.
Bin ab heute bis Ende nächster Woche ohne PC und Internet unterwegs, für einen Hinweis, ob und wie das mit Krita funktioniert, wäre ich aber sehr dankbar.
Grüße