Ich hoffe mal, so kommt es einergermaßen hin: Mittels GEGL definierst Du einen gerichteten Graphen, also eine Abfolge von Operationen, die auf den Pixeln eines oder mehrerer Ausgangsbilder ausgeführt werden. Das kann etwas einfaches sein, wie z.B. an jeder Stelle das hellste Pixel aller beteiligten Bilder benutzen (entspricht in Gimp dem Layermode "Lighten Only" (ohne Berücksichtigung des Alphakanals und der Layermasken)) oder auch eine Faltungsmatrix zum Schärfen oder Weichzeichnen. GEGL führt dann diese Operation auf dem Bild/den Bildern oder einem Ausschnitt davon (für schnelle Vorschau) aus und verteilt die einzelnen Operationen möglichst effizient auf die Hardware. Moment schlägt sich Gimp mit den Pixeldaten selbst herum, in Zukunft wird das dann GEGL tun und die Filter und Plugins in Gimp definieren nur noch, _was_ gemacht werden soll und um das _wie genau_ kümmert sich GEGL. Dazu kommt noch BABL, dass die eigentlichen Pixel behandelt und sich um Dinge wie Farbräume und Profile kümmert. GEGL benutzt BABL für die eigentlichen Pixeldaten, macht aber Transparenz und Masken selbst.
Aber ich kann nicht an der Wurzel des Graphen, also am Ausgangsbild, Veränderungen vornehmen, die sich dann auf das Ergebnis auswirken, oder? Also z.B. Graustufen und Kontrastveränderung eines Portraits, und dann will ich aber noch die Pickel übertünchen, und zwar direkt auf dem Eingangsbild.
Die Idee von GEGL ist, das man das nicht mehr braucht sondern alle Änderungen am Bild intern als Graph abgebildet werden. Das kannst du dir dann so vorstellen wie das Graphen System von Blender:
Aber alles wie gesagt intern. In der Benutzeroberfläche wird man in Gimp erst mal davon direkt nichts sehen. Das ganze kann dann natürlich in ein beliebiges Bildformat exportiert werden.
Würde das bedeuten, dass man auch einzelne Verarbeitungsschritte wieder herausnehmen kann und somit sehen könnte, wie das Bild aussieht, wenn man beispielsweise nicht vor fünf weiteren Verarbeitungsschritten geschärft hätte? Das wäre natürlich ganz stark.
Von dankedankedanke am Mi, 30. November 2011 um 14:05 #
Für AMD hätte ich eine weitere, sehr gute Idee: Sofortiger Ausbau der fglrx-Treiberunterstützung auf Nvidia-Niveau, im Hinblick auf die Nvidia-Supportzeiten der Legacytreiber. Manch ältere Radeon-Grafikkarte wird nämlich unter GNU/Linux so gut von radeon unterstützt, dass man sie praktisch wegwerfen kann.
versteh nicht warum AMD noch so viel energie in den dämlichen binären Blob steckt, ich dachte eigentlich AMD hält den Blob nur noch aufrecht bis der freie Treiber besser ist, soweit ich gehört hab gibts gpu-beschleunigte freie Video-treiber von Intel, da ich nur auf einer Maschine spiele und sonst paar fps mehr oder weniger mich bei den meisten Rechnern nicht interessiert kann mich AMD bald mal dann steig ich zu Intel um.
Mag Amd eigentlich aber irgendwie fühl ich mich langsam verarscht, wenn ich auf meinem Zacate Netbook teilweise bestimmte 720p Filme nicht anschauen kann wenn die Bitrate zu hoch ist, und nein ich installier sicher nicht dieser instabile haufen Mist binären Treiber und mach mich von den Releasezyklen von amds treibern abhängig. Daneben trau ich keinem Konzern so viel das ich denen beliegen Code auf meiner Maschine ausführen lasse ohne das ich wenigstens theoretisch und andere 3. praktisch sich den Code anschauen können. Ich erinnere nur an den Sony Rootkit.
Ist GEGL für Gimp das, was für GEdit GtkSourceView ist? Kann mich da jemand aufklären?
Ich hoffe mal, so kommt es einergermaßen hin: Mittels GEGL definierst Du einen gerichteten Graphen, also eine Abfolge von Operationen, die auf den Pixeln eines oder mehrerer Ausgangsbilder ausgeführt werden. Das kann etwas einfaches sein, wie z.B. an jeder Stelle das hellste Pixel aller beteiligten Bilder benutzen (entspricht in Gimp dem Layermode "Lighten Only" (ohne Berücksichtigung des Alphakanals und der Layermasken)) oder auch eine Faltungsmatrix zum Schärfen oder Weichzeichnen. GEGL führt dann diese Operation auf dem Bild/den Bildern oder einem Ausschnitt davon (für schnelle Vorschau) aus und verteilt die einzelnen Operationen möglichst effizient auf die Hardware. Moment schlägt sich Gimp mit den Pixeldaten selbst herum, in Zukunft wird das dann GEGL tun und die Filter und Plugins in Gimp definieren nur noch, _was_ gemacht werden soll und um das _wie genau_ kümmert sich GEGL.
Dazu kommt noch BABL, dass die eigentlichen Pixel behandelt und sich um Dinge wie Farbräume und Profile kümmert. GEGL benutzt BABL für die eigentlichen Pixeldaten, macht aber Transparenz und Masken selbst.
Vielen Dank.
Ich wußte nicht, daß mein Nachbar von Nebenan Ahnung von Computern und Software hat.
Ich bin erstaunt!
Aber ich kann nicht an der Wurzel des Graphen, also am Ausgangsbild, Veränderungen vornehmen, die sich dann auf das Ergebnis auswirken, oder? Also z.B. Graustufen und Kontrastveränderung eines Portraits, und dann will ich aber noch die Pickel übertünchen, und zwar direkt auf dem Eingangsbild.
Die Idee von GEGL ist, das man das nicht mehr braucht sondern alle Änderungen am Bild intern als Graph abgebildet werden. Das kannst du dir dann so vorstellen wie das Graphen System von Blender:
http://www.blender.org/index.php?eID=tx_cms_showpic&file=uploads%2Fpics%2Fcompositingmetalflower.jpg&width=800m&height=600m&bodyTag=%3Cbody%20style%3D%22margin%3A0%3B%20background%3A%23fff%3B%22%3E&wrap=%3Ca%20href%3D%22javascript%3Aclose%28%29%3B%22%3E%20%7C%20%3C%2Fa%3E&md5=6f650d14971a4dd5a3dd3df43e265021
Aber alles wie gesagt intern. In der Benutzeroberfläche wird man in Gimp erst mal davon direkt nichts sehen.
Das ganze kann dann natürlich in ein beliebiges Bildformat exportiert werden.
Hatte PL nicht mal eine maximale Wortlänge um solche Mörderlinks zu unterbinden?
Nicht, wenn man a- oder br-Tags verwendet
Würde das bedeuten, dass man auch einzelne Verarbeitungsschritte wieder herausnehmen kann und somit sehen könnte, wie das Bild aussieht, wenn man beispielsweise nicht vor fünf weiteren Verarbeitungsschritten geschärft hätte?
Das wäre natürlich ganz stark.
Ja genau, das ist das Ziel. Aber leider ist das Gimp Team nicht all zu groß, so das die Hilfe von AMD wirklich gerne gesehen ist.
Danke AMD fuer diese Unterstuetzung.
Für AMD hätte ich eine weitere, sehr gute Idee:
Sofortiger Ausbau der fglrx-Treiberunterstützung auf Nvidia-Niveau, im Hinblick auf die Nvidia-Supportzeiten der Legacytreiber.
Manch ältere Radeon-Grafikkarte wird nämlich unter GNU/Linux so gut von radeon unterstützt, dass man sie praktisch wegwerfen kann.
AMD wird überhaupt nichts dagegen haben, wenn du deine alten Radeon-Grafikkarten entsorgst und neue kaufst.
versteh nicht warum AMD noch so viel energie in den dämlichen binären Blob steckt, ich dachte eigentlich AMD hält den Blob nur noch aufrecht bis der freie Treiber besser ist, soweit ich gehört hab gibts gpu-beschleunigte freie Video-treiber von Intel, da ich nur auf einer Maschine spiele und sonst paar fps mehr oder weniger mich bei den meisten Rechnern nicht interessiert kann mich AMD bald mal dann steig ich zu Intel um.
Mag Amd eigentlich aber irgendwie fühl ich mich langsam verarscht, wenn ich auf meinem Zacate Netbook teilweise bestimmte 720p Filme nicht anschauen kann wenn die Bitrate zu hoch ist, und nein ich installier sicher nicht dieser instabile haufen Mist binären Treiber und mach mich von den Releasezyklen von amds treibern abhängig. Daneben trau ich keinem Konzern so viel das ich denen beliegen Code auf meiner Maschine ausführen lasse ohne das ich wenigstens theoretisch und andere 3. praktisch sich den Code anschauen können. Ich erinnere nur an den Sony Rootkit.