MCE standby tool で GeForce 6200 がスタンバイからの復帰に失敗する現象が直った(と思ったけど、直ってない)

GeForce 6200 にはスタンバイからの復帰に失敗することがあるという問題があって、同カードを搭載した家のPC環境(Windows XP SP3)でもしっかり発生して5回に1回くらい復帰に失敗するという状況。具体的な発生条件も対処法もわからず、スタンバイを使用しないという消極的な対処をとって数年が経過した。しかし、最近になりどうしてもスタンバイを使用したくなって、久々に検索をかけたら対処法が見つかった。Slick Solutions - MCE Standby Tool (MST) を導入すること。
日本語での情報が殆どなく導入は若干不安だったが、バックアップを取った上で導入してみたところ復帰に失敗することはなくなった。

設定は debug タブの nVidia videocard standby fixes にある。デフォルトでは2項目とも disable となっているので、それぞれ変更する。設定が示す具体的意味は理解していないが、画像の設定で家の環境では問題が解消された。

追記 6/12

導入後、復帰に1回失敗した。しばらく様子をみて、何度も復帰に失敗するようなら本文を訂正する。

追記 6/15

再び復帰に失敗した。失敗する頻度は改善されている気がするけど、厳密にデータをとってる訳ではないので、記事を取り消す。

象の鼻地区

横浜の赤レンガと大さん橋の間に開発から取り残された様な土地*1象の鼻地区)、
大きな地図で見る
これが、


こうなっていて驚いた。



すっかり綺麗に。でも、個人的には以前の打ち捨てられた様な感じが好きだった。

*1:すっかり忘れてたけどマッスルシアターなんてものがあった時期も

16:9の構図についてのお話を読んだ

16:9の構図の分類 〜けいおん!,タユタマ,大江戸ロケット〜 - WebLab.ota
こちらを読んで、だいぶ感じ方が違うなと思ったので。


これは,右のキャラが左の2人のオバサンたちの世間話を盗み聞きする…という場面である.
一目瞭然だけれど,4:3で表現しようと思ったらパンさせるしかない構図になっている.

16:9の構図の分類 〜けいおん!,タユタマ,大江戸ロケット〜 - WebLab.ota

「16:9でしか表現できない構図」として例示されているんだけど、まだカメラを引く余地があるのでパンさせる必要は無いと私は思う。
(引用元の画像を利用させていただいています)
こんな具合で。欠けている部分は当然絵が入ります。脳内補完。元がだいぶ寄り気味の画なので、4:3に収まるまでカメラを引いても人物の大きさは確保できるし、引いたことによって破壊されてしまう要素は特に無いんじゃないかな。元々が人物と背景のカメラがまるで違うという、ゆるいカットだし。


これは,右のキャラが左の2人のキャラに文句を言って,それに対して一番左のキャラ(主人公)がリアクションするシーンなんだけれど
これも,4:3で表現しようと思ったらパンさせるしかない.

これもまだ引けると思う。

実際に4:3で画作りするなら、人物の配置も調整する余地があるんじゃないかな。

で、思ったんですけど、上の二つって「16:9でしか表現できない構図」というよりは「16:9から4:3にパン&スキャンしたときに問題の出る構図」って感じですよね。でもそういう前提には読めなかったんだけど、どうなんだろう。私の誤読かな。

追記 5/28

一応自分の考え方を補足しておくと、「16:9をうまく使っている構図」の例については確かに4:3では難しいと思う。カメラを引くとか、桶をもっと奥において人物の配置も調整するなんて選択は有り得ない。それでは桶を中央に配した意味が弱まってしまう。

ドコモのおさいふケータイ対応端末の内臓ICカードはドコモショップに設置のDOCOPYで初期化できる

おさいふケータイに対応したFOMA端末を譲ってもらったが、ICカードに前オーナーのデータが残っていたために「FOMAカード(UIM)情報が一致しない」云々とのメッセージが表示され、おさいふケータイ用のアプリが起動できない・削除できない・ダウンロードできないという状態になっていて困る→ググる
ドコモショップに持ち込め→え、窓口持ってかなきゃダメなの。手数料かかったりしないの?→もう少しググる
→それ、DOCOPYで自分で出来るよ。
というわけで、ドコモショップに行ってDOCOPYを使って初期化してきた。所要時間1分。よくよく調べたらドコモのサイトにもしっかり書いてある。

・iCお引っこしサービス(ICカード内データの移行)
ICカードフルフォーマット(ICカード内データの消去)

DOCOPY(ドコピー) | お客様サポート | NTTドコモ

DOCOPYの利用はもちろん無料。操作も自由にさせてもらえるので、初期化の理由を詮索されるなんてことは無し。というのは、この問題にはまるのはオークションで白ロムを手に入れた人が多いみたいで、ググった先では何だか心配している人が多かった。ビクビクしすぎだと思う。

jpegで保存を繰り返す

新規保存で劣化していくJPEG形式の画像の様子をとらえたムービー - GIGAZINE
すでに追記があるけど、件のムービーは前回保存時よりQualityを落としながら読み込み保存を繰り返してるんだと思う。試しに似たようなことをやってみた。

use Imager;
use strict;
use warnings;
my $base = 'test';
my $ext = '.jpg';
my $file = 'test.jpg';
my $img = Imager->new;
for(0..99){
    $img->read(file=>$file);
    $file = $base . $_ . $ext;
    $img->write(file=>$file, jpegquality=>100-$_);    #前回保存時よりQualityを減らしていく
}

 test0.jpg
 test49.jpg
 test99.jpg
ムービーと似た画像ができたよ。


今度はQualityは落とさずに固定。読み込み〜保存を1000回繰り返す。

use Imager;
use strict;
use warnings;
my $base = 'test';
my $ext = '.jpg';
my $file = 'test.jpg';
my $img = Imager->new;
for(0..999){
    $img->read(file=>$file);
    $file = $base . $_ . $ext;
    $img->write(file=>$file, jpegquality=>80);    #qualityを固定
}

 test0.jpg
 test999.jpg
フォトライフは再圧縮しちゃうので比較画像のアップロード先としては適切じゃないけど、ムービーみたいな酷いことにはならないことは分かるかな。

Name         MD5                               Bytes
-----------  --------------------------------  -------
test0.jpg    505831637146568AFE85EC37C3949141   24,713
test1.jpg    8D4CFB1337F7F95F0EE21DD68A243BC3   24,715
test2.jpg    526D1EFBADDD81A6B1EAB6346F2E59BE   24,719
test3.jpg    D49CFDCE6ACAE9E22E15ED81B594D452   24,720
test4.jpg    DC667B9AEBD5424E53122E00C63F62BD   24,715
test5.jpg    25F0C995688B8042F8A4022B21BB9B35   24,715
test6.jpg    25F0C995688B8042F8A4022B21BB9B35   24,715
.
.
.
test999.jpg  25F0C995688B8042F8A4022B21BB9B35   24,715

md5とったら test5.jpg以降は完全に一致してた。(ただこれは同一エンコーダー同一設定で画像には一切手を触れずに保存を繰り返すというあまり現実的では無い実験なんで、これをもってjpegで保存を繰り返しても劣化は進まないと思ってはいけない)

アニソン三昧の放送曲を垂れ流す twitter bot を作った。

大晦日のことでとっくに終わった話ですが、12/31にNHK FMにて放送された「今日は一日アニソン三昧ファイナル」の放送曲を垂れ流すbotを作って放送時間中に運用しました。やり方は、Web::Scraperで曲リストを取って、Net::Twitterで投稿するというperlスクリプトVMware上のCentOSでまわしてただけです。
Twitter / aniSonZanmai
放送当日に急に思いついて、動かし始めたのはお昼前くらいだったでしょうか。公式サイトの曲リストから拾って流すだけの存在意義の微妙なbotでしたが、最大で六十数名の方がフォローしてくれていた様です。