Androidで画像をデコードするときの注意点
Androidでは画像の読み込み方法に大きく分けて二つの方法がある。
- SDカードなどパスを指定しての画像読み込み
- リソースフォルダdrawableに入っている画像のIDを指定して画像を読み込み
前者は基本的に副作用のないごく普通の画像デコード。
しかし後者は知らないと躓く場合があるのでまとめておく。
decodeResourceは画像のサイズ変更が行われる
BitmapFactoryのdecodeResouceメソッドは読み込んだ画像をViewで表示することを目的に作られているらしく、読み込んだ画像はAndroid端末の解像度に合わせて自動的にサイズ変更されたうえでBitmapインスタンスとして渡される。
単に画面上に表示するだけであれば問題ないが、画像処理をするために読み込んだ場合はこれが問題となることがあるので注意が必要。
Android2系ではdecodeResourceでBitmap.Configを指定しても無視される
Android4系では無視されることがないので2系に対応しているアプリを開発している場合は注意が必要である。
解像度は元画像のサイズ、Bitmap.Configを指定して読み込みたい(Android2系)、といった場合はdecodeStreamを使う。
decodeStreamの引数にはInputStreamが必要となる。
リソースファイルをInputStreamとして取得するにはResourcesのopenRawStreamメソッドを利用する。
以下は実装例。
InputStream istr = context.getResources().openRawStream(R.drawable.image);
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inPreferedConfig = Bitmap.Config.ARGB_8888;
Bitmap image = BitmapFactory.decodeStream(istr, null, opts);
2画面スマホ Medias W レビュー
購入の動機-Galaxy Note捨てたい
本当はもう少し待ってから買おうと思ってたのですが、Galaxy Noteが使えない子なので我慢しきれず半月ほど前に購入しました。
Galaxy Noteからの乗り換え候補としてはXperia ZとかOptimus Gとかあったのですが、ガジェット好きの自分にはどうしても変態2画面のMedias W が気になって仕方がなかったのです。
正直、「この変態さ加減はいかがなものか」と思っていたのですが、店頭で試しに数回使ってみると案外癖がなく良い感じなことが分かってからというもの、いつ買おうか悩みに悩んでいた次第なのです。
外見-裏表上下がわかりにくい点対称デザイン
実物を見たことのない人が「2画面スマホ」という言葉から連想するのはSonyが以前販売していたSony Tablet P のように画面を内側に折りたたむデザインでしょう。だって画面が傷つきませんしね。
しかし、Medias Wは内側ではなく外側になるように折りたたむデザインになっています。
これはかなり変態。画面傷つくじゃん。手脂でベタベタじゃん。
でも、このデザイン、普段使いを考えると結構理にかなってるんです。
折りたたんだ状態でも画面が外に出ているので、開くことなくスマホをいじれます。
また、閉じた状態だと画面の片方は自動で電源が切れて、もう片方だけが表示されます。これが結構良い感じで、画面が半分になることで電池の消費が抑えられるのです。
このデザインで一番気になるのは、画面が傷つくこと、です。
さすがにメーカーもその辺は認識しているらしく、ちょっとした工夫がされています。
画面の上下にある濃いグレーの部分が画面より少しだけ厚くなっているようで、スマホを机などに置いたとしても画面が直に机に触れないようになっています。
ただ単に変態なだけでなく、欠点を補うための工夫がされているのはいいですね。
また、それだけだと安心できないからか画面保護シートも最初から付属しています。
こういう配慮もいいですね。
中身(UI)-見た目に反して素に近い
Galaxy系は見た目こそ普通ですが、中身はゴテゴテにカスタマイズされていてなんかヤナ感じだったのですが、Medias W は見た目は変態ですが、中身は結構素に近いものでした。個人的には好印象です。
さすがに2画面のための特殊な設定項目は存在するものの、それ以外は素な感じ。
2画面モード
2画面モードには画面を完全に開くことで自動的に変更されます。
このとき、2つ目の画面をどう使うかで2つの状態が選べます。
2つの画面を1つの画面として扱う「フルスクリーンモード」
それぞれの画面で別々のアプリを起動する「ダブルモード」
これらの詳しい情報はニュースサイトのレビューが説明していると思うので省略。
1画面モード2画面モード行ったり来たり
面白いことに1画面モードから2画面モードへの移行、またはその逆、は思いのほか正常に動作しています。
たいていのアプリではエラーが発生せずに動いてくれます(ゲームとかはさすがに無理)。
普段使っているアプリでダメだったのは、Kindle。
1画面モードから2画面モードにするとクラッシュしてしまいました。
また、画面を開くとアプリによっては勝手に画面を回転するものもあります。
おそらくアプリ内で画面の縦横判定をしているものと思われます。
Medias Wは画面を開くと、縦よりも横のほうが長くなるので、このようなことが起こっているようです。
そのほうが何かと都合が良いので私は気にしてません。
総評-後悔なんてない。むしろなぜもっと早く買わなかった。
このスマホ、結構名機だと思います。
作りは特殊で使う人を選びそうな作りをしてそうですが、中身は堅実な作りになっていてAndroidを使ったことのある人なら戸惑うことなく利用できるようになっている点はすごく良い。
2画面モード時の機能もたのしいし、実用的。
フルスクリーンモードなら本を読むときに便利だし、ダブルモードならGoogleマップを表示しながらWebで検索もできる。
2つの画面をフル活用できる点はすごく嬉しい。
そういえば電池の持ちやレスポンスについて何も書いていませんでした。
書き忘れてしまうほどに問題ないのです。
つまり他のスマホと全く差がない。
もしかしたら同じスペックのスマホよりレスポンスは良いかも、と思ってしまうほど。
閉じた状態なら普通のスマホ。
開いたときだけこいつだけが持つ力を発揮してくれます。
ゆえに変態であることを意識せずに使えていいのだと思います。
Androidは HT-03A から使っていますが、それとMedias Wは忘れられないスマホになりそうな気がしています。
pebble Kickstarter Edition
届いてからもう3週間ほどたってしまっているのですが、pebbl についてレビューしようかと。
pebbleの箱。この状態で運ばれてきました。
腕につけてみたところ。
バックライトなしでも視認性は高いです。
そもそもpebbleって?
pebble とは最近騒がれているスマートウォッチに類するガジェットです。
スマートウォッチはAppleが作っているらしい、Googleがー、Microsoftがーと話題になっていました。
そんなスマートウォッチの先駆け的な存在です。
何ができるの?
スマートウォッチというくらいですから基本的に時計です。
当たり前だけど基本って大事。Sony から MN2 っていうスマートウォッチが出ていたのですが、今考えるとあちらは時計という機能がだいぶ蔑ろにされていて使いづらかったです。
それから盤面がカスタマイズできます。
今は有志によって開発されていて様々な盤面を手に入れることができます。
以下がそのサイト。pebble と接続したスマートフォンからアクセスすることで盤面がインストール出来ます。
Pebble Watchapp Directory - Pebble Forums
私のお気に入りはどーもくんの盤面。時間が変わるごとに口をパクパクするのが良い感じ。
Watch Face: Noms - Pebble Forums
他にできることはと言うと、メールの受信と電話の着信通知。
さらに簡単なアプリケーションをインストールできるので、いろんなことができます。
pebble VS MN2
他のスマートウォッチとの比較ということで私が持っているMN2と比較してみようと思います。
時計としての役割
pebble >>> MN2
これはpebbleの圧勝です。
MN2 は単体で動くことができず、常にスマートフォンと接続している必要があります。接続が断たれると時計の表示はなんとかできますが、一度電源を切ると時計すら表示出来ません。
さらに言えば、画面が普通の液晶のため点きっぱなしだと電池を消耗してしまうため、画面はすぐに消えてしまい、時間を確認するために、電源ボタンを押すか、振らなければなりません。
それに比べpebbleは初回起動時にスマートフォンと接続すれば、接続を断とうが電源を切ろうがちゃんと時計を表示してくれます。
盤面は電子ペーパーを利用しているため、常に表示されているという点も良いです。
視認性
pebble > MN2
pebble の盤面は常に表示されていて、見る角度によって見えないということもありません。
MN2 の画面は基本的に消えており、自分で付けないといけません。視認性とは違うかもしれませんが、この点はマイナス。つければその視認性は液晶と同じなので問題有りません。
カスタマイズ(アプリ編)
MN2 > pebble
これに関してはMN2が勝ります。
なぜかというと、MN2は時計と言うよりはスマートフォンの第二画面として機能するため、スマートフォンが許す限りの機能を提供できるからです。
ただし、やはりスマートフォンとセットが絶対な点がマイナス。それ故に強力であることは確かですが、単体で使えないのはどうかと。
pebble は MN2 とことなり時計自体にアプリをインストールすることが可能です。
そのため、機能はだいぶ劣りますし、インストールできるアプリの数もかなり少ないです。
が、pebble 単体でアプリを動かすことができる点は個人的には高評価。
操作性
pebble > MN2
僅差でpebbleかな。
正直、人によって好みがわかれるかと。
pebble には、決定、戻る、選択ボタン1・2の4つのボタンがついており、それですべての操作を行うことができます。
ボタンなので操作がわかりやすい点が良いですね。ただボタンが硬い。
対してMN2は近代的なタッチパネル。アプリによってはタッチパネルを生かしたものも。しかし、画面が小さいことが災いして操作性が良くないのが難点。
バッテリーの持続時間
pebble == MN2
これに関してはほぼ互角。
両方共激しく使わなければ1週間は持ちます。
防水性能
pebble >> MN2
pebble は5気圧防水なのに対して MN2 は防滴対応なので比べようがありません。
ただ pebble も5気圧防水なので水に潜ったりとかはダメで、シャワーとか洗い物で水がかかるのが大丈夫な程度。つまり日常生活で水がかかるくらいなら問題ありません。
ベルトの交換
MN2 > pebble
MN2の勝ちでしょうか。
MN2は時計と言いながら、本体はクリップ形式なのでいろんなところに付けることができます。さらに時計用のシリコンベルト、市販のベルトを取り付けられる台座が標準で付いてる点も良い点。
pebble は本体にベルトが付いているため交換できないみたいなのでこれに関してはどうしようもない。
と、思いきや交換されているかたがフォーラムにいました。どこで見たかは忘れましたが。もしかしたら市販のベルトと交換できるのかもしれません。
総評
pebble >> MN2
私的には pebble の圧勝です。
pebble が一番評価できる点は、単体で機能する点。それ故に使い勝手が良く、それなのに電池も持つ、基本である時計としての役割を果たしている。MN2に勝てるわけがないのです。
おわりに
pebble いかがだったでしょうか?
pebble はスマートな機能と時計としての機能のバランスが絶妙だと、私は思っています。
腕につけて使う以上、人間が操作できることに限りがあるのでスマートフォンからの通知と遊び心。この2つが大事なんじゃないかなと。
今のところ Kickstarter で投資した人しか手に入れることができないガジェットなので、この記事を見てすぐ買うことはできませんが、将来発売された時の参考にしていただけたら幸いです。
今回はMN2をかなりけなしていますが、アレはあれで割り切った設計になっているおかげで遊べるものになっているので悪いものではありません。
しかし、あれは時計ではありません。第二画面なのです。
その点だけ評価すればいいものなのですけどね。
Kindle paperwhite 自炊実験-小説の圧縮形式と品質の評価
最近Kindle paperwhite を買いました。結構今更感が強いのですが。
しかし、これには理由があります。
まだ日本でKindleが発売される1年以上前、今で言うKindle keyboardを購入していたのです。
なので購入しない予定だったのですが、年末のAmazonでのCyber Mondayでスキャナを購入し、その後裁断機を購入してから自炊した本をAmazon経由でKindleで受け取ろうと思ったのですが、いろいろ問題&面倒だと思って購入した次第です。
問題&面倒というのは以前購入していたKindle keyboardが米Amazonから日Amazonに移行することが出来ず、Androidで利用している日Amazonのアカウントと同期が取れず、そのままだと米と日のAmazonを併用しなければならなかったのです。
個人的にはひとつの米と日のどちらかで統一したかったのですが、ハードウェアの制約でそれは無理でした。やろうと思えばそのまま2つのアカウントを併用することもできるのですが、さすがに面倒なので「ま、ライトもついて小さくなるしいっか」と思って結果的に購入に至りました。
基本的には自炊以外で使う予定はないので、スキャンした画像をKindleで表示する上で圧縮率がどのように容量とその表示に影響するのか調べてみようと思い、以下の実験を行いました。
- JPEG圧縮による文字列への影響はどんな感じになる?
- 実際にKindle paperwhiteで表示したらどうなる?
JPEG圧縮による文字列への影響はどんな感じになる?
だいたいKindle whitepaper の解像度に合わせて異なる品質でJPEGで圧縮した後、一部を切り抜いた画像です。
ここでは文字列のスキャン結果を利用してその比較をしてみます。
利用した画像処理ソフトはフリーでお馴染みのGIMP。
品質は 1~20の間で設定して実験しています。
品質 1
品質 3
品質 5
品質 10
品質 15
品質 20
上の画像を見る限りだと1~10でJPEG特有のもやもやが目立ちますね。
そりゃそうですよね。1~10はかなりの圧縮率になりますから、もとの画像に無駄なものが入ったり、抜けたりしてしまいます。
実際にKindle paperwhiteで表示したらどうなる?
Kindleにも入れて実際のところを確認してみましょう。
Kindleに入れるにあたっては、ChainLP というフリーソフトを利用しています。
No.722: ChainLP
上記のURLで公開されています。
高機能で使いやすくもあり、これだけのものをフリーで公開してくださっている作者さんには感謝です。
気づいている方もいると思いますが、使っているソフトが違うので上の結果がそのまま反映されていません。(出来れば、ChainLP→画像抜き出しでやりたかったんですけど、やり方が分からなくて・・・というか面倒で・・・とりあえずということで。)
では、以下が比較です。
JPEGに加えてPNGでも圧縮しています。画像はKindleで表示したものをデジカメで撮影したものを一部編集したものです。
また、カッコ内の値は1冊450ページの小説を各設定でmobi形式で電子書籍化した時の容量です。
JPEG 品質 1(17.5MB)
JPEG 品質 3(17.5MB)
JPEG 品質 5(22.9MB)
JPEG 品質 10(32.6MB)
JPEG 品質 15(40.2MB)
JPEG 品質 20(46.6MB)
PNG 色深度 1bit(22.6MB)
PNG 色深度 2bit(38.2MB)
PNG 色深度 3bit(55.5MB)
PNG 色深度 4bit(67.7MB)
色深度は8bit(0-255)まであるのですがKindleが16階調しか表現出来ないので4bitまでしか作成していません。
試して見た限りだと文字列についてはPNGの1bitが、見やすさと圧縮率の一番バランスが良かったように思います。
同じ圧縮率であるJPEG 品質 5では若干見にくいところがありますし、同じくらいの見やすさとなると容量が大きくなってしまいます。
小説のような文字中心のものを表示するだけならグレースケールではなく、モノクロで十分ということでしょう。
今回は以上になります。
暇があればマンガでもためしてみたいですね。
CMake + Cutter で簡単にテスト&ビルド。
仕事でプログラムを書いているわけですが、Makefileはベタ書き、テストはまともに書いていませんでした。
で、最近から書き始めたコードではさすがにそれはまずいだろう、今後の自分のためにならないだろうと思い、CMakeやCutterについて勉強しはじめました。
CMakeというのはMakefileやVisualStudioのソリューションを作ってくれるソフトウェア。役割としてはautotoolsとほぼ同じ。ただ根本的に違うこと一つあり、autotoolsは主にUnix系OS向けなのに対し、CMakeはクロスプラットフォームでUnix、Windowsなどは問わないのです。
有名なところだと画像処理ライブラリであるOpenCVで利用されています。OpenCVはCMakeの売りであるクロスプラットフォーム対応を最大限活用してUnix、Windows、さらにはiOS、Androidにも対応させています。
ただ、ここではそんな高度なことは全くするつもりなんてありませんし、そもそもできません・・・
ここではクロスプラットフォームなんて単語は無視してMakefileを簡単に生成するためだけに利用します。
次にCutter。これはテスティングフレームワークで同種のもので有名なところだとCUnit、CppUnitなどでしょうか。
Cutterの特色は簡単に書けること。テストプログラムでよくあるよくわからない呪文は無く、よくわからない手順もかなり簡略化されています。
さて、CMakeやCutterをなぜ使おうと思ったかというと、よく使われているツールより簡単そうだったから。ただそれだけ。
(だって今からMakefileの書き方とかautotoolsの使い方、CUnitのよくわからない呪文なんて覚えたくないし、楽できるならソッチのほうがいいじゃないですかー。楽できて同じ事ができるならそれでいいじゃないですかー。)
というわけで自分が忘れないためにもCMakeとCutterの使い方についてまとめていこうかと思います。
ブログを書く手間を省くため、ここではCMakeの書き方とビルド、Cutterの実行だけ説明しようと思います。
Cutterの書き方についてはまた後日、気が向けば。
ではCMakeの書き方について。
参考にさせていただいたのは以下の二つのサイト。
よくわからない現代魔法 cmakeの使い方メモ
CMakeを使って自作ライブラリをビルド&インストールしてみたまとめ - へぼいいいわけ
利用したプログラムのソースはCutterのチュートリアルから拝借。
cutterのソースプログラムのsample/stack以下のファイルを利用し、autotools用のファイルを無くしてCMakeのファイルに置き換えています。
CMakeを使うにはCMakeLists.txtというファイルを作ります。
ディレクトリ・ファイル構成は以下とします。
cmake_cutter |-- CMakeLists.txt |-- src | |-- CMakeLists.txt | |-- stack.c | `-- stack.h `-- test |-- CMakeLists.txt `-- test-stack.c
トップディレクトリであるcmake_cutterにあるCMakeLists.txtは以下のように書きます。
# これはコメント cmake_minimum_required(VERSION 2.6) # このCMakeLists.txtを実行するのに必要なバージョンの下限 subdirs("${PROJECT_SOURCE_DIR}/src" "${PROJECT_SOURCE_DIR}/test") # 指定したディレクトリ以下のCMakeLists.txtを実行する。 # ちなみに PROJECT_SOURCE_DIR はCMake側で定義済みの変数。ここではcmake_cutterになる。
中身は最低限の記述だけ。
重要なのは実行に必要なバージョンの下限と、サブディレクトリの指定。説明はプログラムを参照。
次にsrc以下にあるCMakeLists.txt。
add_library(stack SHARED stack.c) # ビルドするライブラリの設定。 # 第一引数はライブラリ名、第二引数はビルドするライブラリのタイプ。第三引数はライブラリに含めるプログラムのソースファイル名。
これだけ。やっているのはライブラリのビルド設定のみ。
最後にtest以下のCMakeLists.txt。
include_directories(${PROJECT_SOURCE_DIR}/src /usr/include/cutter) # インクルードファイルのあるディレクトリ。 # stackプログラムのあるsrcとcutterのインクルードディレクトリがある/usr/include/cutterを指定している。 link_directories(${PROJECT_BINARY_DIR}/src) # リンクに必要なファイルのあるディレクトリの設定。 # PROJECT_BINARY_DIR はビルド時に利用するディレクトリ。あとで作成するbuildディレクトリがそれになる。 add_library(test_stack SHARED test-stack.c) # ライブラリのビルド設定。 # cutterはテストの実行にシェアードライブラリを利用する。 target_link_libraries(test_stack stack) # リンク設定 # test-stack.c で利用しているstackプログラムをリンクするように設定している。 # リンクする対象であるtest_stackが定義されてからtarget_link_librariesを実行する必要があるので、add_libraryの後に書かれている。前に書くとエラーになる。
こちらでは少し細かな設定をしている。
srcディレクトリではコンパイルのみで標準のライブラリ以外使っていなかったので、add_libraryによるライブラリのビルド設定だけでしたが、testではビルドされたstackライブラリのインクルードとリンクの設定、cutterライブラリのインクルードの設定が必要です。なのでinclude_directoriesとlink_directoriesを使ってディレクトリを指定しています。
また、リンクについてはリンクするライブラリも指定する必要があるので、target_link_librariesでライブラリを指定しています。
これでCMakeの設定は完了。
Cutterのチュートリアルを読むと分かるのですが、autotoolsの設定は異様に長くて意味不明、Makefileの記法まで覚えなければならないので大変です。
それに比べてCMakeは上記のようにCMakeLists.txtを書くだけなのですごく簡単です。
それではCMakeを実行しましょう。
CMakeを実行するにはcmake_cutterへのパスを指定する必要があります。
$ cmake <cmake_cutterへのパス>
これはソースファイル群を含んだディレクトリとビルドファイルを分離できるようにして、メンテナンスなどをしやすくしているものと思われます。
なので、ビルドに利用するディレクトリを作成してCMakeします。
cmake_cutter |-- CMakeLists.txt |-- build #<=これを作成 |-- src | |-- CMakeLists.txt | |-- stack.c | `-- stack.h `-- test |-- CMakeLists.txt `-- test-stack.c
buildディレクトリ下に移動し、以下を実行します。
$ cmake .. #親ディレクトリなので相対パスで指定 -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/kyokushin/programing/cmake_cutter/build
これでMakefileが作成されました。
あとはmakeコマンドを実行するだけ。
$ make Scanning dependencies of target stack [ 50%] Building C object src/CMakeFiles/stack.dir/stack.c.o Linking C shared library libstack.so [ 50%] Built target stack Scanning dependencies of target test_stack [100%] Building C object test/CMakeFiles/test_stack.dir/test-stack.c.o Linking C shared library libtest_stack.so [100%] Built target test_stack
これでビルド完了。
build/src以下にlibstack.so、build/lib如何にlibtest_stack.soが作成されているはずです。
あとはテストを実行するだけ。
Cutterではテストの実行にcutterコマンドを利用します。
cutterコマンドの引数にはテスト用プログラムのシェアードライブラリが含まれたディレクトリを指定します。
ここではbuild/testになります。
$ cutter test/ ... Finished in 0.006037 seconds (total: 0.001482 seconds) 3 test(s), 15 assertion(s), 0 failure(s), 0 error(s), 0 pending(s), 0 omission(s), 0 notification(s) 100% passed
Cutterのソースファイルに含まれているstackプログラムは完成済みなのですべてのテストに通過するはずです。
これでCMakeの書き方からビルド、Cutterの実行までが終わりました。
ここで言いたいことは、
CMakeってAutotoolsより簡単でしょ?
ってこと。
Autotoolsを使おうとするとまずはMakefileの記法について熟知している必要がありますし、さらにAutotoolsの動作についても知る必要があります。
しかし、CMakeではMakefileを作ってくれるのでMakefileについて知らなくても利用することが出来ます(もちろん知っていることに越したことはないです)。
さらに記述する量も少なくて済むので経済的です。
ただ問題は情報が少ないこと。英語の情報は比較的あるのですが、日本語の情報はまだまだで本格的に使っているところも無いみたいなので、細かな使い方が未だに分かっていない状況です。
GoPro Hero 3 Black Edition - 準備+オプションその他編
前回の続きで GoPro Hero 3 Black Edition。今回は準備編ということで、実際に使うまでの準備と別途購入したオプションその他について載せようかと思います。
まずはカメラを防水ケースから取り出します。
カメラの上にある白い三角形の部分をスライドさせながらレンズのある方を上に上げると蓋が開きます。
こんな感じ。
これが出した状態。すっきりしました。
正面には電源兼モード選択ボタンと液晶、レンズ、ボタンの右に2つのランプがあります。上のランプはWifiの状態を、下のランプは撮影状態などを表すために光ります。
上から。シャッター兼決定ボタン。その左下にあるのは撮影状態を表すランプで正面にあったものと同じです。底面と後ろにも同様のものがあります。色々な使い方があるのでどこからでも撮影状態が確認出来るようにするためなんでしょうね。
右から。上の方にある3つ穴は恐らくマイク、その下の1つ穴はスピーカーでボタン操作時に結構な音で鳴ります。おそらく防水ケースにいれていても聞こえるようにするためでしょう。音量調節は可能です。
その下にあるボタンはWifiボタン。Wi-fi Remoteの設定がしてあると、このボタンを押すことでWifiがonになり、Wi-fi Remoteとつながります。もう一度押すとoffになるかと思いきや、Wifiの設定に移動します。
左にあるくぼみはオプションであるバッテリーパックやLCDパックを取り付けるためにあるみたいです(バッテリーパックとLCDパックは注文済みで1/10に届くのでその時に)。
左から。同じく恐らく3つ穴のマイク。その下に蓋があり・・・
開けるとインターフェースが出てきます。micro HDMI と mini USB、micro SDXC スロット。micro SDXC にはカードが入った状態です。
こんな感じで刺さってます。
裏の蓋を外した状態とバッテリー。バッテリーは本体の半分近くを占めています。
並べてみました。見た感じ1/3の容積を占めてる感じですかね。
次に付属のWi-fi Remote。ボタンと液晶はカメラと全く同じ機能です。
上の写真でWi-fi Remoteの右からでてる金属部分は外すことができます。
外すと下のようになり、写真右に映っている専用充電ケーブルが刺さります。
この写真ではWi-fi Remoteに腕時計用のリストバンドを付けて腕に取り付けられるようにしています。
さて、その他のオプションなど。
まずは正規オプションである三脚用のアタッチメント。
防水ケースに取り付けて利用します。
撮影した動画を保存するためのSDXCカード。SANDISK フラッシュカード SDSDQUA-064G-U46A
今のところ問題なく動作中。
さらに手持ち三脚。ポラロイド の Polaroid ピストルグリップ テーブルトップ ミニ三脚 (小型カメラ, カムコーダー用)
足をたたむとグリップに。
手に持つとこんな感じ。
三脚用アタッチメントと一緒に使うとこんな感じ。
値段の割にしっかりしていていい感じです。
もう一つ自転車のハンドルに取り付けるようにクランプ式の雲台も。
写真は撮ってないのですが、試しに自転車に取り付けてみたら揺れる揺れるでどうしょもなかったです・・・ただ揺れる原因がクランプに直結している回転部分で、ここがバネ式の固定になっていたからでした。ネジを外して軸を少し削って再びネジでがっちり締めなおしたらなんとか使えそうな感じになりました。
と、今回は以上です。
カメラの外観とリモコン、オプションその他の説明でした。
オプションその他は先に挙げたバッテリーパック以外にもいくつか購入したので、次回にでも紹介しようと思っています。
ではでは。
GoPro HERO 3 Black Edition 開封の儀
12月頭に日本でようやく発売されたアクションカメラのニューバージョン、GoPro HERO 3 Black Edition がやっと家に届きました。
発売日当日に新宿ヨドバシカメラに行ってみたのですが予約分で売り切れ、次回入荷分の予約待ち。
ならばとネットショップの方で予約して約1ヶ月ほど待ってようやく届いたのです。
とりあえず開封の儀ということで写真など。
(今になって見てみると色々撮り忘れが・・・)
配達用の箱から出した状態。袋に入っていました。
袋から出して右側面。カメラのスペックが書かれています。
スペック部分を拡大。4K 撮影から240FPS撮影まで出来るとんでも仕様。
ただよくよく見てみると普通に使うのにちょうどいい設定がないんですよね。720pで30FPSとかリーズナブルな感じなのとか。
左側面の説明書き。内容物が書かれています。
Wifiリモコンとアタッチメントがいくつか入っています(最後に内容物一覧の写真を載せています)。
後ろから。
カメラとリモコンの機能説明。
少し詳しいスペック。
説明が書かれていた部分は別の箱になっていました。
カメラが入っている部分のプラスチックはテープで止まっているだけで簡単に外れました。
よくよく考えてみるとこの箱って魅せるために結構お金かけてますよね。
Wi-fi Remote を取り外したところ。針金でギッチギチに縛ってあって外すのに苦労しました。
カメラの取り外し方。箱の蓋がカメラ固定のアタッチメントになっているんです。凝ってますよね。
カメラを取り外したところ。右のペンチはWi-fi Remote を取り外すときに仕方なく。。。
蓋を開けると説明書が。と思いきや、説明書はWebからPDFをダウンロードしろという説明書き。
箱の中にはさらに箱が入っており、アタッチメントなどが雑多に詰まっていました。
内容物一覧。
右上にあるのがカメラで防水カバーに入ったままになっています。
その左にあるのがWi-fi Remote。
さらにその左にあるのがカメラを固定するために使うアタッチメント。
Wi-fi Remote の前にある袋に入った黒いのはアタッチメントをハメる部分。平面用と曲面用が用意されていて、両面テープでヘルメットなどに貼り付ける仕様になっています。
その右にあるのはWi-fi Remote 用のキーリング。
左の方にある2つのケーブルのうち左がWi-fi Remote専用充電ケーブル、右がカメラとパソコンを繋ぐためのUSBケーブル。
中央あたりにある袋に入った四角いのはバッテリー。カメラ本体の容積の約2分の1を占める大きさ。
右の方にある紙っぺらは本当に紙っペラ。Webに説明書ありますよーくらいのことしか書かれていませんでした。
で、最後に一番下の方にあるのがステッカー。3枚入っていました(1枚は早速ノートPCに貼りました)。
と開封時に撮影した写真は以上です。
開けるだけなのに結構手間取りました・・・主にWi-fi Remoteの性で。
にしても海外製品のパッケージっておもしろいですね。パッケージ自体のデザインにも凝っていてかっこいい。製品の魅力をよく引き出しています。
カメラを有効活用するために正規オプションその他色々購入しているのですが、明日が仕事始めなので今日はここまで。