OPPO R11s の優秀と言われるカメラ性能は本当に優秀なのか #撮らずにはいられない #OPPOカメラフォン #r11s

OPPO R11s の体験みたいのを申し込んだら当たったのでレビューしてみようと思います。 特徴的なのは「カメラ」だそうです。テスターの際に「#撮らずにはいられない」、「#OPPOカメラフォン」をつけてツイートしてねって言われているぐらいです。 ということで今回はカメラを重点的にレビューしたいと思います。   スペック OS種類 ColorOS 3.2(based on Android7.1) キャリア SIMフリー CPU Snapdragon 660 SDM660 CPUコア数 オクタコア 内蔵メモリ ROM 64GB RAM 4GB インターフェース microUSB 外部メモリ最大容量 256 GB バッテリー容量 3205 mAh(交換不可) 画面サイズ 6.01 インチ 画面解像度 2160×1080  パネル種類  AMOLED  無線LAN規格  802.11 a/b/g/n/ac  背面カメラ画素数  2000 万画素  前面カメラ画素数  2000 万画素  手ブレ補正  –  4K撮影対応  –  耐水・防水機能  –  おサイフケータイ/FeliCa  –  認証機能  指紋/顔認証  デュアルSIM  ○   デュアルSIMデュアルスタンバイ(DSDS)  –  幅x高さx厚み  75.5×155.1×7.1 mm  重量  153 g 値段 62,510円(2018/03/19)     開封~付属品 SIGMA sd Quattro H (30mm, f/2.8, 1/160 sec, ISO100) シンプルな外箱でかっこいい   SIGMA sd Quattro H (30mm, f/5.6, 1/50 sec, ISO100)紙2枚、SIMピン、透明ケース 製品版でも最初からケースが付属されています。   SIGMA sd Quattro H (30mm, f/5.6, 1/50 sec, ISO100)イヤホン、マイクロUSBケーブル、USB電源   液晶の発色が綺麗 SIGMA sd Quattro H (30mm, f/7.1, 1/30 sec, ISO100)OPPO R11s の液晶タイプが AMOLED…

買わない理由が分からないくらいコスパが最高で軽くて小さい、PENTAX K-70 をレビューしてみる 作例もあるよ

ちょうど半年前に SONY α7II から PENTAX K70 へと交換しました。 フルサイズを使っているときに、「別にこれフルサイズじゃなくても撮れる画像しか撮ってねえ」と思ったのがきっかけです。 PENTAX K-70 にした理由はコスパが良いなと思ったぐらい。 PENTAX のセンサーから出る画像も見ずにただただ K-70 を買いました。 買って大正解なボディでした。 最後に作例も載ってるので見てみてください。   スペック タイプ 一眼レフ 映像素子 APS-C 画素数 2424万画素 ファインダー形式  ペンタプリズム 手ブレ補正  4.5段 防塵・防滴 ○ 幅x高さx奥行き 125.5x93x74 mm 重量  628 g 価格 61,361円(2018/03/13)   メリット1:手ブレ補正 PENTAX K-70 はボディ内手ブレ補正が乗ってます。 オールドレンズと言われる昔の Kマウントレンズが使えたり、 m42 レンズでもボディ内手ブレ補正が発揮される。 Kマウントレンズだけじゃなくて、マウントアダプターを使えば m42 レンズが使えるのが素晴らしい。オールドレンズにはレンズ内手ブレ補正がないので僕が感じるメリットと言えばこの辺。   メリット2:防塵・防滴 この価格とこの重量で防塵・防滴! WR と書かれたレンズは簡易防滴のあるレンズです。 山とか登る人は PENTAX 一択ですね!   メリット3:サイズ、重量もコンパクト これだけの機能があって、コンパクトで軽い!   メリット4:Kマウントレンズに良いのが多い Kマウントレンズって、Eマウントと違って安いんですよ。 の割にいい写りをしてくれるレンズもたくさんあります。 スナップで使えそうな単焦点では HD PENTAX-DA 35mm F2.8 Macro Limited もうちょい行くと smc PENTAX-DA★ 55mm F1.4 SDM さらにもうちょい行くと smc PENTAX-D FA マクロ 100mm F2.8 WR 中でも FA Limited シリーズのレンズは 2002年発売にも関わらず未だに人気で FA 31mm F1.8 AL Limited となると10万超えます。   デメリット1:ない ない   作例 中でも DFA Macro 100mm 一番大好き 程よい解像度に、程よい柔らかさ。何でも撮れちゃうレンズです。人を撮るならこのレンズが良いと思った。人を撮って思ったけど自分にセンスはないと思ったので今後は動物、植物が増えると思う。 DA★ 55mm は安定した描写で人にも使える感じなのでオールマイティーな中望遠レンズとして最高です。

Goを使って画像の類似度を超簡単に行う / perceptual(image) hash

コンビニの有人レジがすごい混んでるのに、セルフレジを誰も使わない日本人を理解できない長谷川です。 概要 2つの画像の類似度を算出したい。 得られるハッシュ値は64bit 対象は静止画, 画像, 音声等のマルチメディアデータ コンテンツ内容が類似しているケースでハッシュを得た場合、例えば静止画画像の拡大、縮小といった加工の場合ハッシュ値が全く同じになる また、色調の修正やノイズが加わった場合も得られるハッシュ値間のハミング距離が近くなる 64bitのハッシュ値なので最も遠いハミング距離は64 (=全くコンテンツが異なっている) 逆にハミング距離が0であればperceptual hashで得られた結果上は同一コンテンツ こういった特徴があるため具体的にWebアプリケーションでの用途を考えると コンテンツの重複判定 類似画像検索 などに使えそうというのは上の特徴でわかるのではないでしょうか。 引用元:http://hideack.hatenablog.com/entry/2015/03/16/194336 計算方法もいくつか種類があります。 ・aHash:画像の平均輝度からの差分を使った方法 ・pHash:画像を離散コサイン変換(DCT)し周波数領域に変換後、低周波領域に対してaHashと同じ方法で算出する方法 ・dHash:隣接領域との差分を使った方法 ・wHash:pHashのDCTの代わりに離散ウェーブレット変換(DWT)を用いた方法 参考:http://tech.unifa-e.com/entry/2017/11/27/111546 ここでは aHash と dHash を使ってみようと思います。 使用したライブラリはこちら https://github.com/devedge/imagehash   実装 [crayon-5b4f015b4bc2f219463869/] imagehash.Ahash を imagehash.Dhash にするだけで aHash から dHash に切り替えることができます。   aHash と dHash の比較 こちらのサイトによると、dHash は aHash と同じ速度にも関わらず、精度が良好らしいです。 ちなみに2つの画像の distance(違う画像だと数値が大きい) を求めるには 2つの []byte をループさせて比較して値が違う場合に +1 すればいいだけです。 [crayon-5b4f015b4bc3e842689786/]   試した画像 laptop1.jpg laptop2.jpg iqos.jpg laptop1.jpg と laptop2.jpg は似たような画像(若干右にズレてます)、 iqos.jpg は全く違う画像を用いりました。   aHash 平均輝度の差分を使った超シンプルな方法 スマホで撮影した画像の場合、撮影時にタップした場所によって露出が変わるためスマホの画像を取り扱う場合には不適切なような気がする。 [crayon-5b4f015b4bc41277352519/]   dHash 隣接領域との差分を使った方法でシンプルで精度も、速度も良いらしい。 グレースケールに変換した後、9×8サイズに縮小する。 右隣のピクセルと値を比較して大きければ1 同じか小さければ0 0を黒、1を白に置換し、1pixelを1bitとして、16進数に変換することで値を取得できる。 aHash と違い、輝度ではなく実際にピクセルを見るので精度が良いと言われるのも分かる。 [crayon-5b4f015b4bc44583208298/] aHash と dHash の比較をしてみたけど精度にそこまでの差を見つけられなかった。 まあ今回用いた画像が悪かった。 distance だけを見ると、dHash の方が粒度が高いように見えるけど似たような画像と、アイコスと1枚目の差が 4 しかない。 しかし、aHash では差が 5 ある。 しかも1000回ループした結果では、aHash の方が16秒速い。 全く違う iqos.jpg でも真ん中にディスプレイがあり、dhash の手法だと白黒に変換したタイミングで同じような結果となってしまい、たまたま aHash と差が内容になってしまったと推測。 どちらを使うにしても distance の閾値を適切に設定する必要性がありますね。 もっといろんな画像で試してどっちを使うか決めたいと思います。

AWS-SDK-Goを使って、ユーザーが投稿したファイルをS3から削除してみる

はじめに S3でユーザーが投稿した画像を管理している場合、ユーザーがアプリを退会した際にユーザーに関する情報、S3からもユーザーのファイルを削除する必要性があります。 S3上のプレフィックスは userID/ となっており、全体のキーはbucket/userID/fileName.jpg となっています。   問題点 AWSの制約上、bucket/userID以下にファイルが1つでもあると、 いきなりbucket/userIDを削除することはできません。 加えて、リストを取得するListObjectsでは1度に1000個のキーか取得することができず、 オブジェクトの削除を行うDeleteObjectも1度に1000個のキーまでしか指定できません。 もしユーザーが1000個以上のファイルをアップロードしている場合、 一筋縄ではいかないため工夫する必要性があります。   コード   解説 ユーザーが投稿したファイルを全て取得する [crayon-5b4f015b4c07c563153875/] 最初のリクエストをする際に、Delimiter: aws.String(userID + "/"),をつけてリクエストをすることで、レスポンスにIsTruncatedが含まれています。 IsTruncatedがtrueだと全てを取得できず、まだ残りのオブジェクトがある状態 falseだと全てのオブジェクトを取得できた意味をします   [crayon-5b4f015b4c087845671549/] 最初のリクエストでIsTruncatedがtrueの場合、 NextMarkerがレスポンスに含まれているのでこれを次のリクエストに含めておきます。 ループの中でこれらを繰り返しておき、 IsTruncatedがfalseになった時点で終了。この関数では[]stringを返します。   オブジェクトを削除する [crayon-5b4f015b4c08d667237953/] 関数全体↑   [crayon-5b4f015b4c091039074035/] getAllObjectで取得したキーが入った配列の長さが1000以上だった場合、 先程述べた様に、1度のリクエストで削除できるキーが最大1000のため配列を分割する必要性があります。   [crayon-5b4f015b4c094714190061/] func chunk()では1000要素以上の配列に入ったキーから1つの配列が1000個未満のキーとなるように複数の配列に分割して[][]stringを返します。   [crayon-5b4f015b4c098579505331/] この分割された[][]stringをfor-rangeでループさせ、画像を削除していきます。   [crayon-5b4f015b4c09c958113555/] bucket/userID 以下のファイルが0になったら、bucket/userIDを削除します   使い方 ちなみに画像数が5,000枚レベルになると、マシンのスペックにもよりますがAPIサーバーからアプリへレスポンスを返すまでに1分程度、かかってしまいとても使えたものではありません。 なので、今回はDBからユーザーの情報を削除する部分はGoroutineで制御し、 このS3から画像を削除する部分はレスポンスを返した後に実行されるようにしてみました。 [crayon-5b4f015b4c09e314731023/] DBからユーザー情報を削除する部分はerrgroup(goroutine)で制御を行って、 エラー処理ができるように。全ての処理が終わったあとに、   [crayon-5b4f015b4c0a0312831027/] WaitGroupをインクリメントしておき、wg.Wait()をせずにそのままreturn nilでレスポンスを返します。 ただ、これを行うとS3から画像を削除する部分でエラーを起こるとユーザーへ通知できなくなってしまうので、Slackへ通知するようにしてます。 (そして手作業で該当ユーザーのファイルを削除していく…)   おわり Go言語に自信が全く無い素人のコードを晒して大変恐縮していますが もし間違いや、こうした方がいいのご指摘がありましたらぜひコメントしていただけると本当に幸いです。

[WIP]Locustで初心者がAPIサーバーの負荷試験をやってみた

この記事はチラ裏です。僕の頭の中を整理するためだけの記事です。 寒いなぁ…寒いなあ… 卒論を提出して2/6にはパワポとレジュメを作成して発表です。   負荷をかけるツールはいっぱいある 便利な世の中なので負荷ツール(Load test tool)はたくさんあります。 ここでどれを使うかを選定しないといけないわけですがいくつか候補を挙げてみたいと思います。 JMeter(有名、高機能、リクエストがいっぱい出せる、知見多) ab(シンプル、知見多、手軽) httpperf(手軽、リクエストがいっぱい出せる) vegeta(リクエストがいっぱい出せる) hey(手軽) siege(使ったことない) goad(Lambdaから負荷をかけれる、色んなリージョンからアクセスできる、JSONのPOSTのやり方分からず、手軽) Locust(分散して負荷をかけれる、Web GUIがある) 分散しないで負荷をかける vegeta や hey では家のネットワークとか、1台のマシンだけじゃサーバー側のリソースを使い切ってくれないため除外。 JMeterは設定がダルい、勉強するのは少し面倒。 Locust は Qiita 等で取り上げられてるので知見は結構あります。 JMeter のようなシナリオを Python で書き、負荷をかけるサーバーも簡単に実行することができる。 ドキュメントもきちんと整備されているので今回は Locust を使ってみました。     Locust を使ってみる インストールも簡単です。 pip install locustio これだけです。 実行は locust -H host --master Slaveは locust -H host --slave --master-host=masterip Master は実際に負荷をかけず、集計や Web GUI を担当し、Slaveが実際の負荷を行います。 今回は c4.large のインスタンスを6つ建てて 1Master 6Slave で負荷をかけました。 画面が多いと負荷試験がやりやすい pic.twitter.com/QozJrFR3ag — るいす (@lu_iskun) 2018年1月29日 負荷試験中は、LB(Nginx), API, DBのリソース状況、各サーバーのログを表示しておき、 Nginx のコネクション数や、FD数などは Nginx Amplify を表示しておくと便利です。   今回は 10万ユーザーを作成し、秒間1万ユーザーずつ増加していく方法を取りました。   Charts には数値がグラフ化されています。 この図を見るだけで、RPSは最大3200、ユーザー数が増えるごとにレスポンスタイムが増えていっていることが分かります。   失敗したリクエストは Failures にまとめられています。 先程の図から推測すると、何らかの要因でレスポンスタイムがどんどん増えていき、サーバーがコネクションを切ってしまったんだと思います。     [crayon-5b4f015b4c326958641044/] ルーターのネットワークインターフェースを見てみると LB, API, DB が載ってるサーバーからのパケットで、いくつかドロップされてるパケットがあります。 CDN に Cloudflare を挟んでいるのですが原因は Cloudflare ではなく完全にこちら側ってことが分かります。     コンテナで動かしているAPIサーバーに16スレッドを割り当ててますがうまいこと全部のスレッドを使っているようです。Go はメモリが全然消費されなくてすごいですねぇ ここを見ている限り、平均70%のCPU負荷で %iowait もそこまで高くないため(そもそもディスクの読み書きがないようなAPI)、LBかDBのような感じもします。   LBは2段あって、3段目にAPIがあるわけですがこの画像には写って無くて申し訳ないですが(画像は最上段LB)、最上段LBは HTTP Error が発生していましたが、2段目のLBでは HTTP Error…

去年の振り返りと、今年の抱負 – 2018

明けました おめでとうございます。 今年はうまくいけば大学を卒業し、社会人となります。 2017年バージョン同様にブログのまとめ記事っぽくなります。 チラ裏です。 去年の振り返りと、今年の抱負   初めてのフルサイズ 初めてのフルサイズを買ってみた「SONY ILCE-7M2」 α65 から α7II へ一気にグレードアップしました。 フルサイズの良さが分かったので、APS-Cがどんなもんだったかを思い出すために今は PENTAX K-70 を使ってます。既にフルサイズ機が欲しいです。というか、ソニー機が欲しい。 K-70 も好きな描写なのですが、どうしてもソニーの無機質な冷たい描写が好きみたいです。 K-70 は一眼レフで、ミラーレス機のようにファインダー内が液晶で表示したときと一緒(ISOとか色々)に対して、K-70 はペンタプリズムファインダーなので、液晶で表示(実際に撮影されるイメージ)されるのと、ファインダー内の写りは全く異なる。 それでも、ファインダー内に露出計があるので今では慣れたのですがアレはアレで便利でした。   Ergodox EZ に手を出す 35,000円する最高のキーボードを買ってみた「ErgoDox EZ」 今でも使っています。 キーボードは東プレ、HHKB、LEOPOLD、リベルタッチと高級なものを使ってきたもののすぐ飽きてしまいましたがこのキーボードは今でも好きです。見栄えも良いし慣れると結構速く打てます。   コンテナの手軽さを知る コンテナ上で何もできなくなる「Too many open files.」 今でも仮想アプライアンスとして Proxmox を使ってますが2016年ぐらいまでは KVM を主に使ってました。毎回 ISO からインストールしていたのは手間でしたが LXC を使うようになってテンプレートを指定するだけで良いのは最高です。KVM と違ってオーバーヘッドも少ないのでホストマシンを圧迫することなく良いことづくし。   AWSの色んなサービスを使うようになった Lambda+S3+EC2を使用してできるだけ安くリアルタイムwebPエンコードをやってみる S3をCloudFrontから配信&LambdaとWAFを組み合わせて利便性とセキュリティを確保してみる 友人の会社を手伝うようになり、流石に自宅サーバーだけでやるのはアホすぎるので AWS を触るようになりました。2017年の抱負でも「AWSの色んなサービスを使う」があったので良い感じに実現はできました。 Redshift とか、Quichsight みたいなデータ解析寄りのサービスを触れることはありませんでした。   MBP 2017 13inc に買い替えた MacBook 2016 m7 から MacBook Pro 2017 2.3GHz に買い替えた Macbook m7 での不満は「ディスプレイが小さすぎた」という点だけ。 買ったのは13インチでそこまで大きな差はありませんが、家で MBP を使うようになってからは Type-C が2つになって良かったと思いました。 CPU のスペック差も正直そこまで感じられず m7 の凄さを知りました。   Ansible を良く書いた1年 AnsibleでコピーするときはSynchronizeモジュール使ったほうが幸せになれる 構成管理ツールって、Ansible だったり、Itamaeだったりありますが何で Ansible にしたのか思い出せない。 ベストプラクティス構成は悩みどころかと思いますが僕はこうなりました。 [crayon-5b4f015b4c482439817479/]   Node.js と Go に手を出した 2017年、まともに Javascript も書いたことないのに Node.js を書き、Go も書くようになりました ただ、Go は未だに慣れませんね。慣れていなくても簡素に書けて最高の言語です。   今年はもっと成長できるはずの年なので、頑張りたいと思います。 今年から社会人です。宜しくお願い致します。

Ankerの完全ワイヤレスイヤホンが結構良い「Anker Zolo Liberty」

久々にレビュー記事でも書こうと思います。 先日、25日に布袋寅泰の Paradox Live Tour in 横浜アリーナに行ってきました。 最新アルバムを聴いていなかったので電車の中で予習してから行こうと思い、年に数回しか使わない SENNHEISER IE80 を家の中で探すも見つからず。 TSUTAYA で 1,000円程度のイヤホンを買ったのですがせっかくならということで イヤホンを買ってみました。という話。   Anker Zolo Liberty SC-02J (4.25mm, f/1.7, 1/28 sec, ISO200)Amazonで 7,999円でした。今は在庫切れですけど。   SC-02J (4.25mm, f/1.7, 1/33 sec, ISO200)対応コーディックは AAC, SBC のみの対応となっており aptX には非対応です。 価格帯を考えれば仕方ないですね。音質重視で買う価格帯の Bluetooth イヤホンではないですが、音質の面でも aptX は優位なので聴ければいいって感じのスペックです。   SC-02J (4.25mm, f/1.7, 1/33 sec, ISO200)内容物 ・本体 ・ケース(バッテリー内蔵) ・イヤーチップとか色々セット ・紙 ・USBケーブル ケースは microUSB で給電するタイプですが、充電器自体は付属しません。PCからの電力でも充分です。   SC-02J (4.25mm, f/1.7, 1/20 sec, ISO250)充電方法は、載せるだけでイヤホンの LED が光るので分かりやすいです。 イヤホン本体が満充電、ケースも満充電で最大24時間の再生ができるらしいです。   SC-02J (4.25mm, f/1.7, 1/33 sec, ISO250)ケースは microUSB 充電です。コネクタが壊れるのが怖いのでマグネット式のものを挿し込んでます。   SC-02J (4.25mm, f/1.7, 1/25 sec, ISO200)充電するのもマグネットでカチッなので壊れる心配もなければ、でかけるときもケース本体を引っ張れば勝手に USBケーブルも外れるので大変便利です。   接続について ケースから取り出すと、ペアリング開始です。 特筆する点もありません。 再接続等はとても便利で、ケースからイヤホンを取り出すと勝手に Android とペアリングしてくれます。もちろん Android 側は常時 Bluetooth を ON にする必要性が有りますが。   音質 フラットに近いようで低音が少し持ち上げられてる感じがします。 高音域も出ないわけじゃなく、普通に出ますが低音域が強くてあんまり出てこれてないような。 篭ってる間は無いんですけどね。 音場もそこそこあって、定位もしっかりしてます。解像度は高くはありませんが 2,3万円台のヘッドホンや、イヤホンにあるような解像度が高いくせに音に纏まりがないような感じがなくて聴き疲れは無さそう。 結構好みの音で驚きです。僕はオーテクの音が好きなので、オーテクの音が好きな人は大体好きな音だと思います。 クラシックや、オーケストラ、声が高音域で綺麗なアーティストの曲には向いておらず、ロックやEDMとかが合うイヤホンだと思います。   音切れについて 外出中に使ってみましたが音切れも無くて良い。新宿とか行ってみたけど大丈夫だった。 その時、スマホはポケットに入れてました。   装着感 IE80 時代に色々とイヤーチップを試してきたんですけどバッチリ合うイヤーチップに辿り着けませんでしたが、何とこれにはビックリ。ジャストフィット…😊 付属されてるイヤーチップとか、よく分かんないのもあるのでお好みのを着けたら良いと思います。   マイクの音質について まあ音質は悪いです。 録音したものを…

Node.jsでjpgをwebPエンコードする

前回の記事の続きのような Lambda+S3+EC2を使用してできるだけ安くリアルタイムwebPエンコードをやってみる   node-cwebp を使う https://github.com/Intervox/node-webp cwebp のラッパーです。 cwebp は Google 公式のライブラリです。 使ってるコードをそのまま載せます。 対して長いコードではないので読むと分かりますが、パスに cwebp がなければディレクトリを直接見に行ってます。 前回の記事を見ていただければどれぐらい重い処理か分かってもらえると思います。