エンジニアの醤油漬け

醤油大好きなとあるエンジニアのブログ

Insta360 ONE Xをスキー・スノーボード撮影に使ってみた感想

いきなりですが、

f:id:ubansi:20190212032218j:plain

Insta360 ONE Xを購入しました。

※この記事はアフィリンク多数です!筆者に収益が入るのが気に食わない人は商品名でググってください!

概要

  • Insta360 ONE Xすごい
  • デメリットはあるがアクティビティをやるなら買いだと思う
  • スキー・スノーボードの撮影は楽しい

今回レビューするのはこのカメラです。

スキー・スノーボードの撮影は楽しい

そもそもなんでカメラなんか持っていくのかって思う人もいるかもしれません。 以前は自分もそう思っていたと思います。

でも、いざ撮影して動画を作ってみると

  • 自分の滑りをチェックできる
  • もっとうまくなりたいと思うようになる
  • 行ってない人にも動画を見せながら話題にできる

というメリットが有りました。

ちなみにそのときに作った動画がこちら


YOZORA in yuzawa park short ver

その年の滑りが残るので、上達具合が見られてみんなの向上心が高まって 次、行くときのモチベーションになったようです。

アクションカメラAKASO EK7000

今まではAKASO EK7000という安いアクションカメラを使っていました。

お値段8000円以下で、オプションパーツもたくさんついてくるので、入門にはいいと思います。 ただ、手ぶれ補正がないのでそのままだと下の動画のようになってしまいます。


AKASO EK7000 追い撮り

かなりブレがひどいですね。

そこで、この動画に動画編集ソフトでデジタル手ぶれ補正(ワープスタビライザー)をかけて、安定化させて利用していました。

手ぶれ補正かけたのが下の動画になります。


AKASO EK7000追い撮り(デジタル手ぶれ補正版)

だいぶ安定しますが、動画の画面サイズが小さくなってしまいます。

そのため、補正前は画角に収まりきっていた場合でも手ぶれ補正をかけたときにフレームアウトしてしまう場合があったりします。

個人的には、もう少し高い手ぶれ補正付きのカメラを買うのが良いかもしれません。

こんなのです。(使ったことないですが…)

あると便利なオプションパーツ

とりあえず手持ちで撮影するのは難しいと思うので、 自撮り棒はあったほうがいいと思います。

雪山のカメラ撮影をやったことある方にはおなじみかもしれませんが、 寒い場所だとバッテリーがヘタります。 なので、

  • 自撮り棒
  • ヘタリ防止用の保冷パック
  • 予備バッテリー(3個ぐらいあると良い)
  • モバイルバッテリー

の4つがあると便利です。 普段は、保冷パックに予備バッテリーとモバイルバッテリーを入れておき、 バッテリーがヘタったら交換する感じにしています。

だいたい1日の撮影でバッテリー2個使い切るかどうかっていう状況なので、 余裕を持って3つぐらいあると良いと思います。

ただ、撮影した動画を非圧縮で受け渡すときにカメラとスマホのバッテリーをガンガン消費するのでモバイルバッテリーも持っていってます。 もちろん、モバイルバッテリーからカメラのバッテリーへの充電もできるので、その点でもあると良いです。

ちなみに使っているのはこの商品です。

Insta360 ONE X

前置きが長くなりましたが、やっと今回買ったInsta360 ONE Xの話になります。

Insta360 ONE Xは一言で言うと360度カメラです。

ただ、このカメラはアプリがすごい。

  • 鬼のような手ぶれ補正機能
  • アプリで対象を指定しての画面追従機能

手ぶれ補正も強力なのですが、Gセンサー+画像解析を組み合わせたターゲット追従機能がすごいです。

Insta360 ONE Xを使って撮った動画が次の動画です。


Insta360 ONE X 追い撮り

生憎の天気で写りは悪いですが、こんな感じで常に被写体を画角に収めながら手ぶれ補正をかけることが出来ます。

また、スマホのアプリでトリミング、ターゲット追尾などの加工ができるので 撮影して編集して切り出してその場でシェアというようなことも出来ます。

メリット

恐ろしいぐらいの手ぶれ補正

まずはなんと言っても、手ぶれ補正の凄さ。 意図的に振り回してもある程度までならなんとかなってしまいます。 しかも、360度撮影しているため、手ぶれ補正をかけたときの画面サイズの縮小がない これだけで十分選択肢に入ります。

画角を気にしなくて良い

普通のアクションカメラは撮影中に対象を追っかけながら、 画角を考えて撮影するためどうしても滑りに集中出来ませんでした。

また、カメラのブレをなるべく減らすために気を使わなければなりませんでした。

Insta360 ONE Xでその悩みから開放されたのはすごく大きいと思います。

具体的に挙げると、

  • 難易度の高い斜面でも安定して撮影可能
  • 撮影対象に寄ることに集中できる

というメリットがありました。

SmartTrack

Insta360 ONE Xで撮影した動画は360度動画なのですが、そこから普通の動画に切り出す際にカメラアングルを指定しなければいけません。

ここですごいのが、SmartTrackというアプリの機能で動画の編集時に対象を指定すると勝手にその対象が中央に来るように画角を調整した動画を作成出来ます。

SmartTrackについては公式動画をみるとわかりやすいかもしれません。


Insta360 ONE X - SmartTrack

自分が撮影した動画もSmartTrackで追従させています。

デメリット

バッテリーが弱い

電池の持ちはAKASO EK7000より悪く、 4~5時間滑る中でバッテリー2個で運用しましたが、

途中で足りなくなってしまい、途中で撮影中止してモバイルバッテリーから充電していました。

リフトに乗る時間、リフトに並ぶ時間などがあるので実際にカメラを回した時間は20分前後でしたが、ちょっと足りないかなという感じです。

バッテリーは3~4個あったほうが良さそうです。

給電しながらの撮影も出来ますが、雪山だと基本的に防水カバーをつけての撮影になると思うのでその際は給電できないので注意が必要です。

2019/02/13 追記

低温用バッテリーがあるようなので、 スキー・スノーボードの場合はそちらを利用すると多少長持ちするようです。

謎の停止

原因不明なのですが、回したはずのカメラが気がつくと停止してシャットダウンされる問題が有りました。 原因として考えられるのは

  • 操作ミスでビデオモードになっていなかった
  • 低温でバッテリーの電圧が下がってしまった
  • 振動で勝手にOFFになった

が考えられますが、不明です。

オプションパーツが高い

AKASO EK7000のような低価格商品じゃないので、そこそこオプションパーツの値段が張ります。 本体価格+1~1.5万円ぐらいは見積もったほうがいいかもしれません。

映像が思ったより遠い

映像をみると微妙に距離が遠いなと思いました。

他のアクションカメラも広角レンズなので思ったより距離が遠くなりがちなのですが、Insta360 ONE Xではさらに想定より遠く感じました。

おそらく一番「画が映える」距離は2~3mだと思われますが、 並走するには近すぎ、自撮りするには遠い微妙な距離な気がします。

長めの自撮り棒を用意するのがいいかもしれないです。

あると便利なオプションパーツ

こちらも同様に

  • 自撮り棒(1m以上のものがあると良さそう)
  • 防水ケース
  • 予備バッテリー(3個~4個あると良い)
  • モバイルバッテリー

自分は先程の3Way自撮り棒を使って撮影しましたが、 長さに不満があったので長めの自撮り棒を用意すると良いと思います。

防水ケースはスキー・スノボの撮影では必須だと思います。 なければSDカード挿入口やUSBの口がむき出しになってしまいます。

自分の場合防水ケースは品薄のため買えなかったので、やむなく潜水ケースを買いました。 ただ、潜水ケースのほうが高く画面表示がとても見にくいので、防水ケースのほうが良さそうです。

予備バッテリーはたくさん欲しいところです。 防水・潜水ケースを利用すると給電撮影ができないのでバッテリー頼みになります。

モバイルバッテリーについては先程と同様 現地で予備バッテリーを充電したり、スマホにデータを移す時に利用することになるでしょう。

ちなみに、このダンボーのモバイルバッテリーはUSBが2つあるのでカメラのバッテリーとスマホのバッテリーを同時に充電できておすすめです。

この自撮り棒は次回利用予定。

Insta360 ONE Xは買い?

買いだと思います。

上ではデメリットをたくさんあげましたが、それでもメリットのほうが大きいと思います。

まず、360度カメラの可能性として、 たとえばキッカーの頂上に挿しておけばジャンプの前後が取れたり、 みんなで滑る時に全員を撮影するということも可能です。

また、自分はスキーでの撮影ですが、 スノーボードで普通のアクションカメラを使って撮影する場合、 安定してフレームに入れるのはかなり難しいと思います。

その点気にしなくていいので360度カメラでの撮影っていうのは撮ってもらいやすいというメリットもあります。

その上で、強力なアプリの補助があり、手軽に運用ができるInsta360 ONE Xを選ぶのは十分有りだと思います。

また、今までアクションカメラを使ったことない人は、ぜひ安い物でも良いので一つ買ってみると良いと思います。

いい感じの動画が取れたときの被写体の人も撮影者もテンションがあがって、 またそれを残せるというのは素晴らしいことだと思います。

ただ、撮影の際は周囲の安全に気をつけましょう。

最後に、いつもボード誘ってくれて動画を使っても良いって言ってくれた友人に感謝!

去年の振り返りと今年の目標(2018)

あけましておめでとうございます。

今年もよろしくお願いします、

というか今年こそは記事書こう。

去年の目標

JavaScriptフレームワーク習得

Vue.jsは趣味程度に少しだけ触りました。

習得出来たかと言われると微妙なところですが、50%ってところでしょうか。

ゴールが不明瞭なタスク設定だなと反省しました。

Java Api読破

業務でJavaを使わなくなってしまった(一部使ったけど)ので、優先度下げます。

技術情報の発信を月一以上

すみません。

年間で2本だったので、2/12なので、16%ってところでしょうか。

サーセン

去年やったこと

転職

前職では、Javaのサーバをオンプレで作ってましたが、

PHPでサーバをクラウドで作成したり、 お客さんの要望にあわせてクラウドの構成の設計したり クラウド上に環境構築したり、 いろいろやらせてもらっています。

身につけた技術

PHP

ある程度は書けるようになってきました。

古いバージョンのPHPのレガシーコードをいじってた頃は

Javaで書きてー!」という感想でしたが、

PHP7触ってると、どっちでも良くなってきました。

ただ、IDEの補間はやっぱJavaのほうが強力なのかなと思います。 その代わり、細かい所に手が届く関数が沢山用意されているなぁという印象です。

Google Cloud Platform

結構大きめなプロジェクトの構成を0から設計させてもらいました。

  • Cloud Storage
  • Compute Engine
  • App Engine
  • Cloud Dataflow
  • BigQuery
  • Cloud Functions
  • Logging

での開発経験が積めました。 今年中に認定資格取りたいと思います。

ShellScript

今の会社に入って最初にお願いされたのがGitのリリースシェル

それからなんだかんだ使う事が多かったので、

人並みには使えるようになったつもりです。

というか、あまり複雑な処理をやる場合は言語選定で外しますが…。

Node.js

主にCloud Function向けのスクリプトを書きました。

ただ、そこで作ったモジュールを再利用した結果データ整理などを行うスクリプトが全て ShellScriptとNodeで出来てしまいました。

コールバック地獄からPromiseに置き換えて、その後asyncで書くという

非同期処理パラダイムを一通り経験できてよかったと思います。

Electron

趣味で触ってます。

メイン画面を立ち上げたらあとはWEBサービスと同じ感覚で触れますね。

ただ、サブ画面とかを立ち上げるときはまたElectronの世界に連れて行かれます。

Mocha & Chai

こちらも趣味で導入しました。

JavaScriptユニットテストを今まで出来ていなかったのですが、 やっと出来るようになりました。

正規表現

簡単な正規表現なら何も見ずに書けるようになってしまいました。

特に()$1(マッチングのグループ化ができる)にはお世話になってます。

$1を覚えてからは大抵のことはVSCodeで出来るので、エクセルいらずになりましたね。

カンファレンス

JJUG

春、秋両方でLTしました。 秋のLTはGCPのCloud Dataflowについてです。

docs.google.com

LTに収まらずにオーバーしてしまったので、 どこかでロングバージョンを発表できればいいなと思ってます。

東京Node学園祭2018

などが聞けて面白かった。

ただ、英語のセッションが多くてしんどかったです。

GitHub

ID作ってしばらく放置していましたが、活動し始めました。

DateTimeParser

QiitaのJavaアドベントカレンダー向けの解説用コードを公開しました。

github.com

Johari

デスクトップ向けの画像整理&閲覧用のアプリ作り始めました。

とりあえず、ローカルの画像ファイルに

  • 画像一覧の表示
  • 画像にタグ付け
  • 画像DBの作成

などが出来ます。 将来的には、ソートしたり画像の保存先を管理したり ムフフな画像をこっそり管理したり… 出来たら良いなと思ってます。

しかも、これHTMLで表示しているので、 例えばS3、GCSに画像を置いて一元管理するとか… WEBページにしちゃうとか… 夢は広がります。

まだ、開発者向けという段階で、機能も乏しく完成度も低いです。 これからってところですね。

github.com

今年の目標

GCPの資格取得

クラウドアーキテクトを取得したいと思います。

技術情報の発信を月一以上

がんばる

Johariをある程度形にする

ざっくりとした目標ですが、ゴールは 「一般公開出来る状態にすること」です。

必要なのは

  • 配布ページ
  • ドキュメント
  • 適切なエラーメッセージ

を揃えることだと思います。 ある程度の機能ができた段階で、この3つを用意できれば完了かなと思います。

この3つを今年は頑張っていこうと思います。

転職エントリです

退職者その2 Advent Calendar 2017 7日目です。

adventar.org

自分は去年まで SIerで官公庁向けにJavaでオンプレサーバを作る感じの仕事をしていました。

きっかけ

転職のきっかけは去年のNode学園祭2016でした。

Nodeのユーザーグループの勢いと熱気を目の当たりにした後、

自社の冷めた環境を見て

「今は熱意を持って勉強している、
ただし、この環境に5年10年居たらどうだろう。
そして、その時には外に出られない人間になっていないだろうか。」

と危機感を覚えました。

元請けにすべてを委ねて、競争しなくても仕事がある会社。
基本情報を取った人間が褒められる会社

恐らくこの会社に長く居たら"野生"で行きていけない技術者になるだろうと思いました。
ベンチャーで働いている友人が眩しく見えました。

退職

12月頭にとりあえず辞めることを会社に伝えました。
転職先は完全に未定でしたが、

  • 20代
  • Javaエンジニア

で、ホームレスになることは無いだろうっていう見込みでした。

転機

転機となったのが去年のJJUGでした。
その場のノリで業務コードを改善した話をまとめてLTしちゃいました。

qiita.com

このあと、今の会社の方に声をかけていただき
無事に転職先が決まりました。
(Qiitaを見てTwitterでも声をかけていただけました。ありがとうございました。)

辞めると言った2日後でした。

比較

技術

前職と比べて要求される技術が上がったと思います。

前職では基本的に出来ることを任される感じでしたが、
今の会社は今出来ないことをチャレンジして解決することも要求されてます。
仕事をすすめるたびに自分の技術力が上がっていくのでやりがいはでかいです。
忙しくはなりましたが、経験値が増えたと思ってます。

あと仕事としても要求されるレベルが高くなったと思います。
「解決するために何が必要か」で自主的に動かなければいけない。
前の会社ではまだ自分はお客様扱いだったのかなと思います。

社員

ベンチャーだけあって、技術的な熱意が高いと思います。

  • 外部発表や、記事の連載などをしている人がいる
  • カンファレンスも一緒に参加する人がいる

そして、こんな人らにSlackでいつでも質問できるのはすごい恵まれてる環境だと思います。

福利厚生

言ったら会社がバレそうですが、

がデフォです。 プラスで

私費でオライリー買ってたのでかなり助かりました。

ちなみに前職では

  • Windows機一台
  • ディスプレイ1つ
  • 普通のオフィスチェア

地理的な案件があり、流石にディスプレイ1枚だと辛いので 自前で持ち込んでました。

給料

微アップでした。

結論

案外辞めてもなんとかなる。

あと、何らかのコミュニティやカンファレンス、勉強会で

  • 自分の会社の客観的な技術レベル
  • 自分の客観的な技術レベル

コレは知っておいたほうが良いかなと思います。

Java アドベントカレンダーの2日目書きました。

Javaアドベントカレンダーの2日目書きました。

qiita.com

今やってる案件が

「いろいろなシステムからデータ出力してもらい、 そのデータをBigQueryに入れて解析しようぜ!」

って案件で、DBごとの時間文字列の違いに悩まされたので、 その問題だけ抽出してフルスクラッチでモジュールを作成しました。

いい感じに出来たので業務コードに反映しようかなと思ってます。

はじめはクラス1つ作って、処理べた書きの殴り書きでやっちゃおうかと思ってましたが、 せっかくなのでしっかりクラス作りました。

はじめはインターフェースで作ってたのですが、 例外ログ周りの共通処理が出てきたので抽象クラスになりました。

コードはGitHubに上がってるので、ご自由にお使いください。 ただし、同一インスタンスを使いまわす場合に解析自体はできるけど、 ログがスレッドセーフじゃないのでご注意を。

気が向いたら修正するかも。

ちなみにコードのほとんどは帰宅途中の地下鉄東西線の車内で書きました。 リアルに移動し続けるノマドスタイルのプログラミングです!

そう言えばQiitaがおしゃれデザインになっていて、Qiita臭がしなくなって残念。

でも、使いやすい感じになったんで良いと思います。

JJUG CCC 2017 Fall 参加してきました。

久しぶりの更新になりますが、生きてます。

(ビックデータ案件で死にかけてましたが…)

先週、土曜日に行われたJJUG CCC 2017 Fallに参加してきました。

www.java-users.jp

JJUG CCCは日本Javaユーザグループが年2回行っているカンファレンスです。

今回のタイムテーブルをみると、

サーバーサイドのKotlinの話が2つもあって

いよいよBetter Javaとして使われだしているのかなという雰囲気がします。

気になったセッションは、「新しいプログラミング言語の学び方 ~ HTTPサーバーを作って学ぶ Java, Scala, Clojure ~」です。

JavaScalaClojureでHTTPサーバを作って、

正規表現や、並列処理などの書き方の違いを学ぼうというようなセッションでした。

確かに、新しい言語を学ぶ時にWEBサービスを作ろうとすると

DB周りとか、フロントエンドの実装が面倒で

気がついたら熱が冷めてるってあるんですよね。

そんな時にHTTPサーバがちょうどいいお題だというのは、とても納得しました。

そして、最後の懇親会ですが、

またLTをしてきました。

内容は「やってみようGoogleDataflow」です。

現在携わっている案件がまさにGoogle Dataflow(Java)使っているので、

そこで得た知見などを発表してきました。

資料はこちらです。 docs.google.com (WEB版は個人情報を濁してます。)

今回から、LTが事前申し込み制になってしまい、

正直発表は緊張しました。

そして、残念ながら、時間がオーバーしてしまったので、反省してます。

(そして、LTなのでもっとユーモラスにすべきだったとも反省)

どこかで普通にこの内容でセッションできればな~と思っています。

ちなみに、今週末はNode学園祭ですね。

nodefest.jp

こちらは土曜日に参加しようと思っています。

あと、Javaアドベントカレンダーも申し込みました。

qiita.com

まだ枠が空いているようなので、ネタがある方は是非どうぞ!

オブジェクト指向設計分析の感想

Head First オブジェクト指向設計分析が読み終わったので感想。

オブジェクト指向について復習したかったので、読みました。 いままでJavaでアプリを作成してきましたが、 なんとなくで作成したり、 オブジェクト指向の原則を網羅する機会がなかったりしました。

大学でもオブジェクト指向設計概論とかあった気がしますけど…

なんか設問に対して、ポリモーフィズムとかインターフェイスとか穴埋めしていけば合格もらえた感じだった気がします…w

前職では、クラス設計がひどいソースを渡されて保守させられたり、 社内でも理解していない人がいたりでした。

そこで、基礎から勉強しなおそうかなと思い手に取りました。

この本を手に取った理由は著者紹介です。

Brett McLaughlin はギター奏者だが演奏してもお金がもらえない事に苦しんでいる。 しかし、最近になってプログラミング技術を向上させる書籍を書けばお金がもらえることに気づいた。

という感じのジョークから始まる。 このジョークに惹かれて買いました。 こんなフランクな感じですが、O'REILLYです。

内容としては、図や記号などが多くわかりやすいのですが、 若干回りくどいかな?と感じました。

恐らく業務での開発経験や失敗経験がない人でも分かるように例を用意しているのでしょう。

一番大事なのは設計の原則を述べている8章の内容でしょう。

ということで簡単に8章の内容をまとめたいと思います。

8章まとめ

開放閉鎖原則 (OCP: Open-Closed Principle)

クラスは拡張に開放され、修正に閉鎖されるべき。

  • 機能をクラス内に留めることで、修正時に他に影響がないようにする
  • 機能を拡張したい場合は、クラスを継承し、オーバライドする

繰り返し禁止原則 (DRY: Don’t Repeat Yourself)

共通する事柄を抽出し、一箇所にまとめることでコードの重複を防ぐ。

  • クラスと機能を意味のある状態に保つために必要
  • システムの分割方法を最適化することにも繋がる

単一責任原則 (SRP: Single Responsibility Principle)

オブジェクトは単一の責任を負い、サービスは単一の責任を遂行する。

  • オブジェクトが行うあのは一つの責任
  • あるオブジェクトの変更理由が1つしかなければ単一責任原則が実装できている

その他にも [クラス名]は自分自身を[メソッド名]する。 という文章が成り立つ場合は良いが、成り立たない場合は他のクラスに移動すべき。

例)

○自動車は自分自身を発進する
×自動車は自分自身を洗車する → メンテナンスは別クラスの仕事

リスコフ置き換え原則 (LSP: Liskov Substitution Principle)

サブタイプは基底タイプと置き換え可能でなければならない。

8章以外

インターフェイスに対して実装を行う

これにより新しいオブジェクト、クラスに対しての拡張性が増すため。

テストを意識する

ユニットテストなどができるようにする。

というのもありました。

オブジェクト指向を見直したい方にはおすすめです。 少し高いですが…。

関係ないですけど、明日から新しい会社にジョインしPHPerになります。

ちょっと不安ですが頑張ろうとおもいます。

レコチョクさん主催AWSハンズオンに参加してきました。

recochoku.connpass.com

19:30からという参加し易い時間帯で、 初心者からも参加可能というものだったので参加してきました。

内容は

などをして、 最終的には EC2を2つWEBサーバにして、 ロードバランサーを割り当て。 そこにDNSサーバでドメインを割り当てる。 ってところまでやりました。

内容自体は問題なかったのですが、 SSHのクライアントにWinSCPを用意していたら yumコマンドでApacheのインストールの応答に返答できずに積みました。 急遽Teratermを入れて進行しました。

それ以外は特に問題もなく進行しました。

レコチョクさんのハンズオン参加は初めてでしたが、

  • 仕事終わりに参加しやすい
  • 適度な速さ
  • アシスタントの厚いサポート
  • 図が多くて詳細な資料

って言う感じで、 とても理解しやすかったです。 欠点といえば部屋が暑かったぐらいでw

来月もやるそうなので、 参加できたら参加しようと思います。

興味のある方はぜひご一緒にどうでしょうか。