2024年7月21日~2024年7月27日
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7月21日
windowsファイルのバックアップファイルの作成
32GBのUSBメモリ5セットを購入し、ファイル履歴でバックアップを保存してみる。
32GBフルで使っておおよそ2~3時間かかった。(正確な時間は測っていない)
ファイルはkaggleなどの一部データセットが残っているせいか、膨大になっており、たぶん32GBで入りきらない。そのせいか「個人用ファイルの復元」を押しても復元するファイルが以下の画像の様になり、たぶん完全に復元ファイルの作成ができていないような気がする。
回復ドライブの作成
128GBのUSBメモリを使って行った。
目的としては、基本的なシステムだけでなく、一部アプリケーションや環境の設定なども復元して欲しいから。そのため多めのUSBメモリを選択した。
コントロールパネルの「システムとセキュリティ」から「セキュリティとメンテナンス」を実行。
「回復」をクリックし、「回復ドライブの作成」をクリックして、挿したUSBメモリを選択してしばらく放置すると、回復ドライブの作成が行われる。
ただどんなに容量が大きくても、強制的に32GBに制限がかかるっぽい?(ということはシステムファイルの上にさらに残したいファイルを追加するのは出来ない?)
戻す方法もあるが、ファイルのフォーマットの都合上32GBまでしかできないのかもしれない。
参考リンク: https://zenn.dev/quantum/articles/7061b1c15b9b1b
そもそも32GBまでしかできないのであれば、システム以外の保存は出来ないのだろうか?
調べ方もわからなかったので、ChatGPTに聞いたところ、その通りだった。OSのインストールメディアみたいなものかもしれない。
そう考えると、128GBはファイル履歴のバックアップに使うべきだった。
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/22 MaskRCNNの調査(RPNとROI_HEADSの違いについて)
どちらを見てもBATCH_SIZE_PER_IMAGEがあるので二つの違いを調査
RPN: Region Proposal Networkのことで、検出候補のバウンディングボックスの矩形を検出するモデルのこと。ここでのBATCH_SIZE_PER_IMAGEはバウンディングボックスの候補の数となる、
ROI_HEADS: ROIはRegion of Interestの略、headはその関心領域のスコアを算出する部分。つまり「関心領域が何であるか」を算出する部分である。ここでのBATCH_SIZE_PER_IMAGEはRPNで候補となった、バウンディングボックスの中から、検出された物体のスコアやセグメンテーションのスコアを計算するバウンディングボックスの数を表す。
つまりROI_HEADSのBATCH_SIZE_PER_IMAGEを大きくしても、RPNの数が小さいと意味がない?
ANCHOR_GENERATOR: 領域候補となるアンカーの生成を司る部分。詳細
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/23 MaskRCNNの調査(気になったこと)
NMS_THRESH: Non-Maximum Suppressionの略称。非極大値抑制という。重なり合ったバウンディングボックスを除去する基準。この値が小さいとバウンディングボックスの重複を排除することになる。
POSITIVE_FRACTION: モデル学習時の正例と負例の割合を決める。負例は背景のこと。
PRE_NMS_TOPK_TRAIN: 学習時の重なり合ったバウンディングボックスを検出する数のことと思われる。スコアが大きい順に上位TOPK個をNMSとして算出する。
PRE_NMS_TOPK_TEST: 評価時の重複の重なり合ったバウンディングボックスを検出する数のことと思われる。スコアが大きい順に上位TOPK個をNMSとして算出する。
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/24 ミニPCのネットワークの設定
ミニPCのIPアドレスを固定する。
固定する方法は二つ
- PCの「設定」項目から「wifi」を選択し、「IP割り当て」を自動(DHCP)から手動に変更
- wifiのルーターにアクセスして、設定からIPアドレスを固定したいPCのmacアドレスを指定し、固定するIPアドレスを指定する。
2.の方法を取ってIPアドレスを固定した。
なおwifiのルーターにアクセスする方法はおそらくDNSサーバーに記載されている、IPアドレスを入力することでアクセスできる(ハズ)。
1.と2.の設定の違いはあまりないが、2.の方法の方が安定性は高いらしい。
ChatGPTに聞いてみたが真偽性はもう少し調べたほうがいい。
ただ、PC側から設定すると、IPアドレスの設定で色々ごたごたが起きそう(ipの競合)なので、ルーターから設定した方が良さそうなのはなんとなくわかる。
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/25 ミニPC内のwslへのリモートデスクトップ接続
ミニPC(windows11 pro)への接続は問題なくできた。
では次にwslにデスクトップ環境を作成し、そこにリモートデスクトップ接続を行おう。
手順は過去の通りやったが、既に3389はwindowsのリモートデスクトップ接続で利用しているので、別途新たなポート番号が必要。
また、ミニPCはwslへの接続が必要なのでポートフォワーディングが必要。
というわけで以下の手順で実行した。
- wslでリモートデスクトップ接続用のポート番号を開く
- windows11のファイアウォール設定で別のリモートデスクトップ接続用のポート番号を設定(TCP, UDP)両方
- netstatでポートフォワーディングを設定。listenportが2.で設定した番号で、connectportがwslで設定したやつ
- クライアントマシンの「リモートデスクトップ接続」からPC名:ポート番号(2.で設定した番号)で接続
- 接続先のユーザー名でパスワードを入力
これもそのうち記事にしてもいいかも。
画面に何も出なかったがエラー自体は出ていないので、たぶん成功しているはず。
でももしかするとログインできていない?
とりあえず、xfce4でできたので、i3でもできないかを調査する。
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/26 何もなし
コンペの考察をしていたら一日が終わった。
detectron2のテストデータの推論の挙動の違いを調べていた。
しかし目的の達成にはならず。
MODEL.ROI_HEADS.NMS_THRESH_TEST
MODEL.RPN.PRE_NMS_TOPK_TEST
g.MODEL.RPN.PRE_NMS_TOPK_TEST
![tttttttttt](https://res.cloudinary.com/zenn/image/fetch/s--YaVG9xtd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_70/https://storage.googleapis.com/zenn-user-upload/avatar/b1e726451c.jpeg)
7/27 何もなし
よくわからないことを手探りで進めようとすると、わかったことが少なくなる。
MaskRCNNのRoIAlignを調査したが、FasterRCNNをさらに精度を上げるための工夫点ということしかわからなかった。
またMaskRCNNはFasterRCNNに、セグメンテーションを行うマスク分類を加えることで精度を向上させたということがわかっただけである。
MaskRCNNの構造は一度ちゃんと調べるべきかも。