mieki256's diary

◎ 開封 :

◎ ドライバをインストール :

◎ 使用感 :

◎ ペン立てについて :

◎ 今まで使ってたタブレットとのスペック比較。 :

◎ GIMP Plugin Registryのバックアップについて :

◎ Gimp Plug-in for Image Registration について :

Gimp Plug-in for Image Registration を使うと、そこそこ自動でレイヤーの位置合わせをしてくれる。このプラグインについては公式ページに辿り着けた。

_Gimp Plug-in for Image Registration: Welcome!
_Gimp Plug-in for Image Registration: Examples
_Gimp Plug-in for Image Registration download | SourceForge.net
_Gimp Plug-in for Image Registration - Browse /version-2.0.1 at SourceForge.net

SourceForge.net から 2.0.1 が入手できる模様。今回は gimp-image-reg-2.0.1-windows.zip を入手。解凍すると、gimp-image-reg.py と imregフォルダが入っているので、GIMPユーザーフォルダ/plug-ins/ にコピーすればインストールできる。

ちなみに、0.5.5 の頃は、gimp-image-reg.exe という実行バイナリの形で提供されていた。2.0.x から、Python-Fu (GIMP-Python) で書き直したようだなと…。

インストールすると、GIMPのメニューバーの「ツール」に「Image Registration...」という項目が増える。

使い方は以下。例えば、以下のような状態の2枚のレイヤーがあるとして、上のレイヤーを移動して位置合わせしたい。上のレイヤーを選択してアクティブにしておく。

ツール → Image Registration を選択。

設定ダイアログが開くので、Reference Image として、参照するレイヤー(下のレイヤー)を選んで、OKをクリック。

アクティブだったレイヤーが移動して、位置合わせができた。

ただ、どちらのレイヤーもそれなりに近い位置にないと正しく処理されないようにも見えた。縦方向は位置合わせしてくれたけど、横方向はずれたままになる場面もあって…。あらかじめ、ざっくりでいいから、目視で大まかにレイヤー位置を合わせておく必要がありそう。

前述の設定ダイアログを眺めると、移動＋回転ではなくアフィン変換を使ったり、画素の補間アルゴリズムも色々選べるようだなと…。

◎ exact-aligner.scm について :

自動で位置合わせするわけではないけれど、GIMPのパスツールを利用して、移動先と移動元の位置を指定してやることで、比較的簡単にレイヤーの位置合わせをしてくれる、exact-aligner.scm という Script-Fu もある。github の GIMP Plugin Registry のバックアップから入手することができる。

_exact-aligner.scm at master - pixlsus/registry.gimp.org_static - GitHub
_Exact Align via 4-Point Path - GIMP Chat

ただ、このスクリプトは古いので、もしかするとGIMPのメニューに出てこないかもしれない…。メニュー位置だけを、Script-Fu → Tries-Tools → Exact Aligner に変えた版も一応置いておく。

_exact-aligner.scm

変更点は以下。

--- exact-aligner.orig.scm      Thu Jul 13 06:08:24 2023
+++ exact-aligner.scm   Sat Jul  5 15:36:07 2014
@@ -146,7 +146,8 @@

 ;Now we want to register this stuff...
 (script-fu-register "script-fu-exact-overlay"
-       _"<Image>/Tries-Tools/Exact Aligner"
+       ;; _"<Image>/Tries-Tools/Exact Aligner"
+       _"<Image>/Script-Fu/Tries-Tools/Exact Aligner"
        "Exact projection of 2 images in 2 layers"
        "Dr. Volker Tries"
        "(c) 2009, Dr. Volker Tries - Volker.Tries@kfopraxis-oberursel.de"

インストールの仕方は、該当ファイルを、GIMPユーザフォルダ/scripts/ 以下にコピーすればいい。

使い方は以下。GIMPのパスツールを選んで…。

マウスで左クリックして、4つの点を指定。1番目の点の位置に3番目の点が、2番目の点の位置に4番目の点が移動する感じで…。最初に移動先の2点を打つ、みたいな。

Script-Fu → Tries-Tools → Exact Aligner、を選択。

アクティブレイヤーの位置が変更されて、位置合わせができた。

おそらくだけど、このスクリプトは、移動、回転、拡大縮小をして、位置合わせをしているような気がする…。例えば以下のように、移動＋回転＋拡大縮小をしたレイヤーに対して処理しても、それらしく位置合わせしてくれるので…。

逆に言うと、単に移動だけしたい場合でも、回転や拡大縮小がかかってしまって、レイヤー内の画像が荒れてしまう可能性もありそうだなと…。

◎ ofn-layer-aligner.py について :

前述の exact-aligner.scm を Python-Fu で書き直した、ofn-layer-aligner.py という版もあるらしい。exact-aligner.scm が持っていた不具合をいくつか修正済みとのこと。

_ofn-layer-aligner - GIMP Chat
_Ofnuts' Gimp Tools - Browse /scripts at SourceForge.net

ofn-layer-aligner.zip を入手して解凍すると、ofn-layer-aligner.py というファイルがあるので、GIMPユーザフォルダ/plug-ins/ にコピーしてやればインストールできる。ちなみに、件の zip には使い方の説明書(ofn-layer-aligner.howto.html) も入ってる。

メニュー項目は、レイヤー → Realign。

使い方は、exact-aligner.scm と同じ。GIMPのパスツールを選んで…。

4点を打って…。

レイヤー → Realign、を選択。

アクティブレイヤーの位置が変更されて、位置合わせができた。

◎ SS-path-referenced-scale-move-rotate_v1-0.scm について :

前述の exact-aligner.scm と似た感じで、パスツールを利用して点の位置を指定することでアレコレできる、SS-path-referenced-scale-move-rotate_v1-0.scm という Script-Fu もある。移動、回転、拡大縮小が別々の項目になっているので、利用したい処理だけを選ぶことができる。

_SS-path-referenced-scale-move-rotate_v1-0.scm at master - pixlsus/registry.gimp.org_static - GitHub
_GIMP script scale-move-rotate tutorial.pdf at master - pixlsus/registry.gimp.org_static - GitHub

"GIMP script scale-move-rotate tutorial.pdf" という説明pdfもあるのだけど、github上に置いてあるpdfは、そのままWebブラウザで閲覧できないようで…。一旦ローカルにダウンロードしてから開かないと中身を確認できなかった。一応ここにも置いておくけど、これで見れるのかどうか…。

_gimp_script_scale-move-rotate_tutorial.pdf

さておき。SS-path-referenced-scale-move-rotate_v1-0.scm を入手して、GIMPユーザフォルダ/scripts/ にコピーしてやればインストールできる。

メニュー項目は、レイヤー → 変形 → With Path... → (Move|Ortho|Rotate|Scale) by Path。4項目ほど追加される。

まずは Move by Path の使い方をメモ。パスツールで、移動元の点の位置、移動先の点の位置を指定する。

レイヤー → 変形 → With Path... → Move by Path、を選択。

アクティブレイヤーの位置が移動した。この処理は移動のみで、回転や拡大縮小はしない。

移動直後に赤い色のパスが新規に作られるけれど、これはこの後、回転処理もしたい時に利用する。移動処理のみで済むなら、無視するなり、パスを削除してしまっていい。


回転処理についてもメモ。例えば以下のように、位置がずれていて、かつ、角度が違っているレイヤーがあるとして…。

まずは位置だけ調整する。パスツールで、移動元、移動先の順で、点の位置を指定。

レイヤー → 変形 → With Path... → Move by Path、を選択。

位置のみを変更できた。新規に作成された赤いパスをパスツールでクリックして、角度を指定していく。

水平になっていたパスの点の位置を、移動元に合わせる。垂直になっていたパスの点の位置を、移動先に合わせる。

レイヤー → 変形 → With Path... → Rotate by Path、を選択。

アクティブレイヤーが回転して位置合わせができた。

Ortho by Path を使うと、水平、もしくは垂直に、レイヤーを回転させることもできる。例えば以下のような状態のレイヤーがあるとして、水平にしたい部分をパスツールで指定する。

レイヤー → 変形 → With Path... → Ortho by Path、を選択。

レイヤーが水平に見えるように回転してくれた。

ちなみに、垂直になるように回転させたい場合は、縦方向に長いパスを指定してやればいい。おそらく45度を境目にして判別してるのではないかな…。たぶん。


Scale by Path を使うと、拡大縮小をさせることもできる。例えば以下のような状態のレイヤーがあるとして、移動先、移動元の順に、パスツールで点を指定する。注意したいのは、2本の線があるような感じで指定すること。2本目の線の最初の点は、Shift + 左クリックをする。これで、線が分離してるようなパスを作れる。

レイヤー → 変形 → With Path... → Scale by Path、を選択。

アクティブレイヤーが拡大縮小されて位置合わせができた。

◎ 余談。手動で位置合わせをする場合 :

pip install Pillow -U
pip install tqdm -U

python yodither1.py -i input.png -o out.png --mp
python yodither1tritone.py -i input.png -o out.png --mp
python yodither3.py -i input.png -o out.png --mp
python yodither4.py -i input.png -o out.png --mp

> py yodither1.py --help
usage: yodither1.py [-h] -i INPUT -o OUTPUT [-p PALETTE] [-d DITHER] [--mp]

Yliluoma ordered dithering 1

optional arguments:
  -h, --help            show this help message and exit
  -i INPUT, --input INPUT
                        Input png filename
  -o OUTPUT, --output OUTPUT
                        Output png filename
  -p PALETTE, --palette PALETTE
                        Palette file (.png or .gpl)
  -d DITHER, --dither DITHER
                        Dither type 2,4,8 (2x2,4x4,8x8). default: 8
  --mp                  Enable multi process

◎ 処理時間を実測。 :

◎ 余談。 :

◎ 代替機にファイルが移せない。 :

◎ 2021/7/14追記。 :

液漏れしてるコンデンサは以下のような感じ。

「Rubycon 10v 1500μF」と書いてあるように見える。

VIA EPIA M/B が出回っていた時期は、例の不良電解コンデンサが大量に市場に出てしまっていた時期だった、という話を見かけた。もしかすると、このM/Bも、その時期の個体だったのかもしれない…。

コンデンサだけ交換して修理できないものかとググってみたけど、「10V 1500μF」というスペックのコンデンサはメジャーではないので入手が若干難しいようで。更に、多層基板上でのコンデンサの取り外しにはコツが必要だそうで…。熱が基板上に逃げてしまう、とかなんとか…。なかなか難しそう。

◎ 手順をメモ。 :

blender のパーティクル機能を使って、オブジェクトを大量に発生させる。以下の記事がとても参考になった。ありがたや。

_[2.8]Blenderひとりもくもく会:パーティクル編｜MITSUDA Tetsuo｜note

パーティクル関係の設定は以下のような感じ。

当初、パーティクルが下に落ちていって困ったけれど、フィールドの重み → 重力、を 0 にしたら落下しない状態になってくれた。

発生させるオブジェクトは、Cube(立方体) にした。Cube 追加してから、細分化。細分化の際に、スムーズを掛けて、丸い形にしていく。その後、頂点のランダム化で凸凹に。更に、サブディビジョンサーフェイスで滑らかに。

セルルック風のマテリアル指定は、以下のような感じに。

マテリアル設定については、以下の記事がとても参考になった。ありがたや。

_【Eevee】Blender2.8でトゥーンシェーダーを作る！ - もろりんの3DCGブログ（改装中）


レンダリング関係の設定は以下。

• レンダーエンジンは Eevee。
• カラーマネジメント → ビュー変換、は、標準に。これにしないと色が正確に出ない。
• フィルム → 透過、にチェックを入れて、背景を透明にした。

アニメーションをレンダリング。アルファチャンネルを含んだRGBAの連番画像(.png)として出力。

ffmpeg を使って、連番画像を .avi に変換。出力フォーマットは UtVideo。UtVideo は可逆圧縮なので画質劣化が無く、かつ、アルファチャンネルを含めることができる。

ffmpeg -framerate 24 -i render\%04d.png -vcodec utvideo smoke_test02.avi

• -framerate 24 で、24FPSを指定。
• -i render\%04d.png で、renderフォルダ内の 0001.png - xxxx.png を入力ファイルとして指定。
• -vcodec utvideo で、UtVideoフォーマットを指定。
• smoke_test02.avi が出力ファイル名。

これで、連番画像が .avi になった。以下のような動画ができる。




輪郭線を追加する。今回は AviUtl 1.10 + 拡張編集プラグインを使った。拡張編集ウインドウに .avi を追加して、縁取りフィルタを使って輪郭線を追加。ついでに背景も白くする。

以下のような動画が出来上がった。




ということで、blender を使っても、Moho と同様に、煙アニメは作れそうだなと…。

◎ 余談。Freestyleで輪郭線。 :

◎ 余談。相対パスの指定。 :

# usage : ruby checkimage.rb IMAGE_FILE
#         ruby checkimage.rb DIR

DUMP_NORMAL = false

$err_count = 0

#
# 前述のページのソースをここにコピペ
#

def check_and_output(path)
  
  if FileTest.directory?(path)
    pathlist = []
    Dir::entries(path).each do |lpath|
      next if lpath =~ /^\.{1,2}$/
      lpath = path + "/" + lpath
      check_and_output(lpath)
    end
  elsif FileTest.file?(path)
    return unless path =~ /\.(gif|jpg|png)$/
    result = check_file(path)
    lpath = File.basename(path)
    if result[0] == :unknown
      puts "unknown : #{lpath}"
    elsif result[1] == :damaged
      puts "corrupted : #{lpath}"
      $err_count += 1
    elsif result[1] == :clean
      puts "normal : #{lpath}" if DUMP_NORMAL
    else
      puts "illegal : #{lpath}"
    end
  else
    puts "not found #{path}"
  end
end

def hit_enter_key
  puts "\nHit Enter Key"
  s = STDIN.gets
end

def usage
  puts "usage: ruby #{$0} IMAGE_FILE"
  puts "       ruby #{$0} DIR"
end

if $0 == __FILE__
  if ARGV.size == 0
    usage
  else
    ARGV.each do |path|
      puts "check #{path}"
      check_and_output(path)
    end
    puts "\ncorrupted : #{$err_count}"
  end
  
  hit_enter_key
  exit(0)
end

"Image file damage check"    cmd.exe /c ruby checkimage.rb "$P"

• cmd.exe /c hoge で、DOS窓を開いて hoge を実行。
• 「"$P"」で、あふで開いてるフォルダのパスが渡される。

◎ 板を切断。 :

◎ 角回転台を固定。 :

角回転台の片方をネジ止めすると、もう片方のネジ止めが出来なくなる。どうやってネジ止めするんだろうと思ったけど、以下の動画が参考になった。

_Lazy Susan Assembly - YouTube

要は、ネジ止め用の大き目の穴を一つ余計に開けておくことで対処するらしい。ということで自分もチャレンジ。

まずは片方を当ててみて、ネジを埋め込む場所に印をつけて。

反対側のネジ止めもできるように、大き目の穴を、電動ドリル＋テーパーリーマで開けた。

片側をネジ止めしたらひっくり返して、もう片側の板の上に乗せて、先ほど開けた穴からネジとドライバーを入れてネジ止め。

なんとかネジ止めできた。

◎ 六角シャフトを切断。 :

TAMIYA ユニバーサルギヤボックスの六角シャフトは10cmほどあるけれど、今回は5cm程度あれば十分なわけで。できれば六角シャフトを切断して短めにしたい。

先日100円ショップで買ってきた、ダイヤモンドヤスリ平型を使って切断できないか試してみたり。シャフトを挟んで固定するバイスは、ダイソーで買ってきたプラスチック製のバイスを使った。

今回の作業、このバイスがあるのとないのとでは大違いだったなと…。まあ、100円ショップのソレだから、固定が吸盤式でそもそもちゃんと固定できるとは思えないし、挟むための軸部分がプラスチック製なので、おそらく耐久性その他は無さそうだけど。それでも、細い何かしらを挟んで作業するには便利な印象。

しつこくゴシゴシやってたら、ここまで減ってきた。

ある程度削れた時点で、六角シャフトを折り曲げるように力を入れてみたら、千切れてくれた。やった！ なんとかなった。

後は断面をヤスリで削って少し滑らかに。

ということで、100円ショップで売ってるダイヤモンドヤスリの類でしつこくやれば、TAMIYAの六角シャフトを短く切断することも不可能ではなさそう。でもまあ、疲れるけど。

材質が分かれば金ノコとやらで切断できるのかもしれんけど。…待てよ？ ヤスリで削れる時点で、まだ比較的柔らかい材質でできてるということだろうか。それなら金属一般用の金ノコでイケるのかな。どうなんだろ。

◎ ユニバーサルギヤボックスを乗せる。 :

◎ 板を垂直に立てるためのガイドを貼り付け。 :

MDF板を立てて、その上に天井部分を乗せるようにしたい。全部ボンドでガチガチにくっつけてしまうと後から中を弄ろうとした時に困るので、ガイドを作ってMDF板を差し込むようにして分解可能な状態にしておきたい。

ということで、昔ダイソーで買ったと思われる、9x9mmの太さの角棒をテキトーな長さに切って、ガイドとしてボンドで貼り付け。

乾くまで24時間ほど必要らしいので、作業の続きはまた明日。

◎ 入手にかかった期間。 :

◎ 届いた品をメモ。 :

今回は _KSY さんで、以下の品を注文。

• Raspberry Pi 3 Model B ... 5,670円
• Piケース RS for 3/2/B+ 白 ... 972円
• USB電源アダプター 5V/2.5A/1P ... 1,620円
• Raspberry Piシリーズ用ヒートシンク セット ... 540円
• microSDHC Team製 16GB CLASS10 ... 1,080円
• Piカメラ Official V2 for 3/2/1 ... 3,780円

計13,662円(税込)。cameraモジュールも注文してしまったので、ちょっと高くなったけど。本体＋ケース＋電源等の基本製品だけなら9,000円台で揃うはず。というかセットで売ってるからソレを選んだほうがいいと思うけど。

ただ、ちょっと問題が。USB電源アダプタに、USB電源ケーブルがついてくるはずだけど。ケーブルが入ってない…。全部の箱を開けて確認してみたけど、やっぱり入ってない…。

USB電源ケーブルは別売りだったのかなと不安に思って、 _USB電源アダプター 5V/2.5A/1P のページを再確認してみたけど、「USB電源ケーブル付属」と書いてあるよな…。これはたぶん、梱包ミスだな…。

とりあえず、KSYさんにメールでその旨連絡を入れておいたけど、どうなることやら…。「あらまあゴメンナサイ」で済んでくれればいいけど…。

※ 2016/0716追記。KSYさんから別途USB電源ケーブルが届いた、とメモ。対応してくれてありがとう、なのです。

◎ microSDHCの速度を測ってみたり。 :

Raspberry Pi は microSDHC にOSを入れて動かすらしいのだけど、以前は相性問題が起きてたそうで。なので、「相性問題は起きないよ」と謳ってる、Team製の microSDHC (KSY016G0MC28P1) も一緒に注文してみたわけで。

せっかくだから一応速度を測ってみたり。ちなみにカードリーダは、 _BUFFALO BSCRMSDCWH 。USB2.0接続。

-----------------------------------------------------------------------
CrystalDiskMark 5.1.2 x64 (C) 2007-2016 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

   Sequential Read (Q= 32,T= 1) :    20.054 MB/s
  Sequential Write (Q= 32,T= 1) :    17.851 MB/s
  Random Read 4KiB (Q= 32,T= 1) :     3.139 MB/s [   766.4 IOPS]
 Random Write 4KiB (Q= 32,T= 1) :     0.687 MB/s [   167.7 IOPS]
         Sequential Read (T= 1) :    19.715 MB/s
        Sequential Write (T= 1) :    15.310 MB/s
   Random Read 4KiB (Q= 1,T= 1) :     2.596 MB/s [   633.8 IOPS]
  Random Write 4KiB (Q= 1,T= 1) :     0.543 MB/s [   132.6 IOPS]

  Test : 100 MiB [E: 0.0% (0.0/14.7 GiB)] (x3)  [Interval=5 sec]
  Date : 2016/07/13 20:07:40
    OS : Windows 10 Professional [10.0 Build 10586] (x64)
    microSDHC Team 16GB Class10 + BUFFALO BSCRMSDCBK (USB2.0接続)

これは…。速いのか、遅いのか…。どうなんだろう…。どの数値を重視して判断すべきなのか…。

そもそも、このUSB接続カードリーダは、速度的にどうなんだらう。

◎ OSをインストールするための準備。 :

◎ ケースに入れた。 :

◎ microSDHCをスロットに差す。 :

◎ OSをインストールしたいのだけど。 :

◎ OSをインストール。 :

◎ 構成その他。 :

• ブレッドボード BB-801 ... \200
• ブレッドボード・ジャンパーコード(オス-オス)セット ... \220
• ブレッドボード・ジャンパーコード(オス-メス) 15cm(赤) (10本入) ... \220
• 細ピンヘッダ 1x20 ... \20
• マイクロサーボ SG92R ... \500
• モータードライバー TA7291P (2個入) ... \300
• 3mm赤色LED LT3U31P 250mcd 10個入 ... \100
• 圧電スピーカー(圧電サウンダ)(13mm) PKM13EPYH4000-A0 ... \30
• タクトスイッチ(黒色) ... \10
• タクトスイッチ(赤色) ... \10
• トグルスイッチ2回路2接点(ON-ONタイプ) ... \100

python conv_monospc.py BMFontテクスチャ画像.png BMFontのfntファイル.fnt 出力画像ファイル名.png

• Windows7 x64
• Python 2.7.10
• Pillow 2.8.1

• ASCIIコードの範囲のみに対応。
• 配置し直したフォント画像は、各文字をグリッド内の中央に収めてるだけなので、位置が気に入らない場合は別途画像編集ツールで修正を。

◎ 使い方。 :

以下の3ファイルをダウンロード後、〜.scm にリネームして(.txt を削って)、GIMP に追加。

_mecha-bump-tex-gen.scm
_mecha-bump-tex-gen-parts.scm
_mecha-tex-make-up.scm

まず、512x512 とか 1024x1024 で画像を新規作成。

Script-fu -> Utils -> Mecha bump tex gen を実行。

以下のような画像ができます。

件のスクリプトを呼び出すたびに、乱数を使って模様を作り直すので、気に入った模様が出てくるまで何回か呼び出してみてください。

このまま、3DCGソフトのバンプマッピング用テクスチャ画像として使ってもいいのだけど。もうちょっと手を加えます。

Script-fu -> Utils -> Mecha tex make up を実行。

以下のような画像ができます。

色調やコントラストが気に入らない時は、「Merge Layer」のチェックを外せばレイヤー統合せずに処理が終わりますので、レイヤー追加等をして好きなだけ調整していただければと。

◎ 作例。 :

「こんなテクスチャ画像、一体何の役に立つんだよ。使える場面ねえよ」と言われそうな気もするので、一応、このテクスチャ画像を使って、GIMPのみで作業した作例も載せてみたりして。まあ、遠近法変形して、グラデーションをレイヤーでオーバーレイしただけですが。

よく見るとリベットのあたりが不自然ですが、パッと見だけならソレらしく見えるのではないかなー、と。

「このくらいは手描きで描けよ」と絵描きさんにdisられそうな気もするけど、自分にはちょっと無理。

◎ 手描きでやりたい場合。 :

@echo off
@rem ImageMagick を使って写真を手描きイラスト風に変換できるかどうかのテスト
@rem カレントフォルダ中の src??.* ファイルに対して処理を行う。

setlocal enabledelayedexpansion

set OUTSIZE=800x

for %%i in (src*.*) do (
    set SRC=%%i
    set OUTFN=result_%%~ni
    
    echo ----------------------------------------
    echo !SRC! に対して処理をします
    
    echo リサイズ
    convert !SRC! -resize %OUTSIZE% !OUTFN!_tmp1.png

    echo コントラスト調整・彩度調整・色相をずらす
    convert !OUTFN!_tmp1.png -modulate 100,175,110 -contrast -contrast -contrast !OUTFN!_tmp3.png

    echo 手塗り風フィルタをかける
    convert !OUTFN!_tmp3.png -paint 4 !OUTFN!_tmp4_11.png
    convert !OUTFN!_tmp3.png -paint 1 !OUTFN!_tmp4_12.png

    echo 合成
    composite -dissolve 50 !OUTFN!_tmp4_12.png !OUTFN!_tmp4_11.png !OUTFN!_tmp4_2.png
    composite -dissolve 33 !OUTFN!_tmp3.png !OUTFN!_tmp4_2.png !OUTFN!_tmp4_3.png

    echo medianフィルタ
    convert !OUTFN!_tmp4_3.png -median 6 !OUTFN!_tmp5.png

    echo 合成
    composite -dissolve 25 !OUTFN!_tmp5.png !OUTFN!_tmp4_3.png !OUTFN!_tmp6.png
    
    echo !SRC! に対する処理終了
    
)

:END
endlocal

echo 終了

◎ PhotoScapeもイイ感じかもしれない。 :

一発で絵画風フィルタが使える他のソフトはないのかな、と思って検索。もしかすると PhotoScape のフィルタ → 絵画調 → 水彩画もイイ感じかも。

1920x でフィルタをかけてから 800x にした版。ブラシサイズを小さくすれば精密さが上がりそうではある。

◎ _Pedobear こと、海外におけるクマーの捉えられ方 - Vanteyのアース線 (Ver.2.6) :

◎ 名無しさんを表すキャラクターデザインが存在しないのだな。 :

日本においては、匿名のソレを視覚的に象徴するキャラクターデザインが存在していない。海外はアノニマスのマスクという形で存在しているけど。日本国内も、そのうち、アノニマスのマスク＝名無しさんを示すキャラクターデザインとして定着してしまうのだろうか？

個人的には、「TEXT ONLY」と書かれた黒い紙袋を被ったキャラデザ？などもヨサゲな気もするのだけど。

…動きづらいか。いちいち紙袋の角度を直したりしそう。

◎ このあたりが限界。 :

◎ 小型の立体視液晶ディスプレイが欲しい。 :

• 今風に書いても昔風に書いても動作は変わらないじゃないか。
• 今風の書き方を知ってる人は少ないが、昔風の書き方を知ってる人が多いなら、メンテナンスという点では昔風の書き方を選んだほうがメリットがあるのではないか。
• やってることは今までとたいして変わってないのに、単に今風の書き方がされてるというそれだけで、スクリプトを眺めたときに「なんだこれ？」と首を捻るのは馬鹿馬鹿しくないか。
• 今風に書いた時のメリットとデメリットにはどんなものがあるか。デメリットより、メリットのほうが多いと、本当に言える状態なのか。

東京・杉並区は平成18年に公募によって決定した杉並区のマスコットキャラクター「すぎなみアニメキャラクター『なみすけ』」のライセンス管理事業者委託に関する企画提案を募集している。(中略) 公共団体がアニメ風キャラクターをマスコットとすることが増えているが、そのライセンス管理を民間企業に委託するのは珍しい。さらにそれを公募するのは、これまでにない試みである。近年急増する行政や非営利団体のマスコットキャラクターの運用・展開に、一石を投じるユニークな試みとなりそうである。

アニメ産業とビジネスの情報 より

◎ _はてなスター :

◎ _というわけであちこちのはてなダイアリーの星を連打しまくり、うっかり数百とか増やしてたりする。俺は非常に楽しいのだが :

◎ _「はてなスター不要というユーザーよ、はてなを去れ」とjkondoは言った :

◎ _アンカテ(Uncategorizable Blog) - はてなスターリリース記念アンカテjkondo言及集 :

• 「プログラミング」を過程とすると、成果物は「プログラム」。
• 「恋愛」を過程とすると、成果物は「恋愛関係」「性交」「結婚」あたり？。
• 「プログラミング」を自分でしなくても、「プログラム」を利用できる人は居る。というかそういう人が大半。
• 「恋愛」をしなくても「性交」「結婚」する人は居る。が、現代においては異端とされる。
• 「プログラミング」を知らない人にその内容を伝えるのは大変。
• 「恋愛」を知らない人にその内容を伝えるのは大変。と思われてないふしがある。
• 「プログラミング」を知らない人に、「Perlならではのやり方」を伝えられるのか。
• 「恋愛」を知らない人に、「恋愛の極意」「恋愛の心得」その他を伝えられるのか。
• コンピュータを制御するのが「プログラミング」。
• 異性を制御するのが「恋愛」。ではないのだが、それに近いことができるはずだと思われてる場面が多い。
• コンピュータは命令した事しかしない。予想と違う動きをするのは、命令が間違ってるだけ。
• 人間は命令どおりに動かない。
• 「プログラミング」は「恋愛」より簡単。たぶん。
• 万人がプログラマーになれるわけではない。向き不向きがある。
• 万人が「恋愛」はできる。と思われてるふしがある。
• 「恋愛」できない人間は、人として扱われない。異端扱いされる。
• 「プログラミング」ができない人間は、人として扱われない。ということはない。むしろ、「プログラミング」ができる人間は異端扱いされる。
• 「恋愛」は「プログラミング」より難しい。相手は思った通りに動いてくれない。しかし、相手が自律で動いてくれる。

• 「恋愛」にも「Fizz-Buzz問題」があるのではないか。
• 現代における「恋愛」は8bitPC時代に相当。自身がBASIC等を習わなければ目的の処理ができない時代。
• 作業としてはよほど簡単な「プログラミング」すらできない人達が、何の根拠も無く、自分も、または他人も、「恋愛」はできると思い込んでいるのは何故か。

• 「恋愛はプログラミングだ」もしくは「プログラミングは恋愛だ」というフレーズはどうか。
• 「Perlの伝道師」より「PerlとLoveの伝道師」のほうがなんだかカッコイイ気がします。
• 「『LL』の『L』は『Love』だったんだよ！」「なんだってー！」

◎ _Microsoft Outlook、Outlook Express、Eudora または他の電子メールソフトで電子メールを送受信できない (Norton Personal Firewall 使用時) :

◎ 旧PCのHDDも整理してきた。 :

◎ Outlook Express の設定を変更。 :

◎ WindowsUpdateにずいぶん時間がかかる。 :

◎ 一応作業は昼前に終わった。 :

◎ EPIA LN10000EG。 :

◎ _ケーブルの色付きはプラス、黒がマイナス（Gnd） :

◎ Mini-ITXケース ES-1100W。 :

◎ とりあえず組んではみたものの…。 :

◎ 玩具でふと思い出したけど。 :

◎ しまった :

◎ footer の中で margin 指定をすると必ずおかしくなるな :

◎ _Win9xにはwinpopupなるLAN内メッセンジャーがあるらしい :

◎ _IP Messenger :

◎ _ADSL環境の最適化 :

◎ DynDNSで登録 :

◎ ちょっと待て :

◎ マルチPPPoEとDDNS :

◎ _電源と電話回線を守ります :

◎ _ADSLの雷対策 :

◎ _パソコンを雷から守れ！ :

◎ _落雷で被害にあった方の体験談 :

◎ EPSON PM-G700 と Canon PIXUS 560i のカタログスペックの比較もしてたのだけど :

◎ この時期の、例年の天気について :

◎ 腰のベルトにつけてたからマズイのだろうか :

◎ ケースが黒なのも気になる :

◎ なんにせよ :

◎ 福神漬の考案者 :

◎ ネットって凄いな :

◎ なんとなくだけど :

◎ Image::Sizeを使えば画像サイズを取得できるらしい。 :