Digital ESSAY「rust でがんばる」

坂口 裕

監視カメラ案件ですが、日々ちょっとづ重すぎるよな、という感じでイマイチやる

れ、したがって最初の for ループが終わると、つ進化しております。当初 perl にてサムネ気が出ません。とりあえず評判良さそうだ

そのオブジェクトは破棄されることになりイルを生成していたのですが、いかんせんということで、rust で実装してみることにます。で、話をややこしくするのが、この遅い。どげんかせんといかんということで、しました。

所有権移動規則が適用されるのはヒープに一念発起して別な言語で実装する方針にしました。

まあしかし、これが結構ややこしかった確保したオブジェクトについてのみ、とい... ガベージコレクション不要という美点をうことです。スタックに確保されるような根本的な問題としては perl で遅いという持たせるために、基本的にポインタの共有変数は、移動しません。まあとにかく、今ところにあるわけですから、インタプリタを許さないという設計思想。ポインタは単使おうとしているオブジェクトはスタック系の言語は多分難しいんじゃないでしょう

一のスコープが「所有権」として所持して変数なのかヒープ変数なのか、それをどこか。というわけで、コンパイラ系の言語をいて、スコープから外れると廃棄されるとで作ってどこで破棄するか、を常に意識し探すことになります。これがいろんなマシいう事になってます。で、ポインタを「借ながらじゃないと使えないというのが、なンで動かす必要があるとなると大変悩ましりる」ことはできるのですが、借りた方のかなか慣れないところでした。なにしろ設い問題なわけですが、とりあえず今使ってスコープは所有権を持っていないため、ス計のセントラルドグマなので、この部分をるサーバで動けば十分なので、その意味でコープから外れても実体データは破棄され乗り越えないと 1 ビットたりとも動かないは互換性とかをあんまり気にする必要がなません。そして、ポインタを借りない場合のです。

いのはいいところです。まあ順当には C++は自動的に所有権が移動します。というこ

もう一つの慣れなさが、変数はデフォルとかでやればいいんでしょうけど ... えーととは、for ループの外側で定義したオブジェトでは変更不能である、というところです。

... 単にサムネイルを生成したいという、やクトに for ループの内側で借りずにアクセ

フツーに考えれば定数と変数があると、変りたいことに対してちょっと学習コストがスすると、所有権はそのスコープに移動さ数は変更可能だと思うじゃないですか。違One Point BUZZ WORD

差分検知

境とかによるのでしょうが、とりあえず 32 で回してます。
あとは基準フレームをどこに置くかなのですが、基本的には撮影イベントの最初のフレームで良いようです。一つ前のフレームとの差分を取ると、「消えた分」「出た分」の両方が検出されるため、ちゃんとしたアルゴリズムはあるんでしょうけど、とりあえず今のフレームで出た分は次のフレームで消えることになり、上書今使っててそれなりに見えるのはこんな感じ。前提としてカメラきしていくと違いがよくわからなくなります。これが最初のフレは固定とし、motion で収録するものとします。そもそも処理すームと比較すれば、出た分だけが検出できるので安定します。一る画像のサイズですが、原解像度の必要はないです。視力と相談方で雲が太陽を隠すなど、急な照明条件の変化で大きな領域を差してなるべく小さくすると便利。今の所横 640 でやってますが、分として検出してしまうと、最終的には変化が見づらくなります。

あまり困ってません。

そこで、適当な閾値を決めて、変化があるピクセル数が閾値を超基準フレームと現在のフレームでピクセルごとに比較して、差えた場合、直前のフレームとの差分を取るようにすると、割と見分がなければ黒、差分があるならその色で塗るとします。本当はやすくなるようです。こちらも被写体で閾値は異なるのでしょう

RGB 全部でチェックするといいのですが、まあ G チャンだけ比が、画面の 1/4 ぐらいで設定しています。どちらのアルゴリズ較しても大体問題ないっす。そいでもって、カメラにはノイズがムで検出したかがわかるように、最初のフレームとの差分と直前つきものなので、適当な閾値を決めて、差分の絶対値が閾値以下フレームとの差分で色を変えておくと、修正の方向性が見やすくなら差分なしとした方が良いようです。実際の値はカメラとか環なるかと思います。

18

FDI・2021・07うんだな、これが。変更可能な変数は mut

でまあ所有権規則の魔宮をくぐり抜けた

このあたりをよく考える必要がありそうでというキーワードを付けて宣言しなければとして、今度は実行環境との相互作用といす。まあでも、エラー対処はどうしても状なりません。とすると、変数にはぱっと見う壁があります。ディレクトリを取得する

況依存になるため近視眼的なコードがずらて（1）不変なスタック変数、（2）可変なにはどうするか、ファイルリストを取得すずら続くことになり、ソースの見通しが悪

スタック変数、（3）不変なヒープ変数、（4）

るにはどうするか、ファイルを開くにはどくなるのはちょっといやーんな感じ。

可変なヒープ変数、という 4 種類があるこ

うするか、ファイルに書き出すにはどうす

そんなこんなでコンパイラと二人三脚（ととになります。実際にはこれに加えて（5）るか、外部コマンドを実行させるにはどういうか二人羽織）でなんとかアルゴリズム

借りてきた不変なヒープ変数を不変に使用、するなどなど。でこの山を超えると同時に、を実装してみたところ、perl だと動画 1 本（6）借りてきた可変なヒープ変数を不変でrust のエラーハンドリングという、第二のにつき数十秒かかっていた処理が、数秒程使用、（7）借りてきた可変なヒープ変数を魔宮が待ち構えているわけです。rust は構度にまで高速化できました。動画の処理は可変で使用、とかスマートポインタとか色々造化エラー処理を持たない代わりに、エラ餅屋にまかせて ﬀmpeg で ppm フォーマあるようですが、とにかくデフォルトではーが発生しうる場合、enum を返します。

ットで書き出してもらい、こいつらを rust不変です。不変の何がいいかというと、書

rust の enum は tuple みたいにいろんなで処理して ppm のサムネイルを書き出し、き戻されないことが保証されているので、型を持てるので、「成功した場合の型」とImageMagick の convert で jpg に変換しコンテクストを気にせず同じ値が使えると「失敗した場合の型」などを含む enum をて書き戻し、中間ファイル群を削除するということなんだろうと思います。一方で可処理する必要があります。真当に対処するいうような処理です。実行するマシンのメ

変な変数については、どのタイミングで読なら、すべてのありうる型との一致を調べモリはさほど潤沢ではないため、バッファみ出すかによって値が異なるため、処理のて適切な処理をするわけで、しかも抜けがをちまちま使いながら処理するわけですが、順番を入れ替える場合は注意が必要です。

あるとコンパイラがビシビシ指摘してくるガベージコレクタが動作しないため、最初また、所有権規則として「同時に 2 箇所以わけですが、まあそこまで頑張らなくてもから最後までほぼ同一ペースで処理できる上に可変な貸し出しはしない」「不変で借りいいんじゃないの、という場合もあります。のは頼もしいところです。C# とかだと頻てきた所有権は移動できない」というのがというか、趣味でなんかやってる場合はだ

繁にガベージコレクタを起動して、不要だあり、大変繊細なものになっていてややこいたいエラーなら死んでおけ、なわけです。

けど捨ててないバッファを回収しないとメしいです。これが脊髄反射的に状況が理解それ以前に動かないんだよ〜ってわけで。

モリリークが発生するところですが、このできるようになれば良いんでしょうが、なrust の場合、素晴らしいことにこのズボラ

苦労をコンパイル前に、人間様の方で負担

かなか ...

処理用の syntax sugar が山ほど用意されしておく、というわけですね。今回ちょっ

一方でコンパイラが出すメッセージは詳てることで、「エラー処理しなきゃいけないと手応えを感じたので、もうちょっと色々細かつ的確なので、かなり助けられます。

よね、うん、わかる。正しい。わかってる実装してみようかなと考えてます。今更

まあ大抵のポカミスはこの所有権絡みなのんだけどね、無視したいんだ、俺は。とりperl の手軽さを捨てる気もないのですが、で、はいはい借りまひょ、ありゃ駄目？じあえずこいつは。頼むから頓死させてくれ」

とっつきにくいけど rust は結構いいかもしゃ可変にしときますわ、とかやってると自という心境を表す expect（）とか unwrapれません。まあちょっと go も味見してみて、動的に問題がないプログラムができあがる（）とか unwrap̲or（）とかが用意されて決めたいところでもありますがという寸法なのでした。結果としてメモリおり、エラーを華麗にスルー（というか頓死）管理上問題がないなら、いいんじゃないかできるわけです。まあ rust の哲学からするな。うん。なんかこの、言語習得初期におと、回復可能なエラーは回復しとけやボケ、ける処理系におんぶでだっこな期間って、って感じだろうと思うので、可能であれば右も左もわからない具合がなんとも楽しい

そちらに従うほうが良いでしょう。特にラですよね。

イブラリを公開することを考えているなら、

Hiroyasu Sakaguchi株式会社 IMAGICA Lab.

19

FDI・2021・07