LogicoolのStreamCamがいいなって話

LogicoolのStreamCamがいいなって話
Photo by Emiliano Cicero / Unsplash

LogicoolのWebカメラの一つ、StreamCamをコロナによるオンラインミーティング以降からずっと使ってきている。結局当時はカメラオフの場面が多く、さほど使うことがなかったが、大学生となりカメラをオンにしたミーティングに参加する機会が多くなった。

StreamCam
StreamCamを購入。1080p 60 FPS、高性能オートフォーカスと露出、縦方向ビデオ / ポートレート方向、汎用マウント、USB-C、デュアルマイクなどが特徴です

きっかけは使っているラップトップのちょっとした不具合(キーボードバックライトが点灯しなくなった)を修理する際、メーカーのミスで画面を割ってしまい、ディスプレイの交換修理になった。出張修理ということで、メーカー委託の業者が修理してくれたのだが、ディスプレイ交換の際、内臓Webカメラを指でべったり触ってしまったらしく、カメラの保護フィルムの粘着層に指紋がついてしまったようで、使い物にならないほど白ぼけてしまった。

とはいえ別にオンライン授業で高画質な映像を届ける機会などないし、複数回にわたる修理で呆れていたので、特に何もせずそのままにしていた。

しかし、就活が始まり、オンライン面接に参加することが多くなり、さすがに白ぼけた画面のままではまずいとなり、しまっていたStreamCamを引っ張り出してきて使ったところ感動したというわけだ。

まず、つくりとしてレンズ部分がガラスで作られているので、写りが抜群にキレイだ。ずんぐりむっくりした見た目をしているので、画質に関して相当期待していたが、HDビデオという条件では全く文句のつけようがない。

そもそも画角が異なるので写りこみが多くなり結構焦る。今まで写っていなかった部屋のスミまで写りこむことになるので、気を付けないとぐうたら過ごしていることがばれてしまう!そもそもWebカメラとして設計されていて、そこそこ近い距離で使うことを想定しているのだろう。手元を写すときなどに便利なように広角レンズを設計されたのだと思う。相手視点ではむしろ顔面度アップにならずに、程よい距離考えられていいのだろうなとポジティブにとらえている。

贅沢にも質の良いマイクが二つ付いている。これが結構いい。ステレオで使うこともできるが、私はモノラルとして使っている。マイクのビーム機能があり、実際パソコンの内臓マイクを使っていたときには「ちょっと声が遠いです」といわれることもあったが、StreamCamを使ってからはそんなこともなくなった。

ソフトについて

ソフトウェアはどうやらLogicoolが迷走しているのか、いろいろなソフトを使えるようになっている。

使えるソフトウェアは次のとおり。

ダウンロード - ロジクール StreamCam

公式ページではLogicool Captureとの連携をうたっているが、なぜか今見てみるとダウンロードページにLogicool Captureの文字はない。まあ気にせず進みましょう。たぶんG HubかTuneが後継ソフトなのだろう。

  1. Logitech G HUB
  2. Logi Tune
  3. Logicool Capture

Logicoolの出しているソフトでWebカメラのコントロールを提供するソフトなら何でも使えるわけだが、どのソフトでコントロールをするにしてもまあまあ処理が重たい。しかも、設定だけして終わりというわけではなく、性能をフルで発揮するにはカメラを使用する際は常にソフトを裏で立ち上げていなければならない。正直クロマキー合成などは一切しないで、カメラとして普通に動作さえしてくれればいいので、私はLogitech G HUBを利用し、ソフトでの動作は意図的に切るようにしている。

おまけという名の本編

さて、ここから少しディープなお話をしよう。

せっかくスペックシートにいろいろ書いてくれているのだから、カメラ・レンズとしての性能を調べてみよう。

レンズスペック

StreamCamの公式スペック

レンズ
プレミアム フルHDガラスレンズ
f/2.0 - 焦点距離3.7 mm
視野: 78°(対角)
StreamCam
StreamCamを購入。1080p 60 FPS、高性能オートフォーカスと露出、縦方向ビデオ / ポートレート方向、汎用マウント、USB-C、デュアルマイクなどが特徴です

スペックシートからの抜粋

視野角からセンサーの対角線の長さを求める

視野角は以下の公式で求められる

$$\text{視野角} = 2 \times \arctan\left(\frac{\text{センサー対角線の半分}}{\text{焦点距離}}\right)$$

ということでセンサーの対角線の長さを求めよう。

$$78° = 2 \times \arctan\left(\frac{d/2}{3.7\,\mathrm{mm}}\right)$$

$$39° = \arctan\left(\frac{d/2}{3.7\,\mathrm{mm}}\right)$$

$$\tan(39°) = \frac{d/2}{3.7\,\mathrm{mm}}$$

\(\tan(39°) \approx 0.8098\) なので

$$\frac{d}{2} = 3.7\,\mathrm{mm} \times 0.8098 \approx 2.996\,\mathrm{mm}$$

$$d \approx 6.0\,\mathrm{mm}$$

センサーの対角線の長さが \(6.00\,\mathrm{mm}\) といわれても単位が \(\mathrm{mm}\) ではイマイチぴんと来ないと思うが、これは一般的なWebカメラで使われる1/2.9インチセンサー(対角線約 \(6.2\,\mathrm{mm}\))とほぼ一致する。

ここまで計算できたら、ボケの大きさも気になってくる。

クロップファクターを求める

ということで、センサーサイズのクロップファクターを求めよう。

フルサイズセンサー: \(36\,\mathrm{mm} \times 24\,\mathrm{mm}\)

$$\text{対角線} = \sqrt{36^2 + 24^2} \approx 43.3\,\mathrm{mm}$$

StreamCamセンサー: 対角線 \(\approx 6.0\,\mathrm{mm}\)

$$\text{クロップファクター} = \frac{43.3\,\mathrm{mm}}{6.0\,\mathrm{mm}} \approx 7.2\text{倍}$$

フルサイズ換算のボケ量を求める

ということで結論

フルサイズで同じボケ量を得るには、StreamCamの \(f/2.0\) に対して

$$f/2.0 \times 7.2 \approx f/14.4$$

💡
つまり、StreamCamの \(f/2.0\) でのボケ量は、フルサイズカメラの \(f/14\) 程度に相当する。

フルサイズ換算焦点距離を求める

クロップファクターが求まっているので、これは簡単

$$3.7\,\mathrm{mm} \times 7.2 \approx 26.6\,\mathrm{mm}$$

これまでの数値をまとめるとこういうこと

  • フルサイズ換算焦点距離: 約 \(27\,\mathrm{mm}\)(標準域の広角寄り)
  • センサーサイズ: 1/2.9インチ相当
  • ボケ量: フルサイズの \(f/14.4\) 相当

画質を考える

画質は画素数でもセンサーサイズでもなくセンサーの画素ピッチ(一画素の大きさ)によって決まります。

画素ピッチを求める

仮にセンサーのアスペクト比を記録画素の通り \(1920 : 1080 = 16 : 9\) として考えてみる。

センサーの実サイズを計算すると

  • 水平方向: \(6.0\,\mathrm{mm} \times 16/\sqrt{16^2 + 9^2} = 6.0 \times 16/\sqrt{337} \approx 5.37\,\mathrm{mm}\)
  • 垂直方向: \(6.0\,\mathrm{mm} \times 9/\sqrt{16^2 + 9^2} = 6.0 \times 9/\sqrt{337} \approx 3.02\,\mathrm{mm}\)

画素ピッチを計算

  • 水平方向: \(5.37\,\mathrm{mm} / 1920\text{画素} = 2.8\,\mathrm{μm} / \text{画素}\)
  • 垂直方向: \(3.02\,\mathrm{mm} / 1080\text{画素} = 2.8\,\mathrm{μm} / \text{画素}\)

すると画素ピッチがどちらも \(2.8\,\mathrm{μm}\) とそれっぽい値が出てきたので、これを画素ピッチとして考えよう。

せっかくなので比較してみよう

StreamCamは \(1\text{画素} = 2.8\,\mathrm{μm} \times 2.8\,\mathrm{μm}\) ということで面積: \((2.8\,\mathrm{μm})^2 = 7.84\,\mathrm{μm}^2\) となる。

手元のiPhoneが15 Proなのだが、どうやら調べてみると14 Proと15 Proは同じSony製センサーIMX803を採用しているらしい。ということでこのセンサーと比較してみよう。

iPhone イメージセンサー一覧|orangemeca
カメラ性能の指標としてはF値や解像度などがありますが、その中でもイメージセンサーのサイズに着目してiPhoneのカメラのイメージセンサーを整理しました。 イメージセンサーはサイズこそ正義なところがあり、大きいほど光を集めやすい=高画質になる傾向にあります。 公開されている仕様では画素ピッチが該当します。 (ただし1画素あたりのサイズになるので高解像度になると小さくなります) イメージセンサー一覧 iPhoneのイメージセンサーはSONY製のため、iPhoneのカメラの進化はSONYのイメージセンサーの進化とともにあるようです。 メインカメラでは15 Pro/Pro MaxはIMX903

素朴に画素ピッチを求めると \(1.22\,\mathrm{μm}\) と分かる。

が、iPhoneではピクセルビニングという仕組みを利用して見かけ上の画素ピッチを大きくしている。ピクセルビニングといわれると「なんだその意味不明な専門用語は」と思うが、英語で書けば単純。Pixel Binningということで隣接するピクセルをまとめているだけだ。つまり \(2 \times 2 = 4\) 画素を1画素として扱う技術で、これで画素ピッチが実質 \(2.44\,\mathrm{μm}\) とみなせるようになり、画質が若干高くなるという算段だ。

画素ピッチが分かったので、1画素の面積を求めよう

  • ピクセルビニング(高画質モード)では \((2.44\,\mathrm{μm})^2 = 5.95\,\mathrm{μm}^2\)
  • ノーマル(高精細モード)では \((1.22\,\mathrm{μm})^2 = 1.49\,\mathrm{μm}^2\)

次の表は、光子ノイズ \(\propto 1/\sqrt{\text{画素面積}}\) と考えた場合の比較結果だ

デバイス 画素ピッチ 画素面積 光量収集力比較
StreamCam \(2.8\,\mathrm{μm}\) \(7.84\,\mathrm{μm}^2\) 基準
iPhone Pro(個別) \(1.22\,\mathrm{μm}\) \(1.49\,\mathrm{μm}^2\) \(0.19\)倍
iPhone Pro(ビニング) \(2.44\,\mathrm{μm}\) \(5.95\,\mathrm{μm}^2\) \(0.76\)倍
フルサイズ参考 \(6\,\mathrm{μm}\) \(36\,\mathrm{μm}^2\) \(4.6\)倍

段数(stop)で考える方が写真の世界では実用的で、実際のノイズレベルも理解しやすくなる

デバイス 段数差 等価ISO 実用的評価
フルサイズ参考 基準 ISO 100 最高画質
StreamCam \(2.2\)段劣化 ISO 459 良好な画質
iPhone Pro(ビニング) \(2.6\)段劣化 ISO 605 やや劣化
iPhone Pro(個別) \(4.6\)段劣化 ISO 2416 高ノイズ

この数値が意味することを実際の撮影で考えてみると

フルサイズでISO100で撮れる明るさの環境で撮影した場合

  • StreamCamは理論上「ISO459で撮影したような」ノイズレベル
  • iPhone Proは「ISO605で撮影したような」ノイズレベル

つまり、StreamCamの方が約25%低いノイズを実現できる計算になる。

実用的な影響を考察

いろいろ計算をしてきたが、実用的な影響を考えてみよう。

この $0.4$ 段の差は実際にはどの程度の違いだろうか。

低照度撮影において

  • 理論上、StreamCamの方がiPhoneに比べてわずかにクリーンな画像を生成する可能性があると言える
  • ただし、$0.4$ 段の差は肉眼では判別困難なレベル
  • ピクセルビニングを行わないiPhoneの画像と比較すれば $2.4$ 段の差にもなるので、肉眼でも容易に判別できるほど画質が向上していることがわかるだろう

高照度(十分な明かり)では

  • 両者ともノイズが十分少なく、差はほぼ見えない
  • ソフトウェア処理の差の方が大きく影響

実際の使用ではその後ソフトウェアでの処理が入る。iPhoneでは複数枚の画像を合成してノイズを減らすこともあるし、そもそもノイズリダクション処理がなかなか洗練されている。

StreamCamとiPhone Pro個別画素の差は約 $2.4$ 段となる。これを光量で表現すると、StreamCamはiPhone Pro個別画素の約 $5.3$ 倍の光を集められることになる($2^{2.4} \approx 5.28$ 倍)。

この差の実用的な意味を考えてみよう。

同じ照明条件下で撮影した場合、iPhone Pro(個別画素)で発生するノイズは、StreamCamの5倍以上になる計算だ。これは確実に肉眼で分かるレベルの違いだ。具体的には、StreamCamでは滑らかに見える暗部の階調が、iPhone Pro個別画素では明らかにザラザラとしたノイズまみれになる感じ。

ここでも重要なポイントがあって、iPhone Proは実際には個別画素で動作することは滅多にない。

iPhone Proの動作モードを整理すると次のようになる

  • 通常撮影: 4画素ビニング($2.44\,\mathrm{μm}$ 相当)で12MP出力
  • ProRAW撮影時のみ: 個別画素($1.22\,\mathrm{μm}$)で48MP出力

つまり、一般的な使用では iPhone Pro は常にビニングモードで動作しており、StreamCamとの差は先ほど計算した $0.4$ 段程度に留まる。

それでも、iPhone ProのProRAWモード(個別画素)を解像度の観点から比較すれば面白い考察ができますヨ。つまり、48MPでわざわざ撮るときは、詳細な画像が求められる時であって解像度が必要な時というわけ。

ProRAWで48MP撮影する場合、確かにStreamCamよりもノイズは多くなるが、その代わりに約23倍の解像度(48MP vs 21MP)を得られる。つまりこういうこと

  • ノイズレベル: StreamCamが圧倒的に優位($2.4$ 段差)
  • 解像度: iPhone Pro個別画素が圧倒的に優位(23倍 $\approx 2.26$ 段)

23倍を段数に変換すると $23 = (4.8)^2$ なことから、$\log_2(4.8) \approx 2.26$ 段となる。人間の視覚は、解像度が2倍になっても2倍の細かさを感じ取れるわけじゃないのであまり参考にならないですが、まあざっくり解像度と画質がトレードオフになっていることを理解できると思います。

おわりに

綺麗!とかそういった定性的な分析はあてにならん!ということで、定量的に分析してみたよ。StreamCamに限らず、あらゆるカメラで分析手法は使えるわけで、気になったカメラで比較をしてみると面白いかもね!

と、いうわけでStreamCamとiPhoneのカメラを比較してきたわけですが、結局StreamCamはiPhoneのカメラぐらいなのかなって印象を持ったのじゃないでしょうか。

しょぼいと思うか、すごいと思うかはあなた次第。

僕はいい商品だなって思うよ。

Read more

TailscaleのSubnet Routesを消す

SynologyのNASにTailscaleを導入し、便利に使っている。 TailscaleにはSubnet routersという機能がある。 これは、Tailscaleネットワークに接続されたデバイスが、そのデバイスが接続されているローカルネットワーク(サブネット)全体へのアクセスを他のTailscaleデバイスに提供できる機能だ。つまり、Subnet routerとして設定されたデバイスを経由することで、Tailscaleネットワーク上の他のデバイスから、そのローカルネットワーク内の機器にアクセスできるようになる。 Subnet routers · Tailscale DocsUse subnet routers to give devices outside your local network access to services within specific subnets. Extend your private network with Tailscale.Tailscale 便利そうだなと思って設定をしてみたものの、結局使うことがなかった。 公式ドキュメント

By Sakashita Yasunobu

Boids

群れに指揮者はいない 鳥の群れは、誰かが指示を出しているわけではない。魚の群れも同じ。それぞれが周囲を見て、少しだけ動く。その繰り返しが、全体として秩序ある動きを生む。 これを1986年にCraig Reynoldsがコードで再現した。名前は Boids(bird + oid)。個体に与えるルールは3つだけ。 1. Separation ── 近すぎたら離れる 2. Alignment ── 周囲と同じ方向を向く 3. Cohesion ── 群れの中心に寄る これだけで、群れは群れらしく動く。 なぜ作ったか 群れの動きは、見ていて飽きない。 * 単純なルールから複雑な動きが生まれる ── 創発(emergence)の典型例。設計していないのに、設計したかのように見える。 * 自分のブログに置きたかった ── 静的なページに、動くものがあると空気が変わる。 * Web Components で作りたかった ── どこにでも持っていける部品として。 設計の話 見えないときは止める 画面外でアニメーションを回し続けるのは無駄。Inte

By Sakashita Yasunobu

Days Elapsed

一年を「面」で見る 一年は365日。数字で見ると多いけど、並べてみると案外少ない。 12ヶ月を並べて、過去を塗りつぶして、今日を光らせる。それだけのカレンダーを作った。進捗バーが「一次元」なら、これは「二次元」の進捗表示。 Year Progress一年は50週ちょっとしかない 2026年を週で数えると、52週とちょっと。 カレンダーで見ると長そうなのに、週で数えると急に短くなる。そんな感覚を形にしたくて、このページの上の方に進捗バーを置いた。 やっていることは単純で、「今年が何%進んだか」をリアルタイムで表示しているだけ。 なぜ作ったか 理由は3つある。 1. 時間を「量」として見たかった ── イベントや予定ではなく、単純に「どれだけ経ったか」を数値で見たかった。 2. 目に見える形にしたかった ── 抽象的な「一年」を、動く数字に落とすとどう感じるか試したかった。 3. 自分の場所に置きたかった ── 誰かのツールを借りるのではなく、自分のブログに自分で作ったものを置きたかった。 実装の話 せっかく作るなら、

By Sakashita Yasunobu