mieki256's diary

G'MICには、画像スタック？ 画像リスト？ という、概念というか仕組み/機能があるらしい。複数の画像を保持しておくことができる機能。

要するにレイヤー、とは違うんだよな…。重なって表示されるわけではないし…。まあ、単に画像を複数持っておけますよ、それをスタックとかリストとか呼んでますよ、ということらしい。

• それぞれの画像にアクセスする時は [0] とか [1] とかつけるらしい。
• [-1] とつけると、スタック内の一番最後の画像、という指定になる。
• [0-50%] とつけると、0番目の画像から、スタックの真ん中あたりの画像までを指定していることになる。「-」を記述すると、ここからここまで、という指定になるっぽい。
• [0--1] とつけると…。分かりづらいけど、「0」「-」「-1」を指定している。0番目の画像から、一番最後の画像まで、つまりは全画像を指定してることになる。
• [0--1:2] とつけると、値の増え方を2ずつにする、という指定になる。[0] [2] [4] [6] ... を指定していることになる。

split x や split y というコマンドを見かけて、「一体コレは何だろう？」と疑問に思っていたけれど、画像を分割して画像スタックに入れるコマンドだったらしい。

• split x を使うと、画像がx方向に分割されて、1 x h ドット、w個の画像が、画像スタックに入る。例えば 512x512ドットの画像に対して split x を指定すると、1 x 512 ドットの画像が512個作られる。
• split y なら、y方向に分割されて、w x 1 ドット、h個の画像になる。512 x 512ドットの画像なら、512 x 1ドットの画像が512個作られる。

そのままだと元画像(画像スタック[0])に反映されない。append x や append y を使って結合する。

• append x なら、画像リストの全ての画像を x 方向に結合して1枚の画像にする。
• append y なら、画像リストの全ての画像を y 方向で結合して1枚の画像にする。

そういうコマンドが使えるなら…。1ラインごとに分割して横方向の表示位置を変えたらラスタースクロールっぽい見た目になるんじゃね？

試してみた。

to_rgba      # RGB画像をRGBA画像にする
split y      # y方向で分割。w x 1ドットの画像が h 個作られる。

repeat $!    # ループ開始。$! は、画像リストの個数を示す

  # shiftコマンドで表示位置をずらす。
  # $> は、ループ時のインデックス値。for (i=0; i<h; i++) { } で言うところの i に相当。
  # sin() で sin値が得られる。ラジアン値を与える。角度 * pi / 180 でラジアン値になる。
  # shift x,y,z,c,境界処理,補間処理
  
  shift[$>] {36*sin(3*$>*pi/180)},0,0,0,0,1
  
done         # ループ終了

append y     # 画像リスト内の全画像をy方向に結合

$!、$>、shift については以下で説明されてる。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Substitution Rules
_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - shift

動かしてみたら、期待通りの結果になった。

G'MICのコマンド一覧を眺めていたら、random_pattern というコマンドが目に入った。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - random_pattern

なんだこれは！ ちょっと面白そう…。

Various → Custom Code (Full)、で試してみたけど…。

random_pattern {w},{h},2

プレビュー画面では何の変化もない…。

「Display Debug Info on Preview」にチェックを入れたら原因が分かった。新しい画像として作られて、画像スタックに入るのね…。そのままだと元画像に影響を与えないらしい。



元画像と合成しないといけない。合成には、blend というコマンドが使えるらしい。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - blend

「blend 合成モード,Opacity」を記述すれば合成される。この記述の仕方だと、画像スタックの全画像を合成する状態になるのかな。

合成モードは…。色々あり過ぎて何が何だか…。

ひとまず試してみた。

repeat 3                    # ループ開始
  random_pattern {w},{h},2  # ランダムパターン画像を作成
  to_rgba[-1]               # RGB画像をRGBA画像に変換。[-1]を指定しているのでストックの最後の画像に対して処理をする
  blend alpha,0.3           # 合成。alphaはアルファチャンネルに基づく合成だが、Opacityが0.3なのでうっすらと合成される
done

たしかに、元画像に対して合成できた。

線を引きたい。lineコマンド、もしくは line_aaコマンドが使えるっぽい。

以下で、512本のランダムな線を、ランダムな色で描画する。

repeat 512
  line_aa {u(w)},{u(h)},{u(w)},{u(h)},1.0,${-rgb},255
done

line_aa はアンチエイリアス付きで線を描画する、と書いてあるように見える。ということは、line はアンチエイリアス無しのギザギザした線なのだろう…。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - line
_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - line_aa

u() は疑似乱数を返す関数(?)だけど、u(w) と書けば、(0 - 画像横幅)の範囲の乱数を返す。そのままだとコマンドに渡せないので、{ } で囲んで「ここは計算式だよ」と指定してやる。結果、{u(w)} と書くことになる。

同様に、{u(h)} は、(0 - 画像縦幅)の範囲の乱数を返す。

${-rgb} なる記述をどこかで見かけて、一体何を指定しているのか謎だったけど…。「-」はコマンドの前につける記号で、rgbというコマンドを呼び出していただけらしい。つまり、${-rgb} でランダムなRGB値を返してくれる。${-rgba} なら、ランダムなRGBA値を返してくれる。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - rgb
_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - rgba

一番最後につけている 255 は、アルファチャンネルの値。

G'MIC で画像を新規作成する際の記述がよく分からない…。

とりあえず、width(幅), height(高さ), depth(スライス数), spectrum(チャンネル数) を列挙すれば、画像スタックに新しい画像が作成されると分かった。

以下の事例では、RGB画像(チャンネル数=3)、RGBA画像(チャンネル数=4)を作成できる。幅と高さには100%等のパーセント指定も使える模様。100%なら、既に入力済みの画像の幅と高さを指定しているのと同じになる。

100%,100%,1,3
100%,100%,1,4

Various → Custom Code、で、Desplay Debug Info on Preview にチェックを入れた状態で上の記述を実行すれば、画像スタックに新しい空の画像が作成されていることが分かる。

どうやら G'MIC は、数値から始まる指定を新規画像作成として解釈するっぽい。もしかすると数値の前に、入力画像を指定するコマンド = input が暗黙的に指定されてるものと解釈してるのかもしれないけれど…。

それはさておき。こういった指定の後に、数式を記述することで画像内の初期化ができるらしくて…。そこをどう書けばいいのかが分からない…。

例えば以下を記述するとチェック模様が作れるのだけど…。

100%,100%,1,4,"xor(x,y) % 64 < 32 ? [ 255,0,0,255 ] : [ 255,255,255,255 ]"

ん？ もしかして…。これならどうだ。

100%,100%,1,4,[255,0,0,255]

真っ赤な画像が作成された。つまり、[R,G,B,A] を書いておけばその色で初期化されるようだな…。

ちなみに以下のページで、新しい画像を作成しつつ、チェック模様にしたり、グラデーションをつけたりする事例が提示されてる。数式を指定することで比較的複雑(?)な初期化もできる模様。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing

100%,100%,1,3,"xor(x,y) % 64 < 32 ? [ 255,0,0 ] : [ 255,255,255 ]"
100%,100%,1,3,"lerp([ 32,128,99 ],[ 0,0,16 ],y/(h-1))"

余談。上記のページは背景の指定が何かおかしいようで、テキストが読みづらい…。背景を削除する以下のブックマークレットを用意してどうにか読んだ。

javascript:(function(){document.body.style.backgroundImage='none';document.body.style.backgroundColor='#ffffff';})();

単に画像全体を特定の色で塗り潰したいなら fill_color が使える。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - fill_color

fill_color 0,0,255,255   # 青色で塗り潰す。おそらく画像スタックの全画像を塗り潰す

100%,100%,1,4                 # 新規画像を作成
fill_color[-1] 255,0,255,255  # 新規画像([-1])を紫で塗り潰す

fill というコマンドもあるのだけど、どうやらそれは各ピクセルの内容をずらずらと列挙することでその内容を書き込んでいくコマンドのようだった。これも数式を書くことで複雑な図形を描くことができるっぽい。数学が得意な人なら凝ったことができるのだろうな…。

_fill (f)
_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - fill

G'MICで配列を使いたい。使えるのかな？

動的配列というものが用意されているらしい。画像スタック内の画像データの1つを、値を格納する領域として利用して、追加や削除をすると画像サイズが自動で変化するそうで…。

「画像を配列として使うんかーい」と最初は驚いたけど、考えてみたら画像データって配列みたいなものだし…。メモリ領域を確保して値を格納したり取り出したりできれば何を使ってもいいんだよな…。コンピュータにとっては何であろうとメモリにアクセスしてることに違いはなく、人間がその領域を画像だの配列だの呼び分けているだけだわな…。

以下のコマンドがあるっぽい。他にも色々あるっぽいけどよく分かってない。

da_size() : 動的配列の個数を取得
da_push() : 動的配列の末尾に値を追加。動的配列のサイズは自動で増える。
da_pop() : 動的配列の末尾から値を取り出す。動的配列の中から値は消える。
da_insert() : 動的配列に値を追加する。インデックス値を指定して、その場所に追加できる模様。
da_freeze() : 動的配列用画像のサイズと、動的配列の個数を一致させる？

ドキュメントの、「Dynamic arrays:」の項目に説明が書いてある。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Mathematical Expressions


とりあえず、何かしらのサンプルを書いて動作確認してみる。

ランダムな座標を一旦動的配列に格納して、後で動的配列から座標値を得てその位置に円を描画する処理を書いてみた。単にこういう処理をしたければループを回して即座に描画してしまえばいいけれど、今回は動的配列の使い方を把握するためにわざと回りくどいことをしている。

Various → Custom Code、にコピペして、Desplay Debug Info on Preview をOn/Offすれば、画像の中に値が格納されてる様子もなんとなく分かるかなと…。

1,1,1,3,0 => darray  # 動的配列用の画像(RGB)を作成。名前を darray にする。「=>」は「name.」と同じ意味

# 乱数で座標を生成。動的配列の末尾に da_push() で追加して記憶しておく
repeat 8
  rx={u(w#0)}    # 入力画像(#0)の幅/高さの範囲で乱数を得る
  ry={u(h#0)}
  eval "da_push(#$darray,[$rx, $ry, 0])"   # 動的配列に追加
  circle[0] $rx,$ry,18,1.0,255,0,0,255     # 位置を確認するために赤い円を描画。circle x,y,R,Opacity,R,G,B,A
done

# 動的配列を参照して描画
num=da_size(#$darray)   # 配列数を取得
repeat $num
  x,y,r={da_pop(#$darray)}      # 配列の末尾から座標を取り出す
  circle[0] $x,$y,14,1.0,255,255,255,255  # 白い円を描画
done

# rm[$darray]   # 動的配列用の画像を削除

注意点その1。どうも現状では、動的配列用の画像として、RGB画像、もしくは、RGBA画像を用意しないと値を格納できない気配がする…。

当初、画像を用意する際に 1,1,1,2 と記述して、チャンネル数=2 の画像を作成して値を格納しようとしたのだけど、どんな書き方をしてもエラーしか出なくて…。試しに 1,1,1,3 と記述してRGB画像にして、[x, y, ダミー値] を記録するようにしたら、ようやくエラーが出ない状態になった。

注意点その2。動的配列関連のコマンド、da_*() は、eval " - " の中に入れないと動かない時がある。しかし、eval " - " の中に入れなくても動く時もある。条件がよく分からない…。

eval " - " というのは、「この中は数式モードで記述してありますよ」的コマンドだろうか？ 通常時とはちょっと違う書き方ができるらしい。スペースを入れてもエラーが出なかったり、「;」で行の最後を示したりする。

注意点その3。動的配列用の画像の高さと、動的配列の個数は一致しない。画像の高さのほうがちょっと大きくなる。

当初、一致しないものだから何か間違えてるのかと悩んでしまった…。一致しないのがフツーらしい。もし、一致させたい時は、 da_freeze() を使えば一致させることができる。ただ、これを使うと今度は配列個数を取得できる da_size() がエラーになる…。何故？ もっとも、da_freeze() を使えば、動的配列個数＝画像の高さになるので、それはそれで困らないのかな…。

その他の細かいところとしては…。

• 「name. 名前」と書くと、その画像に名前をつけて管理できるけれど、「=> 名前」と書くことでも同じ意味になるらしい。「name.」の最後の「.」は、画像スタックの一番最後の画像を指定しているらしい？
• 入力画像(#0)の幅と高さを取得したい時は、「w#0」「h#0」と書ける。「#0」が画像スタックの一番最初の画像を指定しているらしい。
• 動的配列関連のコマンド、da_push()等を利用する時は、画像スタックのインデックス値を指定するらしいけど、「#1」とか「#2」と記述できる。名前で指定する時は「#$名前」で通るっぽい？

ちょっと分からないのが、「#$darray」と書いても「$#darray」と書いてもエラーが出ないまま通る時がある…。もしかしたらこの記述はおかしいのだろうか…。

  x,y,r={da_pop(#$darray)}      # 配列の末尾から座標を取り出す

  ↑ ↓ どっちもエラーが出ない…

  x,y,r={da_pop($#darray)}      # 配列の末尾から座標を取り出す

ちょっと分かってきた。通常モードと数式モードで違うっぽい？ 通常モードなら $darray と書くだけでOKっぽい。数式モードでは #$darray と書かないとエラーになる。

昨日は push と pop で値を記録したり取り出したりしてたけど、動的配列のインデックス値を指定して値を取得できるか試してみた。

以下は2つの値を記録して参照する例。

1,1,1,3,0   # 画像スタックに、動的配列用の新しい画像(#1)を作成
repeat 4
  rx={u(w#0)}     # ランダムな座標値を取得
  ry={u(h#0)}
  eval "da_push(#1, [$rx, $ry, 0])"     # da_push() でランダムな座標値を動的配列に記録
  circle[0] $rx,$ry,16,1.0,255,0,0,255  # 赤い円を描画
done

repeat {da_size(#1)}
  x,y,r={I[#1,$>]}                       # 動的配列から値を取得。値が複数ある場合は I[] を使う
  circle[0] $x,$y,8,1.0,255,255,255,255  # 白い円を描画
done

• 複数の値が記録されている場合(二次元配列？)、 `I[ ]` で値を取得できる。
• 値が1つしか記録されてない場合(一次元配列？)、 `i[ ] ` で値を取得できる。

以下は1つの値を記録して参照する例。一次元配列というか…。

1,1,1,1,0      # 動的配列用の画像を作成。チャンネル数に1を指定しているので値は1つしか入らない
repeat 8
  rx={u(w#0)}
  eval "da_push(#1, $rx);"              # 値を1つだけ記録
  circle[0] $rx,50%,16,1.0,255,0,0,255
done

repeat {da_size(#1)}
  x={i[#1,$>]}                            # 値を1つだけ読みだす
  circle[0] $x,50%,8,1.0,255,255,255,255 
done

「#1」は画像番号を指定しているけれど、名前で管理することもできる。

1,1,1,4,0 => dary
repeat 16
  rx={u(w#0)}
  ry={u(h#0)}
  eval "da_push(#$dary, [$rx,$ry,0,0]);"
  circle[0] $rx,$ry,16,1.0,255,0,0,255
done

repeat {da_size(#1)}
  x,y,nn,mm={I[#$dary,$>]}
  circle[0] $x,$y,8,1.0,255,255,255,255 
done

G'MICのスクリプトを勉強していて、変数の代入時と参照時で書き方が変わるのがなんだかアレだなと思えてきた。代入時は x={w} といった感じで変数名だけを書くのに、参照時は circle $x,$y,16 のように $ をつけなきゃいけない。なんだこの糞仕様。一体何の言語を踏襲してこうなったんだ？

そう思ってAI(Google Gemini)に尋ねてみたら、「アレは参照じゃなくて置換なんスよ」「シェルスクリプトも置換時は $ つけるじゃないスか」と言われて腑に落ちた。たしかに Linux のシェルスクリプトも、代入時は変数名だけを書くけれど、参照、というか置換時は $ をつける…。

export PATH="$PATH:~/bin"

つまり G'MICのスクリプトって、プログラミング言語というよりシェルスクリプトに近い仕様なのね…。何にせよ、変数の代入時と参照時(置換時)で書き方が変わると覚えておかないと…。

にしても分かりづらい…。どこかの時点で Lua でも内蔵しちゃったほうが良かったんじゃないのか…。いや、でも、利用できるスクリプト/言語が複数あるとサポートが面倒臭くなるか…。G'MICスクリプトとLuaスクリプトが混在してる user.gmic なんて想像しただけで気持ち悪そうでもあるし…。

Lua と言えば、LuaからG'MICを呼び出して使えるモジュールが存在するっぽい。

_lua_module-gmic | Lua module written in C for interfacing with libgmic, an open-source framework for image processing
_mrharmonies/lua_module-gmic: Lua module written in C for interfacing with libgmic, an open-source framework for image processing


Python から G'MIC を呼び出して使えるモジュールもあるのだけど、Linux上でしか使えないという話をどこかで目にしたような記憶が…。

_gmic - PyPI
_GreycLab/gmic-py: Python binding for the G'MIC Image Processing Framework


Ruby から G'MIC を呼び出してる事例も見かけた。G'MIC CLI を呼び出せば使える、ということかな…。

_Ruby から system 関数を用いて GMIC を呼び出す

入力画像([0] と指定)を何枚か複製して画像ストックに入れたい。どう記述すればいいのだろう？

色々な書き方ができそう。

# ループを回して複製。[0] を新規の入力画像として指定する
cnt=3
repeat $cnt
  input [0]
done

# input は省略することができる
cnt=3
repeat $cnt
  [0]
done

# 画像スタックの最後の画像 [-1] を指定しても良さそう
cnt=3
repeat $cnt
  [-1]
done

# [-1] は「.」というショートカットがある
cnt=3
repeat $cnt
  .
done

# そもそも「x」を使えば指定した数だけ複製できる
cnt=3
[0]x{$cnt}

# [-1] のショートカット「.」でもいい
cnt=3
.x{$cnt}

一番最後はめっちゃ短くなったけど…。こんなのが書かれていても何をやってるのか分からないよなあ…。

画像スタックの一番最後、あるいは最後から2番目、3番目の画像を指定する時は、[-1] や [-2] や [-3] と指定する。この、 [-1]、[-2]、[-3] には、省略形として「.」「..」「...」が割り当てられている。

_Command Decorations


この仕様について、ちょっともやもやと考えてしまった。

この省略形について知った時、「.」とか「..」なんてのがスクリプトソースの中にいきなり出てきても初見じゃさっぱり意味不明じゃんよこんなのわかるわけねえと若干憤慨(?)してしまったものの、考えてみたらLinuxにしろWindowsにしろカレントディレクトリは「./」「.\」、親ディレクトリは「../」「..\」と示すわけで、それらを導入してこうなったのでは？ と思えてきた。

また、「画像スタックの一番最後の画像がカレント画像 ―― 処理対象画像として扱われる場面が多いよね？ だから特別にこういうショートカットを用意してみたよ」ということでもあるのだろう…。

しかし…。こんな記述を導入してたら一気にソースが難解になるよなあ…。そうまでして打鍵数/文字数を減らしたいんかい…。結果、何をやろうとしてるのかよく分からんスクリプトだらけになるし、今後各スクリプトをメンテナンスしていく際の負担も増大する。何より、パッと見て「これならなんとなく分かりそう」と思わせることができない記述ばかりでは、初心者(?)に対して一見さんお断り状態になってツールの普及も全然進まないだろう…。

とは言え、「じゃあカレント画像を指定する際の適切な省略形として一体何がいいのですか？」と問われたらかなり悩んでしまう。やはり何かの記号で表現したくなりそうだけど、すると途端に分かりづらくなる…。そう考えると、「ディレクトリの相対パス指定と同じです」と言える「.」「..」は分かりやすいほうでは？ とすら思えてくる…。

プログラミング言語/スクリプトの仕様を考えるのって難しいものだなと。だからこれだけ色んな言語が溢れかえっているのだろうけど。

何にせよ、G'MICスクリプトってなんだかあちこち分かりづらい…。TyepScriptからJavaScriptに変換、みたいなノリで、一旦分かりやすい言語で書いてからG'MICスクリプトに変換できないものかな…。

GIMP + G'MIC-Qtプラグインを使って、入力画像(入力レイヤー)を指定回数回転させたい。

何百種類もフィルタを持っている G'MIC のことだから、既にこういう処理をするフィルタもありそうだけど、G'MICでフィルタを作成する際の練習問題にはなるんじゃないかなあと…。以前 GIMP + Python-Fu で似た処理をするプラグインを書いたけれど、G'MIC でも同じことができるかどうかも気になるし…。

_mieki256 wiki - GIMPの全レイヤーを円状に配置するスクリプト

G'MICなら、こんな感じかなあ…。

cnt=6         # 回数を指定
[0]x{$cnt-1}  # 入力画像をn枚複製

ang={360/$cnt}   # 角度の増分を得る
repeat $!        # 画像スタック数分ループ。画像スタック数は $! で、ループインデックス値は $> で得られる
  if $>!=0
    rotate[$>] {$ang*$>},1,0,50%,50%  # 画像の中心を軸として回転
  fi
done

blend alpha  # 画像スタック全部をアルファチャンネルで合成

注意点。アルファチャンネルを使って合成してるので、RGBA画像/アルファチャンネルを持っているレイヤーを入力画像にしないと期待した結果が得られない。


G'MIC-Qtプラグインに登録するならこんな感じになるだろうか。

• Windows環境の場合、C:\Users\(ユーザ名)\user.gmic に追記すれば使えるようになる。
• あるいは G'MIC-Qtプラグインの Settings で *.gmic を追加する。
• My Filters → m256 multiple rotations を選べば利用できる。

_fx_m256_multiple_rotations.gmic

#----------------------------------------
# m256 multiple rotations
# Author : mieki256 , 2026/04/07, License : CC0
 
#@gmic
#@gui ____<b>My Filters</b>

#@gmic fx_m256_multiple_rotations : Count, Interpolation, Boundary_conditions
#@gmic : Multiple rotations. Only RGBA images are supported.

#@gui m256 multiple rotations : fx_m256_multiple_rotations, fx_m256_multiple_rotations_preview(0)
#@gui : note = note("Multiple rotations. Only RGBA images are supported.")
#@gui : sep = separator()
#@gui : Count = int(6, 2, 256)
#@gui : Interpolation = choice(1, "None", "Linear", "Bicubic")
#@gui : Boundary conditions = choice(0, "Dirichlet", "Neumann", "Periodic", "Mirror")
#@gui : sep = separator()
#@gui : note = note("Authors : mieki256 , Latest update: 2026/04/06")

fx_m256_multiple_rotations :
  [0]x{$1-1}     # copying input image
  ang={360/$1}
  repeat $!
    if $>!=0
      rotate[$>] {$ang*$>},$2,$3,{w#0/2},{h#0/2}
    fi
  done
  blend alpha

fx_m256_multiple_rotations_preview :
  fx_m256_multiple_rotations $*

以下のページでは G'MIC で作成された色々なアニメーションが紹介されてる。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Gallery

ページ内の「Source code」と書かれたリンクをクリックすると、スクリプトソースを閲覧できるけれど、その中で animate というコマンドを使う旨が書かれてる。

# Entry point when run from CLI:
go =>[^] Distortion e[] "" animate 50

名前からしてそれっぽいし、G'MIC でアニメーションを作る際は animate コマンドを使うのかな…？ ちなみに、その認識は間違いだと後で分かった…。


animateコマンドのドキュメントは以下。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - animate

以下の引数を取ると書いてある。

## Arguments:

- filter_name,"param1_start,...,paramN_start","param1_end,...,paramN_end",nb_frames>=0,_output_frames={ 0:No | 1:Yes },_output_filename- delay>0,_back and forth={ 0:No | 1:Yes }

delayの指定は、G'MICで画像ウインドウ表示をした際の、表示のdelay値だろうけど…。これって連番画像として保存したりはできないのだろうか？

フィルタ名とパラメータを指定した後、nb_frames なるものを指定するらしいけど、この値もよく分からない…。前述のドキュメントには以下の使用事例があったので手元で試してみたけれど…。

gmic.exe image.jpg animate flower,"0,3","20,8",9

G'MIC CLIが画像ウインドウを表示して、そこでは #0 から #19 まで、画像が20枚作成されていた。おかしい。nb_frames で 9 を指定したから9枚作成されるのかなと思ったのに…予想が外れた。すると、この 9 の指定は一体何なんだろう？ 生成フレーム数を指定してるわけではない…？

その上、手元で生成した結果画像は、ドキュメントで紹介されてる画像とは見た目が全然違っていた。何故。

animateコマンドの仕様…よく分からないな…。

その後色々試していたら、そもそも animate コマンドを使わなくても連番画像を保存できると分かった。

前述のギャラリーページから、distortion.gmic をコピペで作成して以下を打ってみた。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Gallery

gmic.exe distortion.gmic go output frame.png

連番画像 frame_000000.png - frame_000049.png が保存された。指定した出力ファイル名に、「_」 + 6桁の数字が自動で追加されて、連番画像ファイルになっている。

つまり、outputを指定することで、画像スタック(画像リスト)の中に入ってる全画像が保存されるのだろう…。たぶん。

• 画像スタック数が1個の場合、frame.png が保存される。
• 画像スタック数が2個以上の場合、frame_000000.png, frame_000001.png ... といった感じで、自動で連番画像として保存してくれる。

すると、animateコマンドって一体何なのか？

おそらくだけど、G'MIC CLI によって表示された画像ウインドウ上で、画像スタックを自動で次々に表示してアニメーションとして見せる際のディレイ値を指定するだけのコマンド、なのかもしれない。ドキュメントにも「in a display window.」と書いてあるし…。

そして、現状のG'MICの実装状態と、animateコマンドのドキュメント内容は合ってないのではないかな…。ドキュメントに書いてある例を試しても同じ結果が出てこないし…。

まあ、何にせよ、animateコマンドは無理して使わなくてもいいらしい。使わなくてもアニメーションを保存することができる。


テストスクリプトを書いて実験してみた。少しずつぼかしを強くするスクリプトを、blur_anime.gmic として保存。

_blur_anime.gmic

go :
  resize[0] 360,240,1,3,6,0
  nbf=48
  repeat $nbf
    echo[] "> Frame "{$>+1}/$nbf
    +fx_blur_gaussian[0] {$>*0.25},0,0,1,7,2
  done
  remove[0]

• resize[0] で、入力画像をリサイズ(拡大縮小)できる。resize 幅,高さ,デプス数,チャンネル数,補間方式,境界処理、を指定できる。
• echo は、G'MIC CLI で動かした際にコンソールにメッセージを表示するためのコマンド。ここでは現在処理中のフレーム番号をメッセージ表示している。
• echo[] で、どの画像も対象にしないで処理をする指定になるらしい。メッセージを表示するだけだから、どれかしらの画像を対象にしつつ処理されてしまうと困るのだろう…。
• fx_blur_gaussian はガウシアンぼかしを行うコマンド。
• fx_blur_gaussian[0] で、[0] = 入力画像に対して処理をしろという指定になる。
• 行頭に「+」がついているのは、新しい画像を作成して画像スタックに入れろ、という指定。何もついてないか「-」がついていると入力画像([0])自体が処理後の画像で上書きされるけれど、この場合「+」がついているので、入力画像はそのまま残して、処理後の画像が画像スタックに追加されていく。
• remove[0]で入力画像を画像スタックから削除している。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - resize

ffmpeg が利用できる環境なら、以下の指定で mp4 として保存することができる。

gmic.exe blur_anime.gmic sample bottles go output out.mp4,24,YV12

上記は以下を指定している。

1. スクリプト blur_anime.gmic を読み込んで、カスタムコマンド go を定義してから、
2. サンプル画像 bottles を入力画像として読み込み、
3. カスタムコマンド go を呼んで処理をして、
4. 画像スタックの全画像を使って mp4 を作成する。

出力ファイル名 out.mp4 の後ろになんか色々つけてあるけれど…。「mp4ファイル名,フレームレート,Videoフォーマット(Codec？)」といった指定ができるらしい。

VideoフォーマットにはYV12を指定しておいたほうが無難。YV12 は、YUV 4:2:0 Planar の指定。これを指定しないとWebブラウザ等で再生できないはず。

_fourcc: YV12


もし、動画ファイルではなく、連番画像を保存するなら以下のように指定する。

gmic blur_anime.gmic sample bottles go output frame.png

frame_000000.png, frame_000001.png, frame_000002.png ... といったファイル名で保存される。


余談。ffmpeg を使って連番画像を mp4 にするなら以下。

ffmpeg -framerate 24 -i frame_%06d.png -vcodec libx264 -pix_fmt yuv420p -r 24 out.mp4

結果として以下のようなmp4動画が作成された。




これでたしかに、G'MICを使ってアニメーションを作成可能と分かった。

_How to export animation via gmic cli [SOLVED] - Software / G'MIC - discuss.pixls.us
_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Input/Output Properties

ダイソーの店頭で売っていたレインコートの中にはサイズ的に良さそうなものがあったけど、残念なことに色が黒で…。俺に忍者になれというのか？

こんな色のレインコートを着て、雨が降ってる夜にそのへん歩いてたら、さあ私を車で轢き殺してくださいとお願いしているようなものではないか…。田舎は夜間の照明が少ないので車のヘッドライトで照らされた一瞬しか歩行者の姿が見えないわけだけど、そんな光量の乏しい状況で黒い服を着てウロウロしてたらドライバーだって困る…。

どうしてどの店も、周囲から発見しづらくなる忍者装束的雨合羽＝黒系の商品ばかり売ろうとするのか…。命に関わるやろ…。

go :
  nbf=120                          # フレーム数
  repeat $nbf
    echo[] " > Frame "{$>+1}/$nbf  # コンソールにメッセージ表示
    input 512,512,1,3,0            # 512x512の画像を新規作成。画像ストックに追加
    fx_spline_spirograph[-1] 0,0,50,200,74,6,50,{$>*0.5},8,0,0,50,50,1   # フィルタ処理
    # resize[-1] 256,256,1,3,6,0   # 場合によっては256x256にリサイズ
  done

gmic.exe spline_spirograph.gmic go output frame.png

ffmpeg -y -framerate 24 -i frame_%06d.png -vcodec libx264 -pix_fmt yuv420p -r 24 -crf 16 -preset veryslow out.mp4

フィルタに与えるパラメータ記述は、G'MIC-Qtスタンドアロン版や、GIMP + G'MIC-Qtプラグインで取得することができる。

GUIでフィルタのパラメータを調整後、上のほうにある「コピー」ボタンをクリックすると、フィルタに与えるべきパラメータを列挙したテキストがクリップボードにコピーされる。これをテキストエディタ等に貼り付けて調整していけばいい。

ダイソーメガステージ須賀川店まで自転車で行ってミニデジタル時計が無いか探してみたけど、やはり売ってなかった。入手不可っぽいなあ…。

色が変わると謳う商品は置いてあったけど、奥行きがあり過ぎる。ザ・目覚まし時計風デザインの商品もあったけど、表示部分が丸いので見辛いのではなかろうか。

G'MIC CLI が必要になる。G'MICの公式サイトからダウンロードする。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Download

「G'MIC for Windows - Other interfaces」の「Command-line interface (CLI):」のところから、gmic_3.7.4_cli_win64.zip を入手して解凍。任意の場所に置く。


G’MIC Animator Tool を入手。

_Releases - ThioJoe/Gmic-Animation-Tools

GmicAnimator.exe と DrosteGUIExpandedRange.gmic を入手して、G'MIC CLI の保存場所にコピーする。


GIFアニメを作りたい場合は、ffmpeg も必要になるらしい。

_Builds - CODEX FFMPEG @ gyan.dev

ffmpeg-8.1-full_build.7z を入手して解凍。bin/ 以下の ffmpeg.exe、ffplay.exe、ffprobe.exe をパスの通ったところに置く。


G’MIC Animator Tool に指定するパラメータの値を確認したい時は、G'MIC-Qt stand-alone interface があると便利かもしれない。あるいは、GIMP を使っているなら GIMP用の G'MIC-Qtプラグインを使ってもいい。G'MIC の公式サイトから入手できる。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Download

上のほうにあるコピーアイコンをクリックすれば、フィルタに与えるパラメータをテキスト形式でクリップボードにコピーできる。そのパラメータを G’MIC Animator Tool のパラメータ入力欄に貼り付ければいい。

GmicAnimator.exe を実行するとウインドウが開く。

• Input File に入力画像を指定。
• 一番下のフィルタ一覧で使いたいフィルタを選択。フィルタ名をダブルクリックすると、開始パラメータと終了パラメータにデフォルト値が入る。
• Frames でフレーム数を指定。
• パラメータの変化具合を色々選択できる。Linear Interpolation を選べば線形補間になって、直線的に値が変化する。
• Expressions ボタンをクリックすれば、パラメータの変化に数式を指定してループアニメを作れたりする。
• Create GIF にチェックを入れると、GIFアニメを作成できる。

Startボタンを押すと連番画像が出力される。GIFアニメを作成する場合も、一旦連番画像が作成される模様。

連番画像の保存先は GmicAnimator.exe のある場所に Output/入力画像ファイル名/ というフォルダが作成されて、その下に、入力画像ファイル名_001.png - 入力画像ファイル名_xxx.png というファイル名で保存される。

• 全フレーム数が2桁で終わる時は数字は2桁、全フレーム数が3桁の時は数字は3桁になる。
• 生成するたびに Output/入力画像ファイル名_2/, Output/入力画像ファイル名_3/ というフォルダが作られる。

ちなみに、ffmpeg を使って連番画像から mp4 を作成したいなら、以下のような指定ができる。

ffmpeg -y -framerate 24 -i emoji_%02d.png -vcodec libx264 -pix_fmt yuv420p -crf 16 -preset veryslow -r 24 out.mp4

試してみたところ、こんな感じの動画が作れた。




G'MICスクリプトを書いて処理することもできるだろうけど、GUIで指示して生成できるのは楽でいいかもしれないなと…。まあ、複数のフィルタをかけて処理したい時はスクリプトを書くことになるだろうけど。

ググってみたら、商品ジャンルとしては一応存在しているらしい。ただ、今日は何日か、何曜日なのかも分からなくなった高齢者向けに販売されている節があって…。

日付をデカデカと表示する製品が多く、たしかにこれなら見間違えは少ないだろうと思えたけれど、表示部が大きいせいなのか、あるいは高齢者を狙ったジャンルのせいなのか、お値段も高い…。

100円ショップで売ってるデジタル時計ぐらいの大きさや精度でいいのだけどな…。モード切替ボタンを押すと日付表示に固定できる仕様があればそれで事足りるのではないか。

ただ、今まで100円ショップで購入してきたその手の時計は、日付表示に切り替えた後、数秒で時刻表示に戻ってしまう。あくまで時刻表示がメインで、その他の情報表示はオマケという扱いなのだろう。時計と称して売っているのだから当たり前か。

精度が悪いのか、1日に5秒？ 15秒？ ほど時刻が進んでしまう100均デジタル時計を持っていたりするけれど、これが日付表示モードで固定できたら、そういった精度の問題もほとんど無視できそうな気もするのだけどな…。さすがに1日2日ずれてしまう時計なんて存在しないだろうし。

いっそ自作できないかとググってみたけれど、Raspberry Pi Zero を使って自作した事例は見かけた。

ただ、電子ペーパーで表示する等、なかなか凝った作りで、部品代だけで15,000円もあれば作れますよ、お安いでしょう、と…。その金額なら電波時計機能も持った市販のデジタルカレンダーを数台購入できてしまうのでは…。見た目が本当にカレンダーっぽくなっているあたりは自作ならではの高機能ぶりでイイ感じにも見えたけど…。

色々考えてみたものの、PCやスマホの画面を見れば日付も分かるわけで…。その程度の動作を面倒臭がってんじゃねえよ、という感も…。

いや、しかし、部屋の中ですっと視線を移すだけで日付を確認できるというのは、それはそれで便利であろう気もするし…。

昔は紙に印刷されたカレンダーを部屋の壁にぶら下げてどうにかしていたことを思い返すと、自分は随分モノグサになったよなあ…。

例えば、毎日決まった時間にメインPCから、もしくはスマホから表示データを転送して、受け取った側は一日中ソレをずっと表示するだけ、といった機器は作れないものだろうか。そういう機器があれば、カレンダーだろうとTODOリストだろうと、何だって好きな情報を部屋の片隅に表示しておくことができるだろうし…。何を経由して転送したら楽になるのかちょっと悩むけど…。

あるいは、ネットから気になる情報を入手して表示し続けるだけのデジタルガジェットとか…。昔そういう機器があったような気もするのだけど、名前が思い出せない…。小さい液晶画面で、TVのミニチュアっぽい形をしていて…。

AIに尋ねてみたら名称が出てきた。そうそう、コレコレ。

_チャンビー - Wikipedia
_スマートスピーカーの成功を見ずに終わった「Chumby」が見せた可能性：デジタル・イエスタデイワンスモア計画（1/3 ページ） - ITmedia NEWS
_ASCII.jp：chumbyで遊ぼう! (1/6)

森宿区民会館まで徒歩で行く際、命の危険を感じた…。結構交通量が多い上に、車がかなり速度を上げて走っていく道路なのに、歩道がほとんど無くて、これは危ない道だなと…。国道4号線の裏道として利用してるドライバーが多いのだろうけど…。信号機がほとんど無い道だからガンガン飛ばせるぞー、みたいな感覚なんだろうな…。

両脇には住宅がびっしり建ってるから、今から道路を広げることもできないだろうし、別の道路を作れそうなスペースも周辺にはない…。アレは危ないなあ…。どうにかできんのか。どうにもできないか…。車がほとんど走ってない時代に作った道路をそのまま使ってるんだろうな…。

それはともかく。池の横の祠が、何の祠なのかちょっと気になってる。実は水神様の類を祀っている祠だったりしたら、この埋め立て工事は死亡フラグになるかもなと…。

というのも、水神様を祀っていたとしたら、その一帯が昔から水害で悩まされていた地域である可能性が高いだろうから…。

2つの池は、ちょっと谷っぽいあたりに作られていたので、雨が降ると、周囲の山や丘から水が凄い勢いで集まって流れ込んでいた。これは想像だけど、もしも池が無かったら、あの水量と勢いが下にそのまま流れていくはずなので…。松尾芭蕉が通ったとされる、中宿から下宿へ通じる、昔からあった街道だって分断されるほどの水の流れがたびたび発生していたのではなかろうか。あくまで想像だけど。

そこで先人達は、池を2つ作って、水の流れを緩やかに、かつ、流れる場所をちょっと変えたりして対策した、という可能性があったりしないか。その際、池のすぐ横に祠を作って、「水神様、どうかこれで鎮まってください」と祈ってたりして…。

ところが今回、その2つの池を埋め立ててしまった。このままだと、昔の荒ぶる水神様(?)状態に戻ってしまう…。

数年後〜十数年後に大雨が降って、阿武隈川が氾濫したわけでもないのに池より下の地域が水没したら、あの池が水の流れを今までイイ感じに調整してくれていたことが分かるのかもしれない。

いやまあ、あの祠がどういう種類の祠なのか分からないので、このへん全部憶測というか只の妄想でしかないのだけれど。

しかし、名前からして気になるんだよな…。「上人池」だもんな…。何かしら由来があるんじゃないのか…。どこかに記録は無いのだろうか…。でも、商店街のあたりならともかく、このあたりは町の外れ(?)だし、何の記録も残ってなさそう…。

「調べてみたけどあの祠はそういうのじゃなさそうッスよ？」ということならちょっと安心(?)できそうだけど、誰も調べてないよな…。

池にどの程度の水が流れ込むかは計算できそうな気もする…。

降雨量？と、池の水面がどの程度上昇したかを調べれば、池の面積はもう分かってるだろうから、周囲からどの程度の水が流れ込んだのか計算できるはず…。ただ、1回だけ調べたのでは、降雨量と流入量が比例関係なのか、それとも指数関数的に増えるのか分からないだろうから、降雨量が違う状態で2〜3回調べることになるのだろうか…。

降雨量と流入量が分かれば、式というか係数が求まるから、得られた式に観測データ上最大の降雨量を与えて計算すれば、最大でどのくらいの水量が流れ込みそうか予想できる…。ただ、温暖化の影響で将来的に水量が増える可能性はあるので、マージンを取って…。

後は、その水量を流せるぐらいの排水管を用意すれば…。

まあ、自分のような素人ですらこんな感じで思いつくのだから、プロならもっと色んな要素を事前に調べて計算してから計画を立てるのだろうな…。そもそも埋め立てに使う土の量を事前に計算して出しておかないと工事もできないだろうし…。

ググっていたら以下のページが出てきた。

_井戸や池を無闇に埋めてはいけない - 井戸や池を埋める際には息抜きやお祓い等をして埋めなけ...

井戸や池を埋める際には息抜きやお祓い等をして埋めなければいけない。

建築関係や土木関係では有名な話で、田舎にお住まいの方は言い伝えで知っているかと思います。

井戸や池を無闇に埋めてはいけない - 井戸や池を埋める際には息抜きやお祓い等をして埋めなけ... より

そういうものなのか…。すると今回の池の埋め立ても、お祓い等をしてから始めてたりするのかなあ…。


_「井戸」は絶対に埋めるな…工事関係者から「ヤバい」「怖い」体験談が殺到　なぜ「井戸の息抜き」をしないといけないのか？｜まいどなニュース

完全に埋めてしまうと井戸内が密閉され、他の地下水脈に影響が出てしまったり、メタンガスが溜まって爆発する危険が生じます。

「井戸」は絶対に埋めるな…工事関係者から「ヤバい」「怖い」体験談が殺到　なぜ「井戸の息抜き」をしないといけないのか？｜まいどなニュース より

なるほど。物理的(?)に問題が出てしまう可能性があるのね…。それを昔の人は祟り云々と絡めることでノウハウとして伝えてたのかもしれないと…。

AI(Google Gemini)に尋ねてみたら、池を埋め立てることで色々な問題が起きる、と言ってきた。

古くから「池や井戸を埋めると祟り(たたり)がある」と言い伝えられてきた背景には、単なる迷信だけでなく、当時の人々が経験的に理解していた土地の性質や環境変化に伴う実害が深く関わっていると考えられています。

現代の科学的・物理的な視点から分析すると、主に以下のような問題が「祟り」の正体として挙げられます。


1. 地盤沈下と液状化

池を埋め立てた場所は、周囲に比べて地盤が非常に軟弱になりやすいのが最大の特徴です。

* 圧密沈下: 水を含んだ泥や有機物が堆積した層を十分に処理せずに土を被せると、建物の重みで数年〜数十年かけてゆっくりと地面が沈んでいきます。これにより家が傾いたり、壁に亀裂が入ったりします。

* 液状化現象: 地震が発生した際、砂まじりの軟弱地盤は液状化しやすく、建物が沈み込んだりマンホールが浮き上がったりする被害が出ます。


2. 地下水の流出経路の変化

池は単に水が溜まっている場所ではなく、周囲の地下水脈とつながっていることが多くあります。

* 水はけの悪化: 池を埋めることで地下水の出口を塞いでしまうと、周囲の土地の水はけが悪くなり、大雨の際に浸水しやすくなったり、近隣の家の床下が湿気たりする原因になります。

* 近隣の井戸枯れ: 逆に、水脈を断ち切ってしまうことで、近隣で使っていた井戸が突然枯れてしまうこともあります。これは近隣トラブルに直結し、現代でいう「法的なトラブル」が昔は「祟り」として恐れられた側面もあります。


3. 有害ガス(メタンガス等)の発生

池の底には、長い年月をかけて蓄積した落ち葉やプランクトンの死骸などの有機物が堆積しています。

* 腐敗と発酵: これらをそのままにして埋め立てると、地中で微生物による分解が進み、メタンガスや硫化水素などのガスが発生します。

* 健康被害と引火: ガスが家の中に流れ込むと、住人の体調不良(原因不明の病=祟り)を引き起こしたり、最悪の場合は引火・爆発の危険性すらあります。


4. 湿気による建物の腐朽と健康問題

埋立地特有の高い湿度は、物理的な構造物と人体に直接的な影響を与えます。

* シロアリとカビ: 湿気が多い場所はシロアリの格好の餌場となり、土台が腐りやすくなります。また、カビの発生は呼吸器疾患などの健康被害を招きます。

* 疫病の発生: かつては、湿地帯を中途半端に埋めることでボウフラが湧き、蚊を媒介とした感染症(マラリアなど)が蔓延したことも、祟りと結びつけられた一因でしょう。


結論としての「祟り」

かつての人々にとって、これらの「家が傾く」「突然病気になる」「水害に遭う」といった理不尽に見える現象は、池に宿る神や霊の怒りとして解釈するのが自然でした。

現代においても、池を埋める際には以下の「物理的なお祓い」が必要です。

1. 水抜きと泥の除去: 底に溜まったヘドロや有機物を完全に取り除く。
2. 息抜き(いきぬき): ガスや湿気を逃がすためのパイプを設置する。
3. 地盤改良: 良質な土で埋め戻し、転圧(締め固め)をしっかり行う。

これらを怠ると、今でも科学的な意味での「祟り」が発生する可能性があるといえます。

実にもっともらしいことを言ってくるものだなあ…。まあ、どこかしらでハルシネーションが起きてる(?)可能性もあるけれど…。でも、ざっと見た感じ、あり得そうな話ばかりに思える…。

画像内の一部を周囲に馴染ませながら消去したり、上下左右に繋がった状態のテクスチャを作れる Reynthesizerプラグインは、GIMPのバージョン毎に異なるバイナリを入手しないといけないけれど、GIMP 3.x 用は GIMP Portable のページの「Reynthesizer Plugin for GIMP Portable 3.0 Pre 2025-01-23.」をクリックすれば入手できる。

_GIMP Portable | PortableApps.com

GIMP_Portable_Resynthesizer_Plugin_3.0_Pre_2025-01-23.paf.exe を入手して実行すると展開場所を尋ねてくるので、GIMP 3.2.5 Portable をインストールした場所を指定すると、その中に Reynthesizerプラグインがインストールされる。

正常にインストールされると、フィルター → Reynthesizer という項目が増える。

数百種類のフィルタが使えるようになる G'MIC-Qt plug-in for GIMP 3 もインストールした。現行版は 3.7.4。

_G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Download

今回は zip版を入手した。

1. gmic_3.7.4_gimp3.2_win64.zip を入手して任意の場所に解凍。
2. GIMP 3.2.4 の、編集 → 設定 → フォルダー → プラグイン、で、G'MIC-Qt の置き場所を指定。

注意点。GIMP側でG'MIC-Qtのフォルダを追加指定する際は、gmic_gimp_qt.exe が入ってるフォルダ(gmic_gimp_qt/)じゃなくて、1つ上のフォルダを指定する。GIMP 3.x は、各プラグインがプラグイン名と同じ名前のフォルダに入ってることを前提にしているので…。

例えば、D:\hoge\fuga\gmic_gimp_qt\gmic_gimp_qt.exe に置いてあるなら、GIMP側では D:\hoge\fuga を指定する。

正常にインストールされると、フィルター → G'MIC-Qt... という項目が増える。

画像テンプレートの設定は、(GIMP Portableインストール場所)\Data\GimpAppData\templaterc というファイルに保存される。

ただ、GIMP 2.10.x の templaterc と中身を比べたら、GIMP 3.2.4 の templaterc はパラメータが色々増えていた…。以前の GIMP の templaterc をコピーして設定を済ませるわけにはいかないようだなと…。面倒臭いけど手作業で設定を追加したほうが良さそう…。

今回は以下のサイズを追加した。

256 x 256 (1:1)
512 x 512 (1:1)
1024 x 1024 (1:1)
2048 x 2048 (1:1)
640 x 480 (4:3) (VGA)
800 x 600 (4:3) (SVGA)

以下のサイズは既に登録されていた。

Display - 4:3 - 1024×768 (XGA)
Display - 4:3 - 1152×864 (XGA+)
Display - 4:3 - 1600×1200 (UXGA)
Display - 4:3 - 2048×1536 (QXGA)

Display - 16:9 - 1280×720 (HD 720p)
Display - 16:9 - 1920×1080 (Full HD 1080p)
Display - 16:9 - 3840×2160 (4K UHD)
Display - 16:9 - 7680×4320 (8K UHD)

Display - 16:10 - 1680×1050 (WSXGA+)
Display - 16:10 - 1920×1200 (WUXGA)
Display - 16:10 - 2560×1600 (WQXGA)
Display - 16:10 - 3840×2400 (WQUXGA)

Display - 17:9 - 2048×1080 (DCI 2K)
Display - 17:9 - 4096×2160 (DCI 4K)

各項目はドラッグアンドドロップで並び順を変更することができる。よく使う項目を上のほうに移動しておいた。

GIMP 3.2.2/3.2.4 Portable をインストールしてみたけれど、gtkrc が無かった。今までは gtkrc を編集してメニュー等のフォント種類を変更していたのだけど…。どうすればいいのだ…。

(GIMP Portableインストール場所)\Data\GimpAppData\theme.css の中に、以下の記述があった。

/* GIMP theme.css
 *
 * This file is written on GIMP startup and on every theme change.
 * It is NOT supposed to be edited manually. Edit your personal
 * gimp.css file instead (D:\Prog\Gimp-3.2.2-Portable\GIMPPortable\Data\GimpAppData\gimp.css).
 */

この theme.css は毎回上書きされちゃうので、設定をカスタマイズしたいなら GimpAppData/gimp.css を編集せよ、と書いてある、のかな？

そんなファイルは無かったけれど、gimp.css を新規作成して以下を書いてみた。

* {
    font-family: "Meiryo UI", sans-serif;
    font-size: 10pt;
}

GIMP 3.2.2/3.2.4 を起動してみたら、フォント種類が変わってくれたように見えた。この指定でいいのかな…？

GTK2 と違って GTK3 は .css で見た目を変更するようになったということなのだろうか…。

編集 → 設定 → 入力デバイス → 入力コントローラ → Main Mouse Wheel → 下の設定ボタンを押して設定する。

Scroll Up : view-zoom-in
Scroll Down : view-zoom-out

ついでに、Alt + マウスホイールでブラシサイズを変更できるようにした。

上にスクロール (Alt) : tools-size-increase-skip (10ずつ増やす)
下にスクロール (Alt) : tools-size-decrease-skip (10ずつ減らす)

Alt + マウスホイールは、デフォルト設定では以下になっている。

上にスクロール (Alt) : tools-opacity-increase (透明度を変更)
下にスクロール (Alt) : tools-opacity-decrease (透明度を変更)

ただ、デフォルト設定では以下も割り当てられているので、Ctrl + Alt + ホイールを使ってしまってもいいのかもしれない。

Ctrl + Alt + ホイール (上) : tools-size-increase
Ctrl + Alt + ホイール (下) : tools-size-decrease

あるいは、ショートカットキーの 「[」「]」にも同じ機能が割り当てられているので、そちらを使ってしまってもよいのかも。

データフォルダを追加したり、ショートカットキーを変更したりしてカスタマイズはできたので、GIMP 3.2 から追加されたというベクターレイヤーを試用してみたけれど…。

最初にベクターレイヤーを追加してから作業するのかなと思い込んで、レイヤー関係のメニューの中を探したけれど、そういう操作ではなかった。まずはパスツールでパスを作ってから、そのパスをベクターレイヤーにする、という流れで操作する。パスツールのツールオプションウインドウ内に「パスからレイヤーを作成」というボタンがあるので、パスを作ってからそのボタンをクリックすればベクターレイヤーになる。

あるいは、パスツールを選んだ直後 ―― まだパスを作ってない状態なら、パスツールオプション内に「新規ベクターレイヤーを作成」というボタンがあるので、それをクリックしてからパスを作成、という流れでもいいらしい？

何にせよ、ベクターレイヤーと呼んでいるのだからレイヤー周りにメニュー項目があるのだろう、と思い込むとハマりそう。あくまでパスツール周りの機能だから、パス関係のあたりにボタンやメニュー項目がある模様。

ベクターレイヤーは、塗り色と線の色を別々に設定できる。そのあたりの設定も、パスツールのオプション内で指定する。

余談。このベクターレイヤーの原型は、2006年頃に提示されていたらしい…。20年経ってからようやく実装されたのか…。しかし Krita は当の昔(?)にベクターレイヤーを実装していたわけで…。いやはや、Krita の開発速度って凄いんだな…。

_GIMP 3.0の新機能 非破壊編集フィルタについて < 特集 | GIMP入門 - 3.2 / 3.0版 -
_GIMP 3.2の新機能 調整レイヤ・ベクタレイヤ・リンクレイヤ < 特集 | GIMP入門 - 3.2 / 3.0版 -
_GIMP 3.2 がリリース - 省型旧形国電の残影を求めて
_GIMP が、3.2.2 にアップデート - 省型旧形国電の残影を求めて
_GIMP 3.2.4 がリリース - 省型旧形国電の残影を求めて
_GIMP 3.2リリース――20年越しの夢が、ようやく「安定版」になった日 | 情報の灯台

Krita から Stable Diffusion を呼び出して使える、Krita-ai-diffusion というプラグインがインストール済みだったけれど、新しいバージョン 1.49.1 が公開されていたようなのでアップデートしておいた。

_Acly/krita-ai-diffusion: Streamlined interface for generating images with AI in Krita. Inpaint and outpaint with optional text prompt, no tweaking required.

どのモデルデータを用意するかにもよるけれど、手元の環境では 86.73GB ほど関連ファイルが入っている。

それはともかく。1.49.1 はライブモードでエラーが出る…。以下のやり取りによると、シード値の最大値をチェックするあたりで問題が起きているらしい。

_when switching to live mode this error shows up - Issue #2454 - Acly/krita-ai-diffusion
_OverflowError happen when change to live panel - Issue #2443 - Acly/krita-ai-diffusion

C:\Users\(USERNAME)\AppData\Roaming\krita\pykrita\ai_diffusion\ui\live.py を修正すれば改善されるそうで、次回公開される予定のバージョンでは既に修正が反映されているけれど、せっかくだから手作業で修正して対応させた。

_"seed_input" field of live.py now uses a QDoubleSpinBox as widget - Acly/krita-ai-diffusion@043ba9c

Krita から AI を使って色々できる、krita-vision-tools もインストールしておいた。以前は krita-ai-tools という名前だったような気がする…。

• 1クリックでオブジェクトを選択できる。
• ボックス選択のような操作でオブジェクト形状の選択ができる。
• 背景を消去できる。

_Acly/krita-vision-tools: Krita plugin which adds selection tools to mask objects with a single click, or by drawing a bounding box.

Kritaのバージョン毎に異なるファイルを入手しないといけないらしい。今回は Krita 5.3.1 に対応と書いてある krita_vision_tools-windows-x64-2.2.0.zip を入手。

ツール → スクリプト → Pythonプラグインをファイルからインポート、を選んで、krita_vision_tools-windows-x64-2.2.0.zip を指定すればインストールできる。

ツールボックス？に以下の2つのツールが増える。

• Point Segmentation Selection Tool : 1クリックでオブジェクトを選択
• Box Segmentation Selection Tool : ボックス選択でオブジェクトを選択

また、フィルタ → その他 → Background Removal という背景消去ができるフィルタも増える。

落語をゲームに応用できないかな。ジャンルとしてはADVやRPGなんだけど画面の見た目は落語、とか。いやそれどんなゲームやねん。イメージが湧かないわ…。

逆はできないかな？ ADVやRPGを落語にする。難しいかなあ…。HPだのヒールだのそういうワードを落語家さんが喋るんだろうか。

ググったら既にあった…。あるんかい！

_史上初!老舗寄席で『ドラクエ落語』開催 モンスターに扮した落語家が“創作落語"を披露 | オリコンニュース(ORICON NEWS)
_落語への扉をアバカムする「ドラクエ」落語が大盛況! 混沌の高座をレポート

RPGを落語にできるなら他にも色々な何かを落語のネタにできそうではあるな…。サイバーパンク落語とか。なんですかそれ。

ウルトラマン落語とか仮面ライダー落語とかゴジラ落語とかあってもいいのかもしれない。いや、もうありそうだけど…。と思ってググったらやっぱりあった…。あるんかーい。

_円谷プロ公認!柳家喬太郎「ウルトラマン落語」10/26(水)DVD発売! - 円谷ステーション - ウルトラマン、円谷プロ公式サイト
_ゴジラと講談&落語がコラボ!? 世界初「ゴジラ寄席」開催 | アニメ!アニメ!
_仮面ライダーが好きなワケ - ヲタクな落語家、春風亭吉好の毎日ブログ

落語の側では何でも取り込んでネタにすることができる、ということなのだろう…。落語というスタイル自体を別の何かが取り込んだりするのは難しいのかもしれないけれど…。

落語についてAIに尋ねていたら、「落語は、舞台装置、演者の服装その他を観客の想像力に委ねている。これはある種のアウトソーシングと言える。故にここまで長く続いた面もあるのでは」みたいなことを言い出した。

なるほど…。であれば、それは別メディアでも応用が利いたりしないかなと…。

いやまあ、小説/漫画/演劇も、読者/観客の想像力に委ねている部分がかなりあるわけで、既に色んなメディアで応用されている気もする…。

逆はどうだろう。例えば、落語のネタを一つ一つ具体的なビジュアルにしてがっつり全部見せるスタイルは…。以前NHKの番組でそういうのを見たような気もするな…。アレは結構面白かった…。

そもそも、アニメやドラマや映画などは、小説や漫画が読者の想像力に委ねていた部分を、スタッフがしっかり作り込んでがっつり見せることで成立しているメディア、と言えそうでもある。だから原作ファンがえてして文句を言うわけだけど…。「俺の想像していたものと違う。コレジャナイ」みたいな。

がっつりとそのものを見せるのが当たり前になっているメディア・表現手法の中で、あえて落語っぽく具体性を削っていくことで、何か変わったものになったりしないかなあ、などと夢想したりもする…。漠然とし過ぎていて何もイメージできないけど…。映画と自称している作品だけど実質的には漫画・小説、みたいな？ と書いてみたけどやっぱりイメージが湧かない…。

妄想メモです。オチはないです。

諦めきれずにググっていたら、画像からグラデーションファイル(.ggr)を作成できる Scrpit-Fu があると知った。

_Convert an IMG to a Gradient - GIMP Chat
_GGR from Image

以下の2つの Script-Fu が入手できた。おそらく GIMP 2.x にのみ対応。GIMP 3.x では動作しないのではないかな…。

• gradient-from-image.scm : 画像からグラデーションを作成する。
• sample-gradient-along-path.scm : パスを作成して、パス上の色を取得してグラデーションを作成する。

1. インストール後、何かしらの画像を開いて、グラデーションウインドウ？ パレット？ 上で、何かしらのグラデーションを選んで右クリック。
2. 「Gradient from Image...」「Sample gradient along a Path...」という項目が増えている。
3. 選択するとダイアログが開くので、サンプリング個数、グラデーションファイル名等を入力してOKをクリック。
4. GIMPがグラデーションファイルを読み込んでいるフォルダ内に、グラデショーンファイル(.ggr)が保存される。

G'MIC の Gradient [from Curve] だけで処理できれば嬉しかったのだけど、まあ、これでもどうにかなりそうではあるかな…。

ちなみに、G'MIC の Gradient [from Curve] は、サンプリングした色を明度でソートして並び替えたりもできるので、一旦 G'MIC で綺麗なグラデーション画像を作成してから、Script-Fu でグラデーションファイル化するのもアリかもしれない。

どうやら G'MIC の Gradient [from Line] は、Linux環境じゃないとファイル保存できないっぽい。

• Windows11 x64 25H2 + GIMP 2.8.22 Portable + G'MIC-Qt 2.4.2 + Gradient [from Line] も試してみたけれど、グラデーションファイル(.ggr)は保存されなかった。
• G'MIC-Qt 3.7.4 Standalone版も試してみたけれど、保存されているようには見えない…。スタンドアロン版でもダメとは…。
• GIMP 2.6.12 Protable を起動してみたけど、これはそもそも G'MIC-Qt をインストールしてなかった…。
• Ubuntu Linux 22.04 LTS + GIMP 2.10.30 + G'MIC-Qt 2.9.4 で試してみたところ、/home/(USERNAME)/.config/GIMP/2.10/gradients/ に .ggr が保存された。

Linux上でしか動作しないフィルタだったか…。そういうオチか。トホホ。

いや、もしかすると Windows上でも、GIMP Portable 版ではなくて通常のインストーラ版なら動作する可能性があるのかもしれない？ Linux上で動かしたGIMPは通常インストール版に近いはずだから…。

ただ、そこまでして動作確認したくない…。GIMP 2.8 / 2.10時代の通常インストール版は旧バージョンのユーザフォルダを何の問い合わせもなく全削除しちゃって途方に暮れた記憶があって、それ以来触らないことにしている…。

それはさておき。Ubuntu Linux 22.04 LTS + GIMP 3.2.4 (flatpak版) + G'MIC-Qt 3.7.4 で試してみたら、/home/(USERNAME)/.config/GIMP/3.2/gradients/ ではなく、/home/(USERNAME)/.config/GIMP/2.10/gradients/ 以下に .ggr が保存された。保存先を 3.2/ にしてるはずなのに、どうして 2.10/ のほうに保存されるのだろう…？

G'MIC の Gradient [from Line] は、サンプリングした各色の間を補間(?)してくれない模様。ガタガタしたグラデーションになってしまう。

Script-Fuを使ってグラデーションファイル(.ggr)を作れば色と色の間をスムーズにできるのでそちらを使ったほうがいいかもしれない。

20.04 LTS から 22.04 LTS にアップグレードしようとしたら、仮想HDDイメージの容量が足りなくて、途中で処理が止まってしまった。「/」に、6〜7GBの空き容量が必要らしい…。今まで32GBだったけれど、48GBまで増やすことにした。

以下のページを参考にしながら作業。ありがたや。

_VM上のext4パーティションを拡張するメモ
_VMware上のUbuntu 22.04 ファイルシステム拡張 parted - Qiita

仮想PCをシャットダウンしてから、VMware の設定でストレージの容量を10GBほど拡張。仮想マシンの設定を編集する → ハードウェア → ハードディスク (SCSI) → ディスク容量を拡張します「展開」、をクリック。総容量を指定する。

Ubuntu を起動。

以下を打って、HDDのサイズ変更を認識させる。らしい。

sudo sh -c "echo 1 > /sys/class/block/sda/device/rescan"

parted を起動。

sudo parted /dev/sda

• print free で状態を確認。
• resizepart 1 で特定のパーティションに空き容量を追加する。100% と打てば追加できる。
• q で終了。

print free
resizepart 1
100%
print free
q

resize2fs でパーティションサイズを変更。

resize2fs /dev/sda2

これで48GBまで増やせた。

ただ、後で過去の作業メモを見直してみたら、パーティションサイズを増やすだけなら GParted でも出来たらしい…。そっちを使ったほうが簡単だよな…。

_mieki256's diary - VMwareの仮想HDDのサイズを増やしてみた

Ubuntu Linux 24.04 LTS にアップグレードしたら、起動時に必ず以下のエラーダイアログが表示されて悩んでしまった。しかも、このエラーダイアログが表示されるまで、異様に時間がかかる…。デスクトップが表示されるまで待たされる…。

Error found when loading /etc/profile: 

X Error of failed request: BadName (named color or font does not exist)
Major opcode of failed request: 141 (RANDR) 
Minor opcode of failed request: 16 (RRCreateMode) 
Serial number of failed request: 55 
Current serial number in output stream: 55 

Asa result the session will not be configured correctly. 
You should fix the problem as soon as feasible.

調べたら、/etc/profile.d/ 以下に mydisplay.sh というスクリプトがあって、その中で xrandr を呼び出していた。中身を削除してみたらエラーが表示されなくなった。また、デスクトップが表示されるまでの時間も短くなった。

どの段階でこのスクリプトを作ったのだろう…。自分で作ったのか、自動で作られたのか、覚えてない…。

vim を起動しようとしたらエラーが出る。どうやら以前入れていたプラグインが動作しなくなっていた模様。

~/.vimrc 内の記述をごっそり削除したり、~/.vim/ 内をごっそり削除したらエラーは出なくなった…けれど、今までの設定はほとんど消滅した状態に…。まあいいか。エラーが出るよりはマシだよな…。

sudo apt update をすると Google Chrome 関係でエラーが表示された。

N: リポジトリ 'https://dl.google.com/linux/chrome-stable/deb stable InRelease' がアーキテクチャ 'i386' をサポートしないため設定ファイル 'main/binary-i386/Packages' の取得をスキップ

以下のページによると、/etc/apt/sources.list.d/google-chrome.sources 内で、amd64 を指定してないとこうなるらしい。

_萌え萌えmoebuntu Google Chromeのリポジトリで不要な「i386」関連のエラーに対処する方法!

以下の1行を、"Components: main" の次の行に追加。

Architectures: amd64

元々、GIMPの動作確認をしたくてアップグレードしたのだけど、Ubuntu Linux 24.04 LTS に入ってたのは、GIMP 2.10.36 + G'MIC-Qt 2.9.4 だった。

これはちょっとビミョーな状況かも…。Debian Linux や Ubuntu Linux は Python 2.7 を切り捨てて Python 3.x に移行してしまったので、Python 2.7 を要求する GIMP 2.10.x では、Python-Fu / Gimp-Python は動作しない…。

GIMP 3.x は Python 3.x に移行したけれど、Python-Fu / Gimp-Python の書き方が大きく変わってしまったそうで、GIMP 2.10.x 時代の Python-Fu / Gimp-Python スクリプトはまず動作しない。

ただ、以下の AppImage を使えば Python-Fu / GIMP-Python が動作する GIMP 2.10.38 を利用できる。

_Release Continuous Hybrid (Experimental) - ivan-hc/GIMP-appimage

GNU-Image-Manipulation-Program_2.10.38-5-Hybrid-with-python2-from-Debian-Buster-archimage4.9-x86_64.AppImage を入手して、chmod +x *.AppImage で実行権限をつけて、./GNU-Image-Manipulation-Program... で実行したら Ubuntu Linux 24.04 LTS上でも動いてくれた。

思考メモです。

TVアニメの続編的な劇場版を作る際、どうしてメインキャラ達が酷い状態から話が始まってしまうのであろうか…。

まあ、右肩上がりの展開を見せていくためには一度落としておかないといかんのだ、みたいなことなのかな。ただ、TV版の最後のあたりで希望を持たせるような光景を見せておきながらコレは無いよー、という印象を受けてしまうのは否めない気もする…。 *1

押井守監督が劇場版パト2を作った際に、「シリーズを続けたいなら数年後のメインキャラを見せちゃダメ。俺はもうこの企画を終わらせたかったからこうしたけどフツーこんなことしたらシリーズの息の根は止まるんだよ」みたいな感じの発言をしていた記憶があるのだけど…。その論で行けば、「SHIROBAKO」劇場版も、「ゆるキャン」劇場版も、スタッフはもう、その企画にウンザリしていて、これで打ち止めのつもりでこういう設定にしたのかもしれない、と邪推することもできそう…。

「ちょっと待て。じゃあZガンダムやZZや逆シャアはどうなるんだよ。ずっと続いてるじゃねえか」 そうなんだよなあ…。例外は結構ある…。そもそも押井監督自身が実写版パトレイバーを作ってた気もする…。シリーズの息の根、全然止まってないじゃんよ。

押井監督のソレは、あくまで一般論としてはそうなのです、そういう設定にするならそのくらいの覚悟を持て、という話なのかも。ただし例外はあると…。

例外になるための条件がありそうな気もする…。例えばメインキャラが刷新された続編にするとか？ ガンダムならF91とかVとかGとか？ いや、そもそもZガンダムの主人公はアムロじゃなかったし、そこからして条件を満たしていたのだろうか。

プリキュアやライダーやウルトラマンもシリーズとしてずっと続いてるよな…。あのへんのシリーズはどうして続いているのだろう…。どういう条件を満たしているのだろう？

STAR WARSシリーズが続いているのは何故なのか。何の条件を満たしているのか。長期シリーズになってるアレコレに対して満たしている条件を探していくと何か見えてきそうな気も…。それが分かればヒットシリーズを作るのも夢ではない…？

思考メモです。オチは無いです。