d.sunnyone.org
sunnyone.org

ページ

2012-10-21

テキトーに使うWCF

WCFのちょっとした実験をしたいとか、ちょっとしたプロセス間通信をしたいといったときに、app.configだとかServiceReferenceだとかはわずらわしい。そんなときに使うコードサンプル。




投稿者 時刻: 0 件のコメント:
ラベル:

2012-10-10

自炊向け本画像処理スクリプト群bkimgproc公開

前回のエントリで予告した、ImageMagickのwrapper script群を公開しました。
https://github.com/sunnyone/bkimgproc
git cloneするか、"ZIP"のボタンを押してzipを落として展開してください。

本1冊ごとにディレクトリを作って連番の素材を入れていき、最後にスクリプトを実行するとまとめてくれるツールです。詳しい使い方は、READMEに載せました。

Ubuntu/DebianであればREADMEの方法で使えますが、普通のshell scriptなので、もしかしたらCygwinでも動くかもしれません。

特徴としては、以下の通りです。
  • pdf, cbz出力(PDFは見開き方向指示に対応)
  • 横向きスキャンデータの回転
  • 白レベル自動判定による白レベル調整
  • kobo向けリサイズ(kobo plugin)
  • 余白の自動カット(kobo plugin)
  • テキストのボールド化(kobo plugin)
使い方にも書いてありますが、白レベル判定は、配置したPDFを単位に行うことで、確実性を高めています。なお、PDFの中でも、偶数と奇数ページで白さが違うことがあったので、別々に判定して対応しています。

PDFの見開き方向指示は、こちらの方法を利用させていただいています。

ちなみにうちでは、convall.shの起動は、Jenkinsを使っています。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2012-09-27

ImageMagickで紙の白レベルを判定する

今日は、一部で「美白化」と呼ばれる、もともと白かった紙の色褪せた部分を白くする処理について。白くするには、どれだけ白っぽくするか、すなわち白とする基準を指定する必要があるが、ImageMagickを利用して、どのレベル以降を白と見做すか判断する方法について、この記事で述べる。

結果だけ使いたい方は、判定ロジックのシェルスクリプトを最後に載せているのでどうぞ。
実行すると、このようになる(以下は95%だった例)
$ ./whitelevel.sh test.jpg
95

この方法(+α)で運用しているが、かなりうまく動いている。

背景

ImageMagickを使って美白化をする例はいくつかWeb上にもあり、-levelを使ってパーセンテージ指定で白レベルを指定するか、-linear-stretchを使ってハイライト側のピクセル数から判断する方法があった。しかし、前者は紙によって異なるし、後者は白い部分が少ない画像で悲しい思いをする可能性があるので、実際の画像から白のレベルを決めたい、というのが背景である。

方針

直感的に言えば、白っぽい部分はヒストグラム上は山になっているはずなので、その直感の方法に合わせて、ヒストグラムを作成し、グラフの傾きから計算すればできそうである。しかし、「ImageMagickでヒストグラムを出力し、数値を計算可能な状態にparseする」「数値をもとに山を求める」というののどちらも面倒くさい。しかも、実際に画像を見てみると、白部分がなだらかだったりして、山になっていないこともある。

ちょっと困っていたが、画像を見ていてふと
「はじっこ(枠)って白くね？」
「ImageMagickって枠切りとれるわ」
という2点に気付き、枠を切り出し、その色を白とすることを思い立った。

もう少し具体的な方針を書くと、以下の通りである。
  1. convertコマンドの-trimを利用して、画像全体のサイズと枠の切り出し座標を得る。
  2. 枠のサイズが、白レベルを判定するのに十分であるかを確認する。
  3. 枠を切り出し、色の平均レベル(μ)と、標準偏差(σ)を算出する。
  4. μ-3σ(正規分布における99.73%の点)を得て、白レベルとする。
  5. (得られたレベルと-levelを利用して、美白化する。)

なお、紙の横方向(綴じてあるほうと、その反対側)は、均一でないことがあるので、余白は上下を用いる。

手順

1. convertコマンドの-trimを利用して、画像全体のサイズと切り出し座標を得る

まず、convertコマンドでは、-trimを使うと、余白を切り取ることができる。
-fuzzオプションを併せて利用すると、その範囲を誤差と見做してくれる。
例としては、以下の通り。
$ convert -trim -fuzz 40% hello.jpg hello-trim.jpg

こんな画像が:

こうなる:


さらに、convertコマンドでは、info:を出力先にすると、画像を出力する代わりに、画像の情報を吐き出してくれる。
$ convert -trim -fuzz 40% hello.jpg info:
hello.jpg JPEG 1338x719 1792x1076+184+136 8-bit DirectClass 0.020u 0:00.010

実は、必要な情報は含まれているので、このままでもいいのだが、-formatというオプションを利用すると、出力フォーマットを調整できる。

まずは、以下の情報を使う。
%H   page (canvas) height
%Y   page (canvas) y offset (including sign)
%h   current image height in pixels
それぞれ、「元画像の高さ」「切り出し縦オフセット」「切り出された画像の高さ」である。

$ convert -trim -fuzz 40%  hello.jpg  -format "%H %Y %h" info:
1076 +136 719

これで、切り出しサイズが得られた。

2. 枠のサイズが、白レベルを判定するのに十分であるかを確認する

端から黒かったりすると、白レベル判定に不十分なので、1.で得たサイズが妥当かどうか、確認する。
上記のサイズから計算するだけなので詳細は省くが、今は、高さが全体の1%以下あるいは25%以上の場合は、白レベル判定不能にしている。

3. 枠を切り出し、色の平均レベル(μ)と、標準偏差(σ)を算出する

サイズ情報を得ているので、-cropを使って画像を切り出し、また-formatとinfo:を使って白部分の平均と標準偏差を得る。今回は、以下の指定を使う。

%[mean]                 CALCULATED: average value statistic of image
%[standard-deviation]   CALCULATED: standard-deviation statistic of image

コマンドとしては、ボールド化のときに使った彩度をゼロにする-modulate 100,0を併せて、以下の形(わかりやすさのため改行を入れている)。
$ convert hello.jpg \
  -modulate 100,0 \
  '(' -clone 0 -crop x$TOP_BLANK+0+0 ')' \
  '(' -clone 0 -crop x+0+$BOTTOM_OFFSET ')' \
  -delete 0 \
  -append -format "%[mean] %[standard-deviation]" info:
64209.3 671.804

これは、上下の双方が白レベル判定として有効だったときで、上下をそれぞれ切り出し、もとの画像を削除したあと、くっつけて情報を得ている。$TOP_BLANKは%Yの値で、$BOTTOM_OFFSETは%Y + %hの値である。

4. μ-3σ(正規分布における99.73%の点)を得て、白レベルとする

この得られた白い部分は、ちゃんと白だけの画像であれば、正規分布だろうと想定して、正規分布では99.73%の値をカバーできる、μ-3σの点を白と判断する。
正規分布のイメージはこちら等で: http://www.cap.or.jp/~toukei/kandokoro/html/14/14_2migi.htm

上記の例では、64209.3 - 3 * 671.804 = 62193.888である。
Maxが65535なので、パーセンテージにすると、655.35で割って、62193.888 / 655.35 = 94.901...である。

これで、95%というレベルが得られた。

(5. 得られたレベルと-levelを利用して、美白化する)

端から色がついていたりして、取得できない画像があるので、もう少し工夫が必要なのだが、一応得られたものを適用するには、-levelを利用して、以下のように処理できる。
$ convert -modulate 100,0 -level ,94% hello.jpg hello-white.jpg

実際にこれを使って白くしたものがこちら。

実装

上記を実装したスクリプトは、以下の通り。


よりうまく使うには

よりうまく使うには、単体の画像ではうまくいかず、画像群に対して使うのが妥当なのだけど、それをするとスクリプトを使う前提の説明がしんどいのでここでは省く。

実は何度か紹介してきたような方法を組合せて、決まった置き方をすると自動で本をまとめるスクリプト群ができていて、うまく動いているのだけど、PDF対応中なので、近日公開予定。


投稿者 時刻: 0 件のコメント:
ラベル: ,

2012-09-22

画像分割ツールKiritoriMage公開

画像分割ツールKiritoriMage version 0.0.1をリリースした。GUIアプリケーションのフリーソフトウェアの新規リリースは、もう10年ぶりくらいになる。

http://github.com/sunnyone/kiritorimage/
ダウンロード: https://github.com/downloads/sunnyone/kiritorimage/KiritoriMage-0.0.1.zip

どんなソフトウェアかというと、区切り線を指定して、その区切られた領域をクリックしていくことで、画像を分割していくツール。以下の画像を見てもらえれば、どんなアプリケーションかわかると思う。


たいていの画像処理ソフトは、1回の保存オペレーションでひとつの範囲しか保存できないのに対し、このツールは複数の範囲が保存できるのが特徴。ちなみに、mageと呼ぶほどすごいことはできない。

自分用なので、保存形式がJPEG固定だったり、保存フォルダは画像と同じフォルダのみ(実は裏技があるのだけど)だったりと、制限は多いのだけど、ひとまずは使えるようになったので公開。

MITライセンスにしているので、改変や再配布も自由。もし拡張とかあればpull requestしてもらえれば。

投稿者 時刻: 0 件のコメント:
ラベル: , , ,

2012-09-09

Taoを使ってC＃/WPFでゲームパッドのボタンを読み取る

ちょっとしたツールを作るために、ゲームパッドをC#で書いたWPFアプリケーションから読もうと思ったが、意外とすっきりいかなかった。結論としては、Tao Frameworkというフレームワークに含まれるWin32 APIのwrapperを使うことで、気軽に読める。

---

ゲームパッド (Joystick? Joypad?)を読むにはDirectInputが定番らしくて、たしかに簡単そうに見えたのでチャレンジしてみたのだけど、managed DirectXを.NET 4で使うにはapp.configを書き替えないといけないとか、SetCooperativeLevelの第一引数がWindows.Windows.Forms.Controlだったりする罠(HWNDも取れるので実は後述の方法でいけるのだけど)にあったりして、挫折した。

ゲームパッドを読むためのAPIがWin32のwinmmというのにあるらしいとわかったが、P/Invokeの定義を書くのが面倒なので探してみたら、Tao Frameworkというゲーム用のフレームワークに定義されているらしい。調べてみると、MITライセンスなので使うことにした。

簡単な使い方

Joystick系のAPIはTao.Platform.Windowsに入っている。Tao Frameworkにはインストーラもあるのだけど、このdllを参照追加すればいいだけなので、zipを落としてdllだけ横に置くのが簡単でいいと思う。

参照追加したら、JOYINFO構造体をnewして、joyGetPos()というメソッドにjoypad IDをセットで渡せばおわり。IDはただの0からの連番。なお、joyGetNumDevs()は、つながっているデバイスの数を返すわけじゃないから注意だ。

for (int i = 0; i < Tao.Platform.Windows.Winmm.joyGetNumDevs(); i++)
{
    Tao.Platform.Windows.Winmm.JOYINFO joyinfo = new Tao.Platform.Windows.Winmm.JOYINFO();
    if (Tao.Platform.Windows.Winmm.joyGetPos(i, ref joyinfo) == Tao.Platform.Windows.Winmm.JOYERR_NOERROR)
    {
        this.textBlock1.Text += String.Format("Joypad[{0}] detected. Button: {1}\n", i, joyinfo.wButtons);
    }
}
パッドによってはもっと詳しい情報が取れるjoyGetPosEx()もあるらしい。自分の用途にはその必要がなかったので使わなかったけど、このへんのAPIの使い方についてはこのへんに書いてある。

イベント的に読み取る1: タイマーで読み取る

もうちょっと実用的に使うために、押されたことを検知したい。

API的には、joySetCapture()というメソッドがあり、これを使うと、ウィンドウメッセージを飛ばすことができる。しかし、引数からしてポーリングっぽい感じなので、WPFアプリケーションであれば、HWNDとか意識しなくていいので、タイマーで見たほうが素直だと思うのでそうした。実装はこのような感じ。


イベント的読み取る2: joySetCaptureで読み取る

それでもjoySetCaptureが使いたいならば、こんなかんじ。 一応動いた。
投稿者 時刻: 0 件のコメント:
ラベル: ,

x86/x86_64関数呼び出しチートシートを書いた

アセンブラはいまのところたまにしか触れないので、espとebpってどっちがどっちだっけとか、ebpからプラスとマイナスはどっちがどっちだっけとか、触れるたびに思ってしまう。そんなとき思い出すために、x86/x86_64関数呼び出しチートシートを書いた。呼び出し規約(calling convention)のcheet sheetみたいになってるけど、一番必要だったのは左上のスタックの絵。
(リンクでPDF。書く都合でA3にしたけど、A4で印刷しても読めると思う。)


本当はそれぞれに対して絵をつけたかったんだけど、それどころではなかった。
勉強のために書いたくらいで全然詳しくないので、間違っているところがあればぜひ教えてくださいまし。

以下余談。

興味深いのは、64bit版のcl.exe(on Windows)とgcc(on Linux)の挙動の違い。関数の引数をスタックにpushするときに、cl.exeではraxに入れてからメモリに置くんだけど、gccはDWORDで区切ってそのままメモリに置く。最適化なし(/Odと-O0)なので、-O2とかにすればまた違うんだろうけどね。

cl.exe版(cl /Od /Zi)：
  0000000140001030: 48 83 EC 58        sub         rsp,58h
  0000000140001034: 48 B8 08 00 FF FF  mov         rax,0AAAAFFFF0008h
                    AA AA 00 00
  000000014000103E: 48 89 44 24 38     mov         qword ptr [rsp+38h],rax
  0000000140001043: 48 B8 07 00 FF FF  mov         rax,0AAAAFFFF0007h
                    AA AA 00 00
  000000014000104D: 48 89 44 24 30     mov         qword ptr [rsp+30h],rax
  0000000140001052: 48 B8 06 00 FF FF  mov         rax,0AAAAFFFF0006h
                    AA AA 00 00
  000000014000105C: 48 89 44 24 28     mov         qword ptr [rsp+28h],rax
  0000000140001061: 48 B8 05 00 FF FF  mov         rax,0AAAAFFFF0005h
                    AA AA 00 00
  000000014000106B: 48 89 44 24 20     mov         qword ptr [rsp+20h],rax
  0000000140001070: 49 B9 04 00 FF FF  mov         r9,0AAAAFFFF0004h
                    AA AA 00 00
  000000014000107A: 49 B8 03 00 FF FF  mov         r8,0AAAAFFFF0003h
                    AA AA 00 00
  0000000140001084: 48 BA 02 00 FF FF  mov         rdx,0AAAAFFFF0002h
                    AA AA 00 00
  000000014000108E: 48 B9 01 00 FF FF  mov         rcx,0AAAAFFFF0001h
                    AA AA 00 00
  0000000140001098: E8 6D FF FF FF     call        @ILT+5(callee)

gcc版(gcc -O0)：
  400498:       48 83 ec 20             sub    rsp,0x20
  40049c:       c7 44 24 08 08 00 ff    mov    DWORD PTR [rsp+0x8],0xffff0008
  4004a3:       ff
  4004a4:       c7 44 24 0c aa aa 00    mov    DWORD PTR [rsp+0xc],0xaaaa
  4004ab:       00
  4004ac:       c7 04 24 07 00 ff ff    mov    DWORD PTR [rsp],0xffff0007
  4004b3:       c7 44 24 04 aa aa 00    mov    DWORD PTR [rsp+0x4],0xaaaa
  4004ba:       00
  4004bb:       49 b9 06 00 ff ff aa    mov    r9,0xaaaaffff0006
  4004c2:       aa 00 00
  4004c5:       49 b8 05 00 ff ff aa    mov    r8,0xaaaaffff0005
  4004cc:       aa 00 00
  4004cf:       48 b9 04 00 ff ff aa    mov    rcx,0xaaaaffff0004
  4004d6:       aa 00 00
  4004d9:       48 ba 03 00 ff ff aa    mov    rdx,0xaaaaffff0003
  4004e0:       aa 00 00
  4004e3:       48 be 02 00 ff ff aa    mov    rsi,0xaaaaffff0002
  4004ea:       aa 00 00
  4004ed:       48 bf 01 00 ff ff aa    mov    rdi,0xaaaaffff0001
  4004f4:       aa 00 00
  4004f7:       e8 06 00 00 00          call   400502

たぶん、movは即値ではQWORDに詰められないんだろうね。

おまけとして、別のアーキテクチャでやったらどうか？ということで、x86版のCコードをARMで試してみた。
00008398 <caller>:
    8398:       e92d4800        push    {fp, lr}
    839c:       e28db004        add     fp, sp, #4
    83a0:       e24dd008        sub     sp, sp, #8
    83a4:       e59f0020        ldr     r0, [pc, #32]   ; 83cc 
    83a8:       e59f1020        ldr     r1, [pc, #32]   ; 83d0 
    83ac:       e59f2020        ldr     r2, [pc, #32]   ; 83d4 
    83b0:       e59f3020        ldr     r3, [pc, #32]   ; 83d8 
    83b4:       eb000008        bl      83dc 
    83b8:       e1a03000        mov     r3, r0
    83bc:       e50b3008        str     r3, [fp, #-8]
    83c0:       e24bd004        sub     sp, fp, #4
    83c4:       e8bd4800        pop     {fp, lr}
    83c8:       e12fff1e        bx      lr
    83cc:       ffff0001        .word   0xffff0001
    83d0:       ffff0002        .word   0xffff0002
    83d4:       ffff0003        .word   0xffff0003
    83d8:       ffff0004        .word   0xffff0004

000083dc <callee>:
    83dc:       e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    83e0:       e28db000        add     fp, sp, #0
    83e4:       e24dd01c        sub     sp, sp, #28
    83e8:       e50b0010        str     r0, [fp, #-16]
    83ec:       e50b1014        str     r1, [fp, #-20]
    83f0:       e50b2018        str     r2, [fp, #-24]
    83f4:       e50b301c        str     r3, [fp, #-28]
    83f8:       e51b2010        ldr     r2, [fp, #-16]
    83fc:       e51b3014        ldr     r3, [fp, #-20]
    8400:       e0823003        add     r3, r2, r3
    8404:       e50b300c        str     r3, [fp, #-12]
    8408:       e51b200c        ldr     r2, [fp, #-12]
    840c:       e51b3018        ldr     r3, [fp, #-24]
    8410:       e0633002        rsb     r3, r3, r2
    8414:       e50b300c        str     r3, [fp, #-12]
    8418:       e51b200c        ldr     r2, [fp, #-12]
    841c:       e51b101c        ldr     r1, [fp, #-28]
    8420:       e0030291        mul     r3, r1, r2
    8424:       e50b3008        str     r3, [fp, #-8]
    8428:       e51b3008        ldr     r3, [fp, #-8]
    842c:       e1a00003        mov     r0, r3
    8430:       e28bd000        add     sp, fp, #0
    8434:       e8bd0800        pop     {fp}
    8438:       e12fff1e        bx      lr

さすがに違うね。

投稿者 時刻: 0 件のコメント:

2012-09-04

Ubuntu 12.04のGNOMEのメディア自動マウントを無効化する

自動マウントは便利といえば便利なのだが、ファイルシステム復旧のようなセンシティブな作業をしているときにやられると困る場合がある。その際に、無効化するには、以下のコマンドを実行する。
$ gsettings get org.gnome.desktop.media-handling automount
true    ←有効の状態
$ gsettings set org.gnome.desktop.media-handling automount false
$ gsettings get org.gnome.desktop.media-handling automount
false   ←無効になった

うーん、SDカードまた壊れたっぽい。早いなぁ…
[   68.000883] mmcblk0: retrying using single block read
[   68.015714] mmcblk0: error -84 sending status comand
[   68.020530] mmcblk0: error -110 sending read/write command, response 0x900, card status 0x1001201
[   68.029647] end_request: I/O error, dev mmcblk0, sector 1082526
[   73.025586] mmc0: Timeout waiting for hardware interrupt.
[   73.031015] mmc0: hw_state=0x22f8, intr_status=0x0811 intr_en=0x4002
[   73.037895] mmcblk0: error -84 sending status comand
[   73.042710] mmcblk0: error -110 sending read/write command, response 0x900, card status 0x80000980
[   73.051924] mmcblk0: error -110 transferring data, sector 1082527, nr 31, card status 0x80000980
[   73.060763] end_request: I/O error, dev mmcblk0, sector 1082527

参考：http://www.liberiangeek.net/2012/05/windows-7-vs-ubuntu-12-04-how-to-disable-auto-mount-on-media-insertion/
投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)