JURIA @Wiki
@あれこれ-2009年2月
最終更新:
juria
-
view
@あれこれ-2009年1月
[2009-02-23]
というわけで また DllCall &bookmark_hatena(show=none)
画像比較用に縦横サイズとか見られるといいかなあってことで、また DllCall っす。
AutoHotkey にはそういった関数は無いのね。gdiplus.dll を呼べばいいらしい。
AutoHotkey の フォーラム漁ってパクリました^^;
AutoHotkey にはそういった関数は無いのね。gdiplus.dll を呼べばいいらしい。
AutoHotkey の フォーラム漁ってパクリました^^;
sFile := "画像ファイルのパス" ; gdiplus.dll をロードして hGdiPlus := DllCall("LoadLibrary", "str", "gdiplus.dll") if hGdiPlus = 0 Return VarSetCapacity(si, 16, 0) si := Chr(1) ; 初期化 DllCall("gdiplus\GdiplusStartup", "UintP", pToken, "Uint", &si, "Uint", 0) ; パスをユニコード化 VarSetCapacity(wFile, 1023) DllCall("kernel32\MultiByteToWideChar", "UInt", 0, "UInt", 0, "UInt", &sFile, "Int", -1, "UInt", &wFile, "Int", 512) ; 改行なしで ; ファイルからイメージを読み込み DllCall("gdiplus\GdipLoadImageFromFile", "str", wFile, "UintP", pImage) ; イメージの幅と高さを取得 DllCall("gdiplus\GdipGetImageWidth", "UInt", pImage, "UInt*", sWidth) DllCall("gdiplus\GdipGetImageHeight", "UInt", pImage, "UInt*", sHeight) ; イメージを破棄 DllCall("gdiplus\GdipDisposeImage", "Uint", pImage) ; GDI+ をシャットダウン DllCall("gdiplus\GdiplusShutdown" , "Uint", pToken) ; gdiplus.dll を開放する DllCall("FreeLibrary", "Uint", hGdiPlus) scale = %swidth% * %sheight%
GDI+ を使うには、最初に初期化し、最後にシャットダウンしなきゃいけないらしい。
loop の度に Startup/Shutdown する方が loop の前後にするよりパフォーマンスが
良さげ、いえ、そう見えるもんで。。。プログラミングの常識知らず。
loop の度に Startup/Shutdown する方が loop の前後にするよりパフォーマンスが
良さげ、いえ、そう見えるもんで。。。プログラミングの常識知らず。
色んな情報を一覧にするだけでなく、Picture Control の枠に収まるように画像を
アスペクト比維持して縮小したり回転したりとかもできるはずだよなあ・・・。
アスペクト比維持して縮小したり回転したりとかもできるはずだよなあ・・・。
[2009-02-17]
るいじ &bookmark_hatena(show=none)
類似画像検索ってのを初めてやってみた。
「類似」って何を持って類似とするのが普通なんだろ?
普通は、重複や不要画像を排除する(逆に言えば、必要なものだけを残す)ために
類似画像検索を行うものなんでしょうか?
普通は、重複や不要画像を排除する(逆に言えば、必要なものだけを残す)ために
類似画像検索を行うものなんでしょうか?
cprof.exe -r -t77 <target folder>
類似度合い 77% でサブフォルダも含めて検索
回転、リサイズ、(程度にもよるが)トリミング、色調補正を施した画像はもちろん、
同じ被写体を距離や角度を変えて撮影した画像なども「類似」と判定してもらえるので
こんな心配も無縁になるし、 AtPicture での属性付加作業の手間がだいぶ緩和されるで
あろうと期待しちゃってます。
同じ被写体を距離や角度を変えて撮影した画像なども「類似」と判定してもらえるので
こんな心配も無縁になるし、 AtPicture での属性付加作業の手間がだいぶ緩和されるで
あろうと期待しちゃってます。
類似画像群は、report.txt に一行ごとにカンマ(,)区切りでフルパスが列挙されるので
(今後仕様が変わるかもしれないけど)、AutoHotkey で loop しながら、付加する
属性のパターンを listbox から選んで類似画像をまとめてコマンドラインから
AtPicture に登録できるのではないかと、気の早い私は思ったり。
(今後仕様が変わるかもしれないけど)、AutoHotkey で loop しながら、付加する
属性のパターンを listbox から選んで類似画像をまとめてコマンドラインから
AtPicture に登録できるのではないかと、気の早い私は思ったり。
ウチの Windows XP Home SP2 のマシンでは起動できない(所謂強制終了)のが残念。
環境によるのだと思うけど。Windows XP Pro SP2 では問題無しよ。
環境によるのだと思うけど。Windows XP Pro SP2 では問題無しよ。
[2009-02-13]
というわけで また migemo &bookmark_hatena(show=none)
非表示(Gui,Hide)には、そういう効果はあまり無いのだわねぇ。。。
[2009-02-08]
というわけで、はじめての RegExReplace &bookmark_hatena(show=none)
正規表現、苦手なんですよね^^;
ひとりWiki
で作成した EUC-JP なページファイル名を Shift_JIS に変換して一覧表示。
普通の(?)名前のファイルがあると笑えます。それと、なぜか、タイムスタンプが
化けるのでコメントにしてます^^;
普通の(?)名前のファイルがあると笑えます。それと、なぜか、タイムスタンプが
化けるのでコメントにしてます^^;
これなら migemo もいけるかも。
[2009-02-06]
どうやら &bookmark_hatena(show=none)
さっきのやつ、AutoHotkey が落ちるのは、どうやらコード種別の自動判別の所為っぽい。
guess := DllCall("nkf32.dll\NkfGetKanjiCode")
をはずせば大丈夫です^^;
もしかしたら、--url-input オプション(% に続く 16 進数を文字に変換)で
ファイル名そのものをいじって、 Shift_JIS に変換して表示できるかも。
ファイル名そのものをいじって、 Shift_JIS に変換して表示できるかも。
はじめての DllCall &bookmark_hatena(show=none)
長年の懸案事項にやっと手をつけた。
ひとりWiki
のファイル名。
ひとりWiki
でページを作成するとファイル名が EUC-JP の文字コードベースになる。
ファイラやエディタからファイルを開きたい時など呪文のよう。手軽にファイル名を
エイリアスやタグで管理できる(実体をデータベース化する必要はない)ソフトが
見つからないので、 ひとりWiki のデータフォルダ内のファイル一覧をテキストの
一行目で見て他のソフトにパスを渡せる AHK スクリプトを書いた。
ファイラやエディタからファイルを開きたい時など呪文のよう。手軽にファイル名を
エイリアスやタグで管理できる(実体をデータベース化する必要はない)ソフトが
見つからないので、 ひとりWiki のデータフォルダ内のファイル一覧をテキストの
一行目で見て他のソフトにパスを渡せる AHK スクリプトを書いた。
簡単にやっつけてから気づいたんだけど、
ひとりWiki
使い出した当初、内蔵エディタで
書いた原稿テキストは EUC-JP、その後標準エディタ(#1)で編集するようになってから
Shift_JIS と、保存してあるテキストファイルの文字コードが2種混合なのだ。
書いた原稿テキストは EUC-JP、その後標準エディタ(#1)で編集するようになってから
Shift_JIS と、保存してあるテキストファイルの文字コードが2種混合なのだ。
んで、
nkf32.dll
を DllCall してみることに。
NkfConvertSafe がうまく使いこなせないので NkfConvert でやってるんだけど
コード種別の自動判別(NkfGetKanjiCode)で誤判定がけっこうある。入力コードを
EUC(-E) と指定すると変換精度が上がるが(#2)、2種混合な故にそれもできない。
NkfConvertSafe がうまく使いこなせないので NkfConvert でやってるんだけど
コード種別の自動判別(NkfGetKanjiCode)で誤判定がけっこうある。入力コードを
EUC(-E) と指定すると変換精度が上がるが(#2)、2種混合な故にそれもできない。
ただでさえパフォーマンス的にはあまり良くないみたいで、AutoHotkey.exe がすぐ
落ちる。(ので、変換結果を一覧に出力するのはやめたほうが無難)
あらかじめ文字コード判別して分岐するとどうなるのか。。。
落ちる。(ので、変換結果を一覧に出力するのはやめたほうが無難)
あらかじめ文字コード判別して分岐するとどうなるのか。。。
いっそのこと、文字コードを Shif_JIS に変換、改行コードを CRLF に変換、
nkf.exe -sc --overwrite 40A4A2A4ECA4B3A4EC.txt
とかしてしまおうか。(--overwrite でタイムスタンプは変更されない。)
WikiTitleViewer.ahk
; ひとりWiki のデータフォルダ datadir = E:\HTML\PukiWiki Gui, Font, , M+2VM+IPAG circle Gui, 1:Add, ListView, x1 y1 w360 h201 -Multi AltSubmit vTitle gTitle, alias| modified|file Loop, %datadir%\*.txt { filetime = %A_LoopFileTimeModified% FormatTime, filetime, %filetime%, ShortDate FileReadLine, firstline, %A_LoopFileFullPath%, 1 LV_Add("" , firstline, filetime, A_LoopFileName) LV_ModifyCol(1,"Sort Auto") } Gui, Add, StatusBar, gStatusBar SB_SetParts(40) ; ステータスバーの分割幅指定 num := LV_GetCount() SB_SetText(A_Space num, 1) ; ステータスバーにファイル数表示 Gui, Show, x232 y205 h226 w362, Wiki Title Viewer Return Title: if A_GuiEvent = DoubleClick { LV_GetText(line, A_EventInfo, 1) LV_GetText(filepath, A_EventInfo, 3) ; SB_SetText(filepath, 2) inStr = %line% ; nkf32.dll をロード。パスを通してない場合はフルパスを指定 hModule := DllCall("LoadLibrary", Str, "path\to\nkf32.dll") ; shift-jis に変換 DllCall("nkf32.dll\SetNkfOption", "Str", "-s") DllCall("nkf32.dll\NkfConvert", "Str", inStr, "Str", inStr) ;文字コード変換判定 guess := DllCall("nkf32.dll\NkfGetKanjiCode") ; 0:シフトJIS, 1:EUC, 2:ISO-2022-JP, ; 3:UTF-8, 4:UTF-16LE, 5:UTF-16BE SB_SetText(inStr, 2) ;開放する DllCall("FreeLibrary", UInt, hModule) MsgBox, %A_EventInfo% is `n ファイル名:%filepath% `n 変換前:%line% `n 変換後:%inStr% `n 文字コード判定:%guess% Run, %datadir%\%filepath% } Return GuiEscape: ;ButtonCancel: GuiClose: ExitApp
-