mieki256's diary



2008/03/18(火) [n年前の日記]

#1 [iappli][cg_tools][prog] GIMPのレイヤー位置を取得できないかと実験中

iアプリの画面上にgif画像を表示するわけだけど。各gifの表示位置調整をする際に、今現在は下のような作業手順を踏んでたり。
  1. GIMPの、「ファイル」→「レイヤーとして開く」で、複数のgifをレイヤーとして読み込む。
  2. 各レイヤーを順々に選択。して以下の作業を。
  3. 「すべて選択」でレイヤーサイズの選択領域を作る。
  4. 「選択領域をストローク描画」して、レイヤーサイズの枠を描く。
  5. レイヤーを移動。位置調整。
  6. 全レイヤーの位置調整が終わったら、「ファイル」→「コピーを保存」で、レイヤー統合状態の画像をpngとして保存。
  7. ドットエディタ EDGE2を起動。先ほど保存した png を読み込み。
  8. クリップボード履歴をテキストファイル保存するユーティリティ、CliPla を起動。
  9. 「目視」で、png上の各枠を選択。←ここがシンドイ。
  10. 選択範囲(左上座標値と縦横幅)をテキストとしてコピー。(ショートカットキーで Alt+C に割り当ててる。)
  11. 一通り座標値を取れたら、CliPla で、クリップボード履歴をテキストファイル保存。
実にアホらしい。

目の前の画像編集ツール上では、レイヤー位置情報を内部的に持ってるからこそ、表示位置の調整ができているわけで。しかし、それをテキスト出力できないというただそれだけで、人間が目視でもう一度座標値を測定し直すことになるという…。まったくもう、何のためのコンピュータか。何のためのデジタルデータ化なのか。これでは、人間がコンピュータに使われちゃってる典型例ではないか。ぷんすか。

一度や二度の修正だったら、まだこんな感じでやれなくもないけれど。今後、相手先から、「ここ直して」「こっちもずらして」てな修正要求がどんどん出てくるだろうから、さすがにこのへんどうにかせんといかんなと。かといって、エディタでソース上のテーブルをチクチクと修正→コンパイル→画面確認、とかやるのもアホらしい。

ということで、GIMP の Script-fu (2.4は、Tiny-fu?)でどうにかできんかと実験中。

Scheme 判らねえ。 :

Script-fu にしろ Tiny-fu にしろ、Scheme なるLisp系の言語が元になってるらしいのだけど。アレコレ検索しても資料ページにぶつからない。数値から文字列への変換ってどうやるんだらう。とかそんなレベルで躓いたり。資料がないってことは、物凄くマイナーなんだな。この言語は。

大体にして、Lisp系の、「a = 1 + 2」を「(a (+ 1 2))」とか書かなきゃいけないところが嫌だ。や、前者も、内部的には後者にして処理をする・スタックに貯めていって処理をする、と中学の頃に読んだ雑誌には書いてあったけど。勝手な想像だけど、前者で言語を作った人は、「やっぱり人間が判りにくい書き方はいかんだろう。人間がコンピュータに使われちゃいかん。俺が苦労しても、それで皆が楽になるなら…」と思いながら実装してたのではなかろうか。しかし後者は「俺はこれでも判るし、コンピュータも判りやすいんだから、これでええやんか」という気持ちで言語を作ってたのではないか。「俺が判るんだからそれでいい」という姿勢からして気に食わん。しかも「え? なんでこれが判んないの? 君達バカ?」みたいな雰囲気を時々漂わせてるし。>Lisp使用者。こんな独りよがりで、優越感ゲームに浸った気持ちで作られた、カッコばかりつけてる言語が、普及するわけなどないのです。嘘です。根拠のない妄想を垂れ流してんじゃねえ。>俺。どうもスイマセン。

つーかどうしてGIMPは、PyGimp? Python-fu を標準にしないのかな。標準ではないから、pythonで書いても「俺しか使えない・俺の環境でしか使えない」ということになっちゃって、作成意欲?公開意欲?が削がれるし。さりとてLisp系言語は習得が大変みたいだし。なもんだから、「よっしゃ、ここは一つ、俺がスクリプト書いたるか」てな人が滅多に出てこない状態に。Lisp系を導入したツール・アプリケーションは、えてしてそのことが足を引っ張ってる気がする。Lispは存在自体が害悪。とまで書くのはアレだけど、結構それに近い場面が多い気もしたり。…まあ、スクリプト関連が何もないよりはマシなのかもしれんのですが。

printf()デバック的手法が使えねえ。 :

(gimp-message hogestring) みたいな感じで動作確認しようとしたら、「不正なUTF8文字列です」等のエラーが出て困り果てる。巷で何かとバカにされがちだったりするぐらいに一般的な手法である、printf()っぽいソレも使えないとは…。なんというクソ環境!

Script-fuコンソールで事前に部分的テストをしようと思っても、入力欄が1行しかないから大変なことに。対応カッコを色づけ表示等もなければ、タブキーで補完とかそういうのもないし。結局、スクリプトファイルを書いたら、ツールボックスの「拡張」→「Script-fu」→「スクリプトリフレッシュ」をして、しばらく待たされてから動作確認、というループで作業する羽目に。どうにかならんのか。

例えば、Script-fuコンソールを出力先として指定した状態でメッセージ出力、とかできんのかな。あるいはどこぞのテキストファイルにひたすらログを残すとか。

保存先ファイルのフルパス文字列すら作れねえ。 :

保存テキストファイル名のパスを、SF-DIRNAME と SF-STRING から得たソレで、 (string-append dirname "/" filename) で作ろうとしたら。できたソレは、C:\hoge\piyo/hoge.txt みたいな。あー、パス区切り文字が…。

外人さんは「SF-FILENAME の仕様が変わったんで (string-append dirname "/" filename) でフルパス作ってどうにかせい」とか言ってるみたいだけど。ソレ、*NIX文化圏でしか動かないスクリプトになったりしないのか? 各OS環境でどのパス区切り文字が使われてるか、システム変数とか関数とかそのあたり使って取り出せれば助かるけれど、そんなもんがあったら「(string-append dirname "/" filename)で〜」とか言ってたりしないよな。ということは、おそらくそんな気の利いたものは用意されてないに違いない。

GIMPの標準添付スクリプト界隈は、ディレクトリやファイルの取扱いに関して、どうも何かが弱い気がする。例えば、 _Python の os.path あたりを見てると、「異なる環境でもちゃんと使えるように」てな気配り?が感じられるんだけど。それに比べるとGIMPのソレは、上記のような感じで。

それはともかく、解法はないものかと検索してたら、Windows版 GTK+ では「\」も「/」も両方パス区切り文字として扱ってたりするかもよ、てなPDF文書に遭遇。であれば、問答無用で「/」でやっちゃってもいいんだろうけど。本当にそうなってるのかなぁ…。なんだか怖いなあ…。

なんとかできたかもしれない。 :

こんな感じに。
(define (script-fu-dump-layer-offsets
         img         ; image ID
         drawable    ; target drawable ID (not used)
         dirname     ; output dircetory name
         pathstr     ; path separator
         filename    ; output text filename
         )

  (let* ((layers (gimp-image-get-layers img))
         (number-layers (car layers))
         (layer-array (cadr layers))
         (layer-count 0)
         (layer 0)
         (outputpath (string-append dirname pathstr filename)))
    (set! layer-count 0)
    (call-with-output-file
     outputpath
     (lambda (p)
       (while (< layer-count number-layers)
         (set! layer (vector-ref layer-array layer-count))
         (gimp-image-set-active-layer img layer)
         (let* ((name         (car (gimp-layer-get-name layer)))
                (offset-x     (car (gimp-drawable-offsets layer)))
                (offset-y     (cadr (gimp-drawable-offsets layer)))
                (layer-width  (car (gimp-drawable-width layer)))
                (layer-height (car (gimp-drawable-height layer)))
                (s (string-append
                    name ","
                    (number->string offset-x) ","
                    (number->string offset-y) ","
                    (number->string layer-width) ","
                    (number->string layer-height) ","))) 
             (display s p)
             (newline p))
         (set! layer-count (+ layer-count 1)))
       ;; (close-output-port p)
       ))
    ; (gimp-message-set-handler MESSAGE-BOX)
    ; (gimp-message (string-append "Output File : " outputpath))))
    
    ))
    

(script-fu-register 
 "script-fu-dump-layer-offsets"
 "Dump All Layer Offsets..."
 "全レイヤー位置座標をダンプ"
 "mieki256"
 "mieki256"
 "2008/03/18"
 "*"
 SF-IMAGE    "Image"    0
 SF-DRAWABLE "Drawable" 0 
 SF-DIRNAME  "Select Output Directory" "."
 SF-STRING  "path separator" "\\"
 SF-STRING  "Input Output Text Filename" "dump_temp.txt"
 )

(script-fu-menu-register "script-fu-dump-layer-offsets"
                         "<Image>/Layer")
エラー処理とかどうやって書いたらいいのか判んないので、場合によっては酷いことになる可能性大。それと、レイヤー名に日本語を使ってると謎の文字列で記録される。例えば、「背景」→「闇」になってたり。…なんで「闇」なんだ。なんだか怖い。

「闇」じゃなくて、別の文字っぽいな。

以上です。

過去ログ表示

Prev - 2008/03 - Next
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project