カレンダー
クイック サーチカテゴリ管理最近のエントリ
|
2009年 9月 3(木曜日)金子恵水の日本画金子恵水の絵画金子恵水の水墨画、南画、日本画を紹介していきます。 金子恵水について、私の母、金子恵水(カネコ ケイスイ、本名 恵美子 1931-2009)は、趣味で水墨画を書いていました。実はジャンルが何にあたるのか私には確信がないのですが、元々は南画、最近は日本画で良いのではないかと思っています。いずれにしても、水墨画のカテゴリに属しており、和紙に墨と岩彩(岩絵の具)で描いていく絵画です。 1973年頃、福島市にいたとき、たまたまお隣り同士となりました故 篠原三青 氏に師事して南画を書き始めました。その後、埼玉に転居してからは、東京の川口楽土 氏らの日本南画院に出入りして、段々と日本画に近い絵を描くようになりました。ただし、写実よりも墨の濃淡が出す味わいを大切にしていたように思いますので、これを日本画と言って良いのか良く分りません。南画を書いていた時分には四君子を始めとする典型的な南画の題材を描いていましたが、徐々に好きな山野の草花を題材にすることが多くなりました。 生前は絵を描くことを楽しむと同時に、展覧会に出展したりして人々に見てもらうことも楽しんでおりました。描く時期と描かない時期に大きなムラがありましたが、それでも100点弱くらいの絵が残されているのではないかと思います。それらの絵をここで順に展示していきたいと思います。 ウバユリの絵最初はウバユリの絵です。この絵はどこかの展覧会に出品していた筈ですので、題名を付けていたと思われますが、整理ができていないために現在では分らなくなっています。 さて、この花は本人が特に好きな花でした。オオウバユリ(大姥百合)は晩夏に花を付ける大型の野生の百合で、暗い林床で咲きます。花は1メートルくらいの直立した茎の上に拡声器のような具合に付きますが、その頃には葉が枯れてぼろぼろになっているため、葉がない→歯がない→姥、という連想で和名が付いています。アイヌ語ではトゥレップと言い、重要な食物として利用され、根から澱粉を取っていたようです。北海道や福島に住んでいた時分に良く見かけましたので、寒い地方に多いように思います。スケッチは黒姫(長野県)の家の近くで行ったのではないかと思います。 基本的に画像は自由にお使いいただいて構いませんが、もし転載の希望や商用で使いたい場合があれば声をお掛け下さい。
2009年 8月 28(金曜日)YouTubeダウンローダスクリプト プレイリスト対応YouTubeダウンロードスクリプトのプレイリスト対応YouTubeにはplaylistというものができています。クリックすると、直接指定されている動画から始まり、それに続くリストが順番に自動再生されるものですが、ありがた迷惑のような気もします。ただ、YouTubeのダウンローダーページでも、プレイリストのURLを指定してエラーしている方もいらっしゃいますので、対応することにしました。 対応は2レベルに分れます。
プレイリストは8曲くらい連なっているようでダウンロードには多大な時間が掛かりますため、バッチ処理になるスクリプト(ytdownloader.pl)ではレベル2対応、ウェブサービス(YouTubeダウンローダ)ではレベル1対応を行いました。 仕様の解析プレイリストは以下のようなURL形式です。 http://www.youtube.com/view_play_list?p=3A7DF57CA0B7E08B&playnext=1&playnext_from=PL&v=n3m1P05Shy4 ページを開くと、直接ビデオが始まり、リストのビデオがその後が続きます。 次にプレイリストの続きはどうなっているでしょうか。 <div id="playlistRow_PL_23" class=" watch-playlist-row v*CGaJrUXe45A "> これがプレイリスト23番目で、赤字がビデオ識別子になります。(2箇所に指定されています)。直接指定されていたのが、このプレイリストの22番目のようで、その後は上記のブロックが順番に並んでいます。従って、これを順番に取得してやれば良いことになります。 それにしても、他の情報も同様なのですが、ページ中の情報には冗長なものがすごく多いです。なんだかきちんと設計していないんじゃないかという感じがしてしまいます。実際にはビデオストリーム(100MBにもなる)に比べれば誤差の範囲なので、性能の問題にはなりませんが。 実装完成したスクリプトはこちらにあります。"-p"オプションを指定するとプレイリストのファイルを全部取得します。 さて、最初にプレイリストをリストに格納します。上記のどちらを使っても良いのですが、上のを使います。 } elsif (m!<div\s+id=\"playlistRow.*\"\s+class=\"\s*watch-playlist-row\s+v*([^\s\"]+)\s*\">!) { 次に実際の中身を取得します。 foreach (@vplaylist) { 自分を呼び出してダウンロードします。ここでは並行してダウンロードしたかったのでforkしていますが、行儀良くシーケンシャルにやるのでしたら、systemで良いでしょう。また、waitpidしていますが必須なわけではありません。 2009年 8月 24(月曜日)YouTubeダウンローダー仕様変更〜スクリプトYouTube仕様変更に対応したダウンローダースクリプトYouTubeダウンローダの改修の記事で書いていますが、YouTubeの仕様が一斉に変更されています。提供しているダウンローダスクリプトでもこれに対応しています。仕様変更内容はこちらのページをご参照下さい。ここでは、中身について簡単に解説いたします。 YouTubeのページを読むまずはおなじみ、YouTubeのリンクに使われるページを読みます。 $ytpid = $ARGV[0]; 中身を解析します。 最初の"fullscreenUrl"が旧来の方法です。2番目のifの中にある"var swfArgs"はFlashPlayerに渡す引数で、この中の"fmt_url_map"を捜します。ここには、解像度パラメタとそのファイル取得URLがペアになっているので、ハッシュに保存します。(Dprintはデバッグ文です)。タイトルは取れれば取っておきます。 foreach (@wgetrsp) { ストリームのURLを取得します。 if ($raw =~ m|(video_id=.*)&title=|) { 次のifが新しい仕様に合わせたものです。"fmt_url_map"の中身が取得できた場合に、このメソッドで取得することにしていますが、厳密かどうかは分りません。タイトルがあれば、なるべくタイトルを生かしたファイル名にします。(pathに使えない文字を'_'にしてあります。"TypeSelect"では、なるべく高画質なビデオファイルを選択しています。 } elsif ($#vphashk >= 0) { 最後のifは使っていませんが、コードとしては残してあります。昨年後半に行われた仕様変更により、一部のビデオが対応したと言われるメソッドです。"t"パラメータ("&t=")であるトークンを取得する方法は"get_video_info"によるものと、"api2_rest"によるものの2種類あり、片方をコメントアウトしてあります。 } elsif (0) { 最後に実際のストリームを取得します。 $GetCmd = "wget $FlagQuiet -O \"$filename\" \'$url\'"; なお、ファイルの選択ですが、基本的に下記"Spriority"の順番に高画質なのですが、22は大き過ぎてダウンロードに時間が掛かる上に再生も重いので、特に希望がなければ取らないようにしています。 #--- Select the suitable type. 帯域の制御実際にダウンロードしてみると、ダウンロード開始時に500kbpsくらいのスピードで始まるのですが、30秒くらいで徐々に遅くなり始め、100kbps〜50kbpsくらいまで落ちて行きます。以前は無制御(一定のスピード)でダウンロードできていたので、帯域制御をサーバ側でするようになったと思われます。 というのも、これが問題になるのはダウンロードのときだけで、ストリーミングの場合は支障ありません。ストリーミング視聴であれば、最初にバッファをある程度一杯にしないとならないので高速で送り、バッファが満たされれば、後はビデオストリームのビットレート程度のスピードで送れば充分ということになるからです。この場合、クライアント側のブラウザは実時間(10分のビデオなら10分間)サーバに接続状態になってしまうのはサーバ負荷ともなってしまうとも考えられます。しかし、実質的にブラウザ側でバッファ充足度による伝送速度のフィードバック制御を行っていますので、殆どのクライアントは最後まで速く送ろうとしても受け取れません。このため、今回のサーバ側の帯域制御はこれで仕方ないことになります。 2009年 8月 14(金曜日)YouTube Downloaderの改修YouTube仕様変更に合わせてダウンローダーを変更最近、私のYouTuneダウンローダでダウンロードエラーしているファイルがボチボチあったので、YouTubeの仕様の変更が行なわれているのには気が付いていました。それでも大多数はダウンロードできていたので後まわしにしていたところ、昨日8/13の朝から一切ダウンロードできなくなりました。先方の都合に文句を言う筋合もありませんので早速対応しました。 仕様変更の中身以前はビデオが表示されるURL(<http://www.youtube.com/watch?v=KONKcBvRHt8>の形式)の中身(1)を読み、"fullscreenUrl"のラインから"video_id"を取得して、"http://youtube.com/get_video?"のメソッドに食わせてやるというものでした。この方法で多くのツールが配布されています。しかし、実際に試してみると、既に"fullscreenUrl"は中身がなくなっているのです。 var fullscreenUrl = '/watch_popup?v=KONKcBvRHt8'; 結局、紆余曲折(後述)ありましたが、結果的には以下のような方法で取得できました。
"fmt_url_map": "18|http://v8.lscache5.c.youtube.com/videoplayback?ip=0.0.0.0 さてここまで分ったので、早速CGIを修正しました。実はこの方法は、従来のものを含めて第3の方法です。第2のもの(後述)を含めてサポートするようにしましたが、実際、8/13以降は全て上記の第3の方法でダウンロードされているように観察されます。 これにて、サービスのページと、ソフトウェアのページをアップデートしました。 紆余曲折と第2の方法実際には、すんなりは分りませんでした。第2の方法というべきものがあり、2008年の後半から一部のビデオファイルでサポートされていたようです。ググって発見したこの方法をやってみて、"動かん動かん"と唸っていました。 朝から動いていないのが分ったので、早速自作のproxyでブラウザとYouTubeのやりとりを眺めてみると、怪しいのは以下のリクエストです。 GET http://www.youtube.com/get_video?video_id=KONKcBvRHt8 お馴染の"get_video"メソッドですのでログを grep してすぐ見つかりました。従来と違うのは、"t"という呪文パラメタが追加されています。さて、これを更にググってみると、外人が概ね以下のようなことを書いていました。
これを実装してみましたが、うまくダウンロードできません。このときのエラーコードが微妙に変化するのと、自作proxyではどうした訳かブラウザからの視聴も失敗してしまうため、中々理由が分りませんでした。疑心暗鬼になって、「さては小細工されたかぁ」と思い、GET メソッドのパラメタやUserAgentなんかもいじったりしてしまいました。 もう一回ログに戻ってみると、"get_video"の直前に、怪しいリクエストがあります。 GET http://v24.lscache4.c.youtube.com/videoplayback?ip=0.0.0.0 "videoplayback"でググってみると、どうやら、これで取得できるっぽいです。それで探ってみると、"swfArgs"の中にありました。フラッシュプレイヤーに渡すパラメタのようです。パイプの前の数字はビデオ解像度のパラメタとして見覚えがありますので、後のURLがその解像度のURLということになるでしょう。これで実装すると、ファイルがダウンロードできました。 結局のところYouTube側は、むしろ直ダウンロードし易い形に仕様変更してくれたようです。実際、分り難くすることも含めて第2の方法を採用したが、アクセスが1回増えるのも無駄だし、ということで第3の方法にしたのかもしれません。まだ、仕様を詳細に解析していませんが、使い易くしていただいてありがたいことだ、と思っていて良いように思います。 2009年 7月 16(木曜日)デジタル写真の向きを合わせるJPEG画像の向き(EXIF Orientation)JPEG画像には画像の向きを示す情報が記録されている場合があり、画像ビューワはこれをヒントとして、画像の向きを合わせて表示することが期待されています。そのソフトウェア的な対応方法を説明します。 最近Canon製の一眼レフデジカメ(Kiss X2)を購入しました。Canon製デジカメは、知る限りではコンデジも含めて全機種に重力センサが付いていて、撮影時に画像の天地向きを記録することができます。(しないこともできる)。これをgqviewなどの対応したソフトで閲覧すると、自動的に縦向き(portrait)の写真はクルっと回転して正しい向きに直して見ることができます。対応していないと縦画像が寝てしまいますので一長一短なのですが、デフォルトでは利用するように設定されています。 私が提供しているPhotostandでは、Linux版もWindows版も特に何も処理していませんでしたので、そのまま(縦向きの画像は寝た状態で)表示されます。つまり、システムの壁紙表示機能はこの仕様に対応していませんでした。 EXIFの仕様と対応この向き情報は、EXIFのOrientationに記録されています。従って、表示の前にこの情報を読み出して、正しい向きに直してやる必要があります。仕様に関しては、このサイトが詳しいのですが、かいつまんで書くと以下のようなものです。
|
ブログ管理 |