|
おかげさまでspamコメントが増えてきましたので、一応コメントを承認制にしました。基本的には承認します。
sugarsync:QID 508を見ればいいことなんですが，念のため。
PR Max OSX snow leopardクリーンインストールが事の発端で，クリーンインストールするからにはバックアップをせねばならぬ，で，するならTimeMachineとかでやった方がいいよね，というだけの話だったのに，開始が16日で今日はなんですか，22日ですか。６日も何をしているのか。 一応失敗の履歴を書いておきましょう。TimeMachineでバックアップしようとする→失敗→InProgressファイルが悪さをしているのかも？→ゴミ箱に入れて再挑戦→失敗→HDの異常かな？ということで，ディスクユーティリティで確認→ディレクトリ構成に異常があるらしいので修復→再挑戦→失敗→しばらくバックアップをとってなかったから，差分をとるのに苦労しているのかも，こうなったらHDの方を初期化して，いちからTimeMachinにかけよう→失敗ということをやって，もうダメだTimeMachineは諦めよう，ということで，allabout:Macのディスクユーティリティの使い方を参考に，起動ディスクのイメージを保存しようとする→失敗，という経緯を経て，もう完全に諦めました。渡辺の負けです。 ユーザディレクトリ以下の，書類（document)(これはSugarsyncで同期しているからいいんだけど，一応），デスクトップ，Music (iTunes)（多分iPhoneに全部入っているけど），MovieからMy projects，PictureからiPhoto library(これはコピー中にエラーメッセージが出たけど，このライブラリを指定して開いたらちゃんと開けたので多分大丈夫：念のためオリジナル形式での書き出しも保存した），あと個人情報データのあるフォルダ(sugarsyncで同期しておらず，かつ重要なのでしっかり確認），念のためdownloadsを手動でコピー。更に，Mailから，一応受信メール全てをアーカイブ化して保存。結構重かったと思いますが，１時間くらいで終わりました。最初から…こうすれば… あとは，iTunesとSugarsyncのコンピュータ認証を解除して，いよいよインストールです！消えるファイルがありませんように。 補足。TimeCapsuleを購入して，別のPCのバックアップをTimeMachineで取ることにしたんですが，これは超順調だったので，（でも，TimeCapsuleって2年で壊れる，という話を聞いてそれはそれで怖い）TimeMachineそのものが悪いわけではなさそう。また，HD自体（yano mobilshuttle Duo)は，普通のコピーにはかなりの早さで対応しており，結局上記ファイルを合わせると60GB近くになったんですが，全然ストレスがありませんでした。単に相性の問題ですかねえ…わからん…。
さっきちょっとやってみました。
Step 2. Applying Signal Space SeparationSSSは、渡辺の理解では、信号磁場（自発／誘発の脳活動によって発生する磁場）と雑音磁場をどうにかこうにかして（本当はここが大事なんですが）分離し、雑音磁場を取り除く方法、ということになりましょうか。初出はS. Taulu and M. Kajola, Presentation of electromagnetic multichannel data: the signal space separation method, J. Appl. Phys. 97 (2005),あたりですかね。詳しい人に聞いてきます。 さて、SSSを実行するには、 [SSS] maxfilter -f <rawdata_file> -o <output_file> -ctc /neuro/databases/ctc/ct_sparse.fif -cal /neuro/databases/sss/sss_cal.dat -autobad off -bad <list of bad channels> -v | tee <log_file>とするようです。基本的には不良チャネル同定と一緒なんですが、既に同定済なので、-autobadオプションはoffにし、-autobadで得られた不良チャネルを、-badの後に指定するようです。形式としては、 -bad 1134 1123 1412のようにすれば良いようです（おそらく、数字はチャネル番号ですね）。 まれに、SSSを実行した後に、データの左側（はじめの時間、になるんですかね？）に、アーティファクトが存在することがあり（たとえばセンサージャンプ）、それはmaxfilterの時間的拡張（-st)を用いることによって起こりえるので、このオプションを使うときは、それがうまく働く特定の時間バッファが要求される。デフォルトのバッファは0.25Hzのハイパスフィルタに対して4秒であり、もし、低周波数を維持したいと思うのであれば、処理時間を犠牲にしてでも、バッファ時間を長くとるべきである（たとえば、10秒-0.1Hz）。もしセンサのアーティファクトが残っている場合、-corrオプションをデフォルトの0.98より小さくすることで、電位（潜在的な？potential)アーティファクトが除去される閾値を減らすことにより、-stはより少なく保守されうる（ただし、これは興味のある信号も取り除いてしまう可能性が増大する。また、<0.8は推奨されない）ということで、それをふまえたコマンドはこちら。 [SSS, -ST] maxfilter -f <rawdata_file> -o <output_file> -ctc /neuro/databases/ctc/ct_sparse.fif -cal /neuro/databases/sss/sss_cal.dat -autobad off -bad <list of bad channels> -st 10 -v | tee <log_file> 試行中の頭部移動の補正（200ms, 500ms, 1000msのいずれかの間隔で補正する）ができるそうです。コマンドはこちら。 [SSS, -ST, -movecomp] maxfilter -f <rawdata_file> -o <output_file> -ctc /neuro/databases/ctc/ct_sparse.fif -cal /neuro/databases/sss/sss_cal.dat -autobad off -bad <list of bad channels> -st 10 -movecomp -hpistep 200 -hp <head_pos_log_file> -hpisubt amp -v | tee <log_file> 記録中にcHPIを用いる理由は、我々が記録セッション内の被験者の頭部の移動をモニター/補正することができるからである。頭部の移動のモニターと、それをファイルに出力するために、-headposオプションを用いる。-movecompオプションを用いることで、動きを補正できる。両方のオプションで、logファイル（頭部位置パラメタが保存されている；後に視覚的に点検するために）を指定し、算定間隔（普通200msだが、500msや1000msも可能である）を設定する(*多分、-hpistepオプションですね）。また、-hpisubtオプション（amp or off)を用いることで、データからcHPI信号（非常に高周波）を取り除くことも選択できる。なお、 バグにより、-autobadと-movecomp, -headposオプションは同時に使用してはいけないとされています。まず、-headposオプションを入れてmaxfilterを実施し、そこで出てきたファイルを、"head_pos_log_file"として読み込むのだと思いますが、そのコマンドは記載されていません。HPIが記録できていない場合、無理矢理実行はできるようです。 もしHPIが試行中のどこかで（記録）失敗していた場合、頭部移動の補正/算定も失敗し、そのデータブロックはスキップされる（つまり、0にセットされる）。最後に確認されたHPIを使いたい場合は、-movecomp interオプションを使用できる。しかし、もしこのHPIの失敗が、ファイルの初めの方で起こっている場合は、本当に移動の補正をしているというわけではないので注意すること単に、上のコマンドの-movecompの後に、interを加えるだけ（-movecomp inter)です。 原点(origin)の選択Maxfilterは、基本的にはcoordinate systemの原点に依存して出力がなされる。デフォルトでは、原点をデジタイズした点によるsphereにフィットさせることで得る。しかし、これで問題が生じる場合もある。もっとも良くあるのは、"sphere fit extends outside of the sensors (sphereのフィットが、センサの外側にあります）"、あるいは、原点が0,0,0 (maxfilterの既知のバグによる）にあるということ。両方のエラーは、同じ方法でfixできる。利用したい原点を手入力することである。この原点は、デフォルトセッティング(0,0,40)にする、他のsphere fittingツール（matlabにおける例）で計算したもので良い。 [SSS, -ST, -movecomp, origin] maxfilter -f <rawdata_file> -o <output_file> -ctc /neuro/databases/ctc/ct_sparse.fif -cal /neuro/databases/sss/sss_cal.dat -autobad off -bad <list of bad channels> -st 10 -movecomp -hpistep 200 -hp <head_pos_log_file> -hpisubt amp -frame head -origin <x> <y> <z> -v | teeこのように、原点(-originオプションで）情報を任意に与えることができる、ということでしょう。-frameオプションは、なんだかよくわからないのですが、多分ここから新しくできているので、-originに関係しているものと思われます。 sphereは、直訳だと球で、MEGの場合だと、頭部をなぞる形でデジタイズすることでできる架空の頭のことだと思うんですが、良い訳がないのでこのまま。SSSはこんな感じです。原理はわかればまた追記します。次がいよいよco-ordinateですね。
cはcontinuousのcだったようですね，ということで， もしcHPIを取ってなかった場合，不良チャネル探索は，Step2と同時に行うことができるようです．また， -autobad 20 よりもむしろ，-autobad 1を使う事は，記録中の一秒毎のバッドチャンネルのチェックになるかもしれず，データのはじめの20秒を基盤とした永続的な不良の宣言よりもよいかもしれないとされています．（ということは，autobadは20秒「間」のチェックをする，ということではなく，20秒「毎」にチェックする（だからスキップがある）ということなんですね）． autobadは，トリガーチャネルがゼロの値を持っているデータセグメントのみで働くことも特筆すべきとありますが，ということは，データ計測時に，トリガをたてる（実験を開始する）前に意図的に20秒ほどのwaitを設定したほうが良いかもしれないということですね．まあ，HPI measureの期間に20秒くらいは経過する気がしますが… もし，データの相当の部分が，トリガチャネルのゼロでない値であれば，SSSの時間的拡張が，より明瞭なセンサーアーティファクトの除去を提供するかもしれないということで，SSSに行きましょう！ 以下はあまり意味が良くわかってませんが，適当に解説． 不良チャネルのためのログファイルを通して，サーチを行う場合については，以下のコマンド． cat <bad_chans_log_file> | sed -n /Static/p | cut -f 5- -d| tee <bad_chans_log.txt>を利用する．catというのは，concatnateの略だったと思いますが，log fileの中身をテクストで表示するコマンドですね．sedはstream editorの略で，sed /aaa/bbbで，aaaをbbbに置き換えるコマンドです．つまり，出力されたlog file中の，Staticという部分をpに変更するということ（たぶん）．-nについては，これがないと全ての行を表示してしまうんだけど，-nオプションがあると，置換した行だけを表示してくれる，ということ（だったと思います）．cutについては，-fオプションをつけると，指定したフィールドを出力する（デフォルトのフィールド区切りはTAB)，ということで，-dオプションというのは，区切り文字に文字列(string)を利用する，というもの．つまり，５つ目のTAB区切りから，以降を区切り文字を用いて区分する，ということ？で，それを>bad_chans_log_txt<という名前のファイルで書き出すということですね（tee；前回記事参照）.ようするに，logファイルを，（以降扱いやすいような）txt形式に変更する，ということなんですかね…？ あとは， 自分の不良チャネルのためのraw dataの全てを，EEGLABデータブラウザをスキャンするために用いるとすれば，MNE_browse_rawを用いることができる．ということですが，MNEって本当何してるか良くわかってないんですよね…．勉強します．とりあえず，1st stepはこのあたりで．
|
カレンダー
カテゴリー
プロフィール
ＨＮ：
渡辺隼人
性別：
男性
ブログ内検索
アクセス解析
カウンター
|
