最近のGIMPの開発MLを見てて気づいたんですけど、GIMPって完全な非破壊編集(non-destructive)なツールになることを目指してるっぽいです。
今はGIMPではGEGLというライブラリを使うように作り替える作業がされていますが、
GEGLさんには画像のドットを直接操作する機能がなさそうなのが前から気になっていました。
で、最近のメールでその方向性がはっきりしてきました。
たぶん、ブラシとかもストロークの履歴を取っておいて、それをレンダリングしていく感じになるんですね。
将来のGIMPでは画像のバッファを直接変更するような変更はできなくなるんでしょう。何を気にしているかというと、いろんな書き味を追加するお絵描きツールとして使えないものになるんじゃないの？っていうことが恐いのです。
ちゃんとキャッシュ管理さえすれば、そこそこ使いものになるはずなんですが、構造は複雑になるし、結構難しいんじゃないかなぁ？
とりあえず、混色ブラシとかの実装には問題なさそうですが、直接バッファをいじって高速化っていうことはできなくなりそうです。
こ、これはGEGLがすべての元凶ってこと？ うーん。。。
今はGIMPではGEGLというライブラリを使うように作り替える作業がされていますが、
GEGLさんには画像のドットを直接操作する機能がなさそうなのが前から気になっていました。
で、最近のメールでその方向性がはっきりしてきました。
たぶん、ブラシとかもストロークの履歴を取っておいて、それをレンダリングしていく感じになるんですね。
将来のGIMPでは画像のバッファを直接変更するような変更はできなくなるんでしょう。何を気にしているかというと、いろんな書き味を追加するお絵描きツールとして使えないものになるんじゃないの？っていうことが恐いのです。
ちゃんとキャッシュ管理さえすれば、そこそこ使いものになるはずなんですが、構造は複雑になるし、結構難しいんじゃないかなぁ？
とりあえず、混色ブラシとかの実装には問題なさそうですが、直接バッファをいじって高速化っていうことはできなくなりそうです。
こ、これはGEGLがすべての元凶ってこと？ うーん。。。
なんとなく、sigブランチのcustombrush相当のことをしたいと言っているような気がするのですが、ぜひAlexiaさんにはプロトタイプを作ってもらいたいところです。
私が心配なのは、ブラシツールがストローク単位で1つのGEGLオペレーションになってしまうことです。ストロークの圧縮などは簡単になりますが、機能が1個のBrushオペレーションで完結してしまうと、それに対してMixbrushのように他の機能を合成するようなことが難しくなるんじゃないかと心配してます。この辺はGIMPの開発者の様子を探りながら・・・という手探りのやりとりが必要そうです。
それが面倒なのでSPICE-and-WILMAに走った、という面もあります ;P
しばらくGIMPにコミットするつもりがないだけに、Alexiaさんには頑張ってほしいです。
http://www.nabble.com/Paint-core-beyond-2.6-tt17712721.html
この話題、盛り上がるのかどうか。
そろそろ後がない雰囲気になってきているだけに、今一度きちんと議論しスッキリした状態で「次」に進んでほしいものです。
#本当は開発者だけでなくユーザーも巻き込んでほしいんですがね……
>うまくメリットを活用できるようにデザインされていると思います。
そうですよね。
「調整レイヤーを作るつもりがない」っていうのがショッキングでした。
私もMLで処理をdestructiveとnon-destructiveに分けてほしいと言った(つもり)ですけど、返事がなくて残念です。
今でも、色での範囲選択や塗りつぶしの効率化なんてできるのかどうか不安です。データ量が膨大に増えるか、挙動が今までと変わるか、どちらかの問題は必ず起こると思うんですけど、どうするんでしょうね...
当時はマシンパワーの問題もあったので、同じようには語れないのですが、それでもピクセルを軽視するような設計になってしまうとユーザーの支持は得られないような気がしますね。
Photoshopはピクセル処理を基本としながらも、非破壊的処理をレイヤーの単位に封じ込めることでうまくメリットを活用できるようにデザインされていると思います。
GEGL/GIMPにもその辺のセンスというかバランス感覚を身に付けてもらいたいところです。
携帯から投稿するとなにかしら間違えますね...
その次のバージョンでごそっと入れ替えるんだと思います。
BablはGEGLBufferとお話できるようになっています。GEGLNodeはGEGLBufferに操作を行うのですが、結果として作成されるGEGLBufferをさわったり、結果だけを保存したり、アンドゥしたりするんだと方法がわかりません。
いずれにしても、コアの開発者がグラフベースを志向しているのでそうなっていくと思います。
従来のGIMPコアと連携したりとか…うーん
おいらの場合、GEGLはビルドの段階でこけました。
依存関係は全部満たしてるはずなんですが…はて。
個人的には早く16bit内部処理化してほしいのです。8bitでは限界があるし。
GEGLはbablをインストするとこまではしたんですが、そこから先は躊躇してしまいますね。結局悩んで削除して、また思い直して入れ直して、３回くらいインスト＆デリートしてます。もう一歩勇気が足りません。
GEGLベースのGIMPで今みたいな混色機能を実装するのはかなり大変になりそうです。というか、smudgeなんかどうやって実装するんだろう...
例えばレイヤーにjpg画像を読み込んだ後、画像を改変して保存する際、
>jpg画像自体は埋め込んだまま改変をせず、その画像に対する変更点・差分を記述することで
>再エンコードの必要が無くなったり元の画像の保全になったりするということでしょうか。
まさに今日「そのとおり」という回答が開発者MLでされました。
GEGLのgalleryを見ると雰囲気が分かると思います。
とりあえずXMLとして保存出来るのですが、自分の描いたストロークが全部テキストで保存されると考えただけでも凄いことになりそうです。
script-fu(とうかscheme)との相性はバッチリな感じですけど...
「非破壊編集」という言葉を適当に想像で補完してみたのですが、
例えばレイヤーにjpg画像を読み込んだ後、画像を改変して保存する際、
jpg画像自体は埋め込んだまま改変をせず、その画像に対する変更点・差分を記述することで
再エンコードの必要が無くなったり元の画像の保全になったりするということでしょうか。
そうなるとGEGLの処理に極めて依存した、孤立したファイルフォーマットになりませんかね。
GIMPと他ソフトとの連携可能性を著しく損ねるというか…
SVGの規格に徹底的に準拠しているInkscapeとは
事情が違ってくるのではないでしょうか…
GEGLのキャッシュ管理とラスタ画像のレンダリングがうまく共存できそうな気がしません。
とっても不安です。
遅いんですか... それまた残念です。
GEGL自身はすばらしいライブラリだと思うんで、
頑張って速くなって欲しいですね。
>>ひりたさん
ペイントとレタッチがうまく融合できる作りになってくれれば、GEGLを使っていろんな効果が簡単にいじれるようになるんでうれしいですね。
どこまでイラレ化が進むか分からないんですが、「Inkscapeとどう住み分けるか」みたいな議論がされていたのが気になる所です。
>>さくらいさん
GEGLベースでも作りようによってはちゃんとラスタ画像を編集出来そうです。作ったノードをこまめにレイヤ画像に描き出して消してあげればいいはずなので。
ただ、開発MLで「調整レイヤはいらなくなったので作らない」ってあったのが心配です。彼らが全部の編集操作を非破壊にすることを目論んでいるような気がしてなりません。
もっとも、そうすると今のドットをいじるプラグインが全滅なので、そうならないかもしれません。
とはいえ、例えそれでも複雑にははなりますね。
これなら確かに「GIMPでしか実現できない」、「かけがえのないGIMP」にはなりそうですが…
HDR画像を取り扱えるようになっても、その仕様ではレタッチ特化になってしまいそうな気がします。これも漠然とした不安でしかないので何とも言えませんが…
自分としては無から有を作り出すペイントツールとしてのGIMPのポテンシャルを保っていって欲しいです。
「重い」ということと「Macには入らないかも」
ということだそうで、断念しました。
GIMPの構造がかなり変わってくるように感じます。とりあえずソースを落としてきました。
（GEGLたん、厳しそうです）
ペイントツールみたいにがんがん塗り込んでいくと、どんどんとデータが増えていっちゃうので困りものです。
GEGLたん、やさしくお付き合いできるか心配です。
Gimp Enhancement Graphic Library だったか、E の部分がよくわかりません。違ってますか？
GEGL たん、まだ？