These pages are written by only Japanese.

Welcom to My Diary.com
最新の日記タイトル一覧カテゴリ別タイトル一覧トップへ戻る〜

こんばんわ♪ 現在は9月23日(月)3時49分。 そろそろお休みになられたほうが。


hns - 日記自動生成システム - Version 2.19.5 (色々 Fixed)

先月 2008年09月 来月
01 02 03 04 05 6
07 08 09 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
Namazu for hns による簡易全文検索です。
詳細は 詳細指定/ヘルプをご参照下さい。
検索式:

2008年09月21日(日)

giflib の使い方 (4)

読み込みや書き出しの方法として、大雑把に2つあります。

順次読み出し:

giflib/util 以下の gifrotat.c と gifrsize.c で使っている方式です。
while ((DGifGetRecordType(&GifFile, &RecordType)) &&
       (RecordType != TERMINATE_RECORD_TYPE)) {
    switch(RecordType) {
      case SCREEN_DESC_RECORD_TYPE:
        DGifGetScreenDesc(&GifFile);
        break;
      case IMAGE_DESC_RECORD_TYPE:
        DGifGetImageDesc(&GifFile);
        break;
      case EXTENSION_RECORD_TYPE:
        DGifGetExtension(&GifFile, &GifExtCode, &GifExtension);
        while ((GifExtension != NULL) &&
	       (DGifGetExtensionNext(&GifFile, &GifExtension) == GIF_ERROR)) ;
        break;
      default:
       break;
}
こんな感じ。
尚、case の中で DGifGet... 系を呼ばないと、 次の DGifGetRecordType で失敗します。
parse 処理を想像すれば仕方ないですが、途中 parse を飛ばせないって事で。
出力は、D(Decode) を E(Encode)に、そして Get を Put に変更すれば大体 OK.

まとめ読み出し:

入力(Decode)は
DGifSlurp(&GifFile);
出力(Encode)は
EGifSpew(&GifFile);
どちらもその関数の中で順次読み出し/書き出しをしてるだけです。
続き

2008年09月22日(月)

最小公倍数

↑このツールで複数GIFファイルのフレーム数の最小公倍数を算出する必要があるので、 とりあえずそれっぽいのを実装。
確か、お互いに引き算し合って残った数値がそれとかいう理屈だったので。 そのままコードにしてみる。 何となく動いてる感じ。
% ./a.out 6 8
gcd(6, 8) => 2
lcm(6, 8) => 24
ふと、ユークリッドの互助法を思い出し google の検索で以下のページを発見。 なるほど。余りを使ってもよいですね。 これで多分、OK
最後の (a > b)?a:b は 片方が0のはずなので a+b でいいかなとか 一瞬誘惑にかられましたが、後で混乱するのであえてこのままで。 *1
あと、確か、もっと速いアルゴリズムがあったと思いますが、 そこそこ複雑だったはずなので、 性能面が問題になるまではこのコードで行きます。
*1: (a)?a:b という手もあったか…

2008年09月23日(火)

giflib でフィルタ処理 (2)

フィルタを作る準備としてとりあえず、Encode/Decode だけするプログラムを 順次処理方式と、そうでない方式で作成してみました。 後者の方がシンプルなコードになるけど、 処理を最小にしようとすると前者を使うしかないかも。
状況によって使い分けって事で。

補足:

念の為に補足しとくと、EGifOpenFileHandle に stdout を渡した方が シンプルになりますが、データ配列のままごにょごにょする予定なので、 こんな回りくどいコードになってます。
swfed でも流用するつもりですし。(*'ω'*)

Close 処理が微妙な…:

GIFアニメはカラーマップをグローバルなのと別にフレーム毎(ローカル)に持てますが、 グローバルなのと最終フレーム(←終了時に処理対象カーソルが指してるフレーム) のカラーマップしか Free してないような… (´Д`;)
582 DGifCloseFile(GifFileType * GifFile) {
	<略>
600     if (GifFile->Image.ColorMap) {
601         FreeMapObject(GifFile->Image.ColorMap);
602         GifFile->Image.ColorMap = NULL;
603     }
604 
605     if (GifFile->SColorMap) {
606         FreeMapObject(GifFile->SColorMap);
607         GifFile->SColorMap = NULL;
608     }
多分、正しくは↓このはず。
for ( i = 0 ; i < GifFile->ImageCount ; i++ ) {
    GifImageDesc *ImageDesc = & GifFile->SavedImages[i].ImageDesc;
    if (ImageDesc->ColorMap) {
        FreeMapObject(ImageDesc->ColorMap);
        ImageDesc->ColorMap = NULL;
    }
}

if (GifFile->SColorMap) {
    FreeMapObject(GifFile->SColorMap);
    GifFile->SColorMap = NULL;
}
でも、何か勘違いしてるのかなぁ…
そんな分かりやすい不具合があったら 誰か困って即刻直りそうですし。
又は、実際のところ、 フレーム毎にカラーマップを持つ GIF アニメ自体絶滅種 (形式的にはありうるけど、実際には作られないorまともに動かない)ので、 頑張っても無駄とか。(無駄な所を頑張るのは好きなのでむしろ嬉しいけどw)
不安なので、SavedImages のデータ構造を生成してる場所、 よくチェックしておこ。

2008年09月24日(水)

Skype API wrapper class (PHP) を試してみた (4)

何時の間にか作者に捕捉されてましたw github での fork & pull をお望みのようなので、 github にアカウントを作成 *1 して、何も考えず fork 。 手元に持ってきて手動 merge 開始。
git clone git://github.com/yoya/php-skype.git
適当にいじって動かすのは簡単ですが、 commit を意識するなら真面目にいじらないとです。
例えば、Char.php の配列のメッセージを追加するにも並び順 (このコードの場合、どの protocol version で追加されたものか) を崩す訳にはいきませんし。
とりあえず間違えようのない *2 debug メッセージを isDebug で分岐する所だけでも、 時間を見つけて commit してみようかしら。
*1: 自分のピクチャを貼り付けたいけどメニューが見つからず。むー。
*2: とはいいつつ、(isDebug() == false) とか (isDebug() == FALSE) とか、 (isDebug() === false) か、はたまた (! isDebug()) にするかは 周りのコードにあわせた方が良いので、 間違いようが無いというのは言いすぎかも。
見たところ、一番初めのもののようでした。 まぁ、自分も一番初めのが好きですし、そもそも (! isDebug()) は C 言語脳的っぽくて嫌んですが。:)


2008年09月25日(木)

PHP で 3D plot

GIF 画像合成では減色処理が必要になるので、 減色アルゴリズムの検証として色んな画像ファイルに対して、 R,G,B ヒストグラムを 3D にマッピングしてみようかと、 軽く 3D plot 処理を考えていたところ、 以下の PHP ライブラリを紹介してもらいました。 早速実験。
$x_axis = $world->createObject('cube', array(128, 4, 4));
$x_axis->setColor(new Image_3D_Color(255, 100, 100));
$x_axis->transform($world->createMatrix('Move', array(64, 0, 0)));
$y_axis = $world->createObject('cube', array(4, 128, 4));
$y_axis->setColor(new Image_3D_Color(100, 255, 100));
$y_axis->transform($world->createMatrix('Move', array(0, 64, 0)));
$z_axis = $world->createObject('cube', array(4, 4, 128));
$z_axis->setColor(new Image_3D_Color(100, 100, 255));
$z_axis->transform($world->createMatrix('Move', array(0, 0, 64)));
うーん。とりあえず軸を書いてみたのですが、使うのめんどいし、 スケールが把握できないです。。(64 の値は探って見つけた値。。)
線(という考え自体ダメダメですが ^^;)をひくにも、 ココからココって指定できなくて、 物体を置いた後に移動(必要なら回転も)しなきゃだし。
そもそもオーバースペックな感じがします…

自分で作っちゃえ:

イメージ図。(図の d は微分ではなく、distance の頭文字です。ごめんなさい)

簡単なグラフを書くのが目的なので、
  • ワイヤーフレームのみで Zバッファ無し
  • 座標変換は世界座標へのオイラー角回転のみ
  • カメラ位置決めうち = (0, 0, $distance_to_eye)
  • その他、一般的な 3D API は殆ど(一切といっていいかも)無し
という究極の手抜きっぷりの簡易3Dライブラリを作ってみました。 仕様は↓こんな感じ。
  • スケールは全て pixel 単位
  • モニタ表面から自分の目までの物理距離は明示的に指定
  • 画像の中央を (0, 0, 0) の原点として計算する
  • x軸は右方向、y軸は上方向、z軸は手前方向。(右手座標系)
  • 一応、原点を中心とした回転は出来る。(x軸, y軸, z軸 の順で適用)
  • 任意の色で点を打てる。任意の色で線が引ける
自分の用途にはこれで十分。これ位なら 30分で作れますし。:-)
続く

2008年09月26日(金)

Skype on Linux がメモリを使いすぎる問題

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31651 yoya      16   0  782m 652m 3164 R  0.7 65.2 194:34.40 skype
えーっと… メモリ1G で 65% 食ってるのって、幾らなんでも太りすぎ。(´Д`;)

Skype 再起動:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25343 yoya      15   0 80376  33m  11m S  1.0  3.3   0:02.03 skype
とりあえず、原因を切り分ける為に Skype bot を止めました。

あたし彼女のガイドライン

乗り遅れないように若者文化を勉強勉強と…
90 :水先案名無い人 :2008/09/25(木) 16:41:54 ID:32KaDK9t0
ガイドライン来て判ったこと。
さんざん馬鹿にしておきながら
原作を超えてない点…
確かにある意味才能だよね。 共感は出来ないけど。^^;

参考:


2008年09月27日(土)

GIF画像の色分布表示

これ の続き
4次元ヒストグラムを作っても見難そうなので、頻度情報は諦めて、 使っている色を RGB=XYZ 空間にプロットするだけのグラフを作ってみました。

例:

画像1の色分布 やはりパステルカラーな絵だとこうなるのね。^^; 画像2の色分布 ますます傾向が顕著にw

プログラム:

以下のページでグラフを生成できます。(JPEG, PNG でも動作します。重たいけど) コードは以下の2つです。.phps の拡張子を .php に変更して使って下さい。 コマンドラインにも対応。
% php colordist.php  chara-298.GIF  > chara-298.PNG

備考:

初め、対応する色でそのまま plot したところ、 (0, 0, 0) に近づくほど量が少ないような(誤った)印象を受けたので、 暗い色を明るく補正するようにしました。
NG 版は↓こんなです。
画像1の色分布 (NG版) 画像2の色分布 (NG版)

KAIST からの Crawl

たまにやたらと重たい事があるので、アクセスログを見ると、 KAIST からバースト的なアクセスが来てました。
[2008/09/27:12:06:31 +0900] dor18184.kaist.ac.kr "20020627-2-S1" ""
"Mozilla/5.0 (compatible; MJ12bot/v1.2.2; http://www.majestic12.co.uk/bot.php?+)"
サーバが貧弱なうちとしては困るので、ブロックする設定を入れました。
多いだけなら google もそうなのですが、 という訳です。

MJ12bot:

どうも去年の10月ぐらいから、ウイルスによって拡大するニセモノのMJ12botが
跋扈しているようで ^^;; ちなみにホンモノのボットの最新版はv1.2.1らしいです。
majestic12のなかのひともたいへんですね。よくよく調べてみると、ホンモノの
MJ12bot (v1.2.1でした)もときどきアクセスにきているようです。そっちは大変
お行儀がよく、4, 5ページクロールしたらすぐいなくなってるようでした。
なるほど?

KAIST:

KAIST 自体はまともな学術機関のようです。 1学生or1ホストが暴走してるだけっぽいですね。

2008年09月28日(日)

memcachedを使ったPHPのシングルトン実装?

以前、以下のページを参考にコードを書かれて困ったのを思い出したので。 先にことわっておくと、このページ自体に罪はない *1 ですし、限定的な条件では利用できる *2 技術だと思いますが、ありがちな罠が幾つかあるので列挙。

排他制御:

ただし今回の実装は排他制御を行っていないのでそのままでは使えませんが…。
アプリケーション全体でのデータ共有が目的なので、 そのレベルのロック処理を自分で入れて使って下さい。
使いたい人はガンバレ…

serialize:

クラスのオブジェクトデータを保存する際に serialize するので、 クラスインスタンスに serialize 不可な変数が入った時点で破綻します。

object サイズ:

この方式では、オブジェクトを生成/破棄する度に unserialize/serialize & memcache との入出力処理が働きます。
つまり、インスタンス変数に巨大なデータを入れたまま放置すると危ないです。 そもそも、「その」リクエスト処理で必要ないデータまで入出力するのはどうかと…

ゴミデータ:

object サイズの件と絡みますが、 データが要らなくなった場合に明示的に破棄しないとダメで、 それをアプリケーション全体レベルで考える必要があります。

クラスの改造:

クラスファイルを update すると、memcache 上のイメージと合わなくなるかも しれません。停止メンテナンスですか、そうですか。

slashdotやmixiも使っている?:

...から大丈夫でしょ。という事を言われたのですが、
パフォーマンスは悪くないのでオブジェクトに限らず画像やテキストなど
キャッシュさせれば負荷を軽減させるのに役立つのではないでしょうか。
slashdotやmixiも使っているようですし。 
この文章の前には、 MySQL やファイルI/O との比較が載ってますし、 「...に限らず...画像やテキストなど...ようですし」という流れなので、 「slashdot や mixi も memcached を使っているようですし」であって、 PHP クラスのインスタンスとして使っているとは言ってないはず。
そもそも mixi が Perl で動いてるのは有名な話ですし。

最後に…:

斜め読み(で終わらす人)って怖いね… (´Д`;)
自分も結構誤読する事があるので気をつけよう。 ひとのふり見て我がふり直せ…

*1: どれも自爆系だし、そもそもこんなアグレッシブな技術はきちんと 理解/消化/吸収してから使わなきゃダメダメ。
*2: メンテナンスまで考えると、その条件を把握し続けられるかって所ですが…

2008年09月29日(月)

gif_dump 改良

gifovlap 用に Extension ブロックのビット処理 *1 を実装してて、 実際の GIF 画像の Extension ブロックのバイナリイメージを調べたくなったので、 gif_dump.c で Extension ブロックを16進ダンプするように改造。
ExtensionBlockCount=1
    Function=0xf9  ByteCount=4  Bytes: 01 00 00 00
    Graphic Control
	Transparent=0 (= #ffffff)
	Dispose=0
↑こんな感じで表示されます。 こちらにも反映済み。
*1: giflib は Extension の細かい操作APIがなくてバイナリをそのまま アプリケーションで勝手にいじれ方式なのです。ケチ…

はてな日記のカテゴリ指定がうまくいかない。

はてな日記のタイトルにカテゴリを付けてみたのですが、 カテゴリ一覧から辿れません。
自分のタイトルの付け方。
* [GIF]GIF画像の色分布表示
 ↑1文字空白
検索パターン (窓に表示されるので分かりやすい)
*[GIF]
なるほど…
ソースが読みにくくなるけど、* と [ をくっつけて書くか…
*[GIF]GIF画像の色分布表示
編集して気づいたけど * と [ の間の空白は表示にも影響するのね。 どのみち詰めた方が良いみたい。

2008年09月30日(火)

giftransmask

gifovlap の実験用素材を作るのに、giftransmask を作成しました。
丁度、ming に付属している gif2mask の逆 に近い動作 *1 をします。
giftransmask foo.gif baa.alpha > baz.gif
とすると、baa.alpha αチャネル情報を元に goo.gif に透明pixelを上書きした baz.gif が生成されます。

Flash からマスク付き画像を抜き出す:

swfed と組み合わせると以下のような感じで使えます。
まず抜き出したい画像を探します。 に Flash の SWF ファイルを放り込んだ後、 左上の画像一覧のリンクを辿ります。
透明度付きの画像は DefineBitsJPEG3(35) が相当するので、 例えばその中から 298 を選ぶと、以下のコマンド *2 を用いてデータを抜き出せます。
php swfgetjpegdata.phps      chara.swf 298 > chara-298.jpg
php swfgetjpegalphadata.phps chara.swf 298 > chara-298.alpha
それから、適当なツール *3 で chara-298.jpg を変換して chara-298.gif にします。 あと、何とかして 透明=on で保存してください… *4 ごめんなさい。ごめんなさい。 そして giftransmask を実行。
giftransmask chara-298.gif chara-298.alpha > chara-298-trans.gif
やったーっ!

プログラム:

コンパイル
gcc -O2 -o giftransmask giftransmask.c -lgif

制限事項:

  • 入力元に transparent 対応 *5 フォーマットでない GIF を指定してもダメです。
  • transparent index を 0xff 決め打ちにしてるので 256 色全部使ってる画像だと問題あり
  • アニメーションGIF 未対応。1枚目のフレームだけ適用します。
そのうち何とかします…

*1: と思ってましたが全然違う処理でした。○rz
gif2mask の方は画像の明るさ(max(red,green,blue))を zlib 圧縮したデータです。

*2: swfgetjpegdata.phps, swfgetjpegalphadata.phps は swfed/samples/ の下にあります。
*3: Photoshop で GIF 保存 > 強制=なし、ディザ=誤差拡散法、同一色の保持=off。 お勧め
*4: 透明度 on でないと処理できないのは、giftransmask の今の所の制限事項です。
*5: transparent index 有る無しに関わらず、フォーマット的に

Skype on Linux がメモリを使いすぎる問題 (2)

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
11222 apache    22   0 53708  21m 5720 D 11.3  2.2   1:58.63 httpd
27944 yoya      15   0 91388  42m  13m R  0.7  4.2   4:02.70 skype
とりあえず動かしっぱなしでも問題はなさそうなので、次は、 Windows Skype から同じアカウントでつないで様子を見ます。
更に、これでも問題がなかったら、 PHP で bot をつないで(Windows Skype は止めて)みようかと。
切り分け切り分け。

これで、10 日分だよ〜。

タイトル一覧
カテゴリ分類
Database
JXTA
Java
XML
awm
bookmark
keyword
memo
news
research
Powered by hns-2.19.5, HyperNikkiSystem Project