BeagleBone Black 用に。$54.88

BeagleBone Black では専用イメージを使えみたいなことが書いてあって不安だったけど、繋ぐだけで表示できたしタッチも動いてくれた。しかしタッチは感度か精度がいまいち。細かい操作のために抵抗皮膜式が良かったんだけど、静電容量式のしかなかった。タッチペンが反応しなくてこまってる。

Google Photos の ICC カラープロファイルの扱い | tech - 氾濫原 の続きです。前回のまとめとしては

  • Google Photos は基本的に sRGB に変換
  • s0 (オリジナル同等サイズ) のみ元々のカラープロファイルが保持される
  • 500px 未満の場合はカラープロファイルが削除される

でした。

ただしある程度時間が経つまではオリジナルのプロファイルの画像が配信されることがあることがわかりました。

検証の試行錯誤

今日追試してみたところ、前回わかったルールよりもうすこし複雑なようだぞという挙動にみえ、ついでにいうと法則性がわかりませんでした。

あらたなファイルをアップロードして検証

今日あらたにアップロードしたファイルで検証してみました。以下のようにして s0 の部分をかえています。

curl https://lh3.googleusercontent.com/-4gapCD_T4ag/WOT-_iAPFkI/AAAAAAAAu-I/KXcMpxSoEcMurTrZ3umFh8nfOfOV88knQCE0/s0/IMG_7343-16MP-2.jpg | exiftool -
  • s320 - なし
  • s480 - なし
  • s499 - なし
  • s500 - sRGB IEC61966-2-1 black scaled
  • s1024 - sRGB IEC61966-2-1 black scaled
  • s1280 - sRGB IEC61966-2-1 black scaled
  • s1919 - sRGB IEC61966-2-1 black scaled
  • s1920 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s1921 - sRGB IEC61966-2-1 black scaled
  • s2047 - sRGB IEC61966-2-1 black scaled
  • s2048 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s2049 - sRGB IEC61966-2-1 black scaled
  • s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)

前回のファイルを再度検証

一方、前回検証したときに使ったファイルを再度検証してみましたが、こちらは前回と変わりませんでした。

curl https://lh3.googleusercontent.com/-BDMfJtqE7Mw/WIlEQ29H7II/AAAAAAAAnw0/2ZUwqimJUcQUbiLomaBrvwcrAebJFSjWQCE0/s0/IMG_9415-16MP-AdobeRGB.jpg | exiftool -
curl https://lh3.googleusercontent.com/-pEtCDwM8HhQ/WIlEQ5CSwLI/AAAAAAAAnw8/rAyZIkuFVzEk3x68vRLPAkkevHUxEicJQCE0/s2048/IMG_9415-16MP-ProPhotoRGB.jpg | exiftool -
  • s320 - なし
  • s480 - なし
  • s499 - なし
  • s500 - sRGB IEC61966-2-1 black scaled
  • s1024 - sRGB IEC61966-2-1 black scaled
  • s1280 - sRGB IEC61966-2-1 black scaled
  • s1919 - sRGB IEC61966-2-1 black scaled
  • s1920 - sRGB IEC61966-2-1 black scaled
  • s1921 - sRGB IEC61966-2-1 black scaled
  • s2047 - sRGB IEC61966-2-1 black scaled
  • s2048 - sRGB IEC61966-2-1 black scaled
  • s2049 - sRGB IEC61966-2-1 black scaled
  • s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)

よくわからないので、前回と同じファイルをアップロードしなおしてみましたが変わらず。

同じ内容ですこし違うファイルを再アップロード

しかし s0 をダウンロードしたものを再度アップロードすると今度は以下のような結果に…

curl https://lh3.googleusercontent.com/-ykbJTkOQRME/WOUC9VszXHI/AAAAAAAAu-g/E5q6Ds_DJu06zrYiOK8J2FKNbmMjlU34ACE0/s2049/IMG_9415-16MP-AdobeRGB.jpg | exiftool -
  • s320 - なし
  • s480 - なし
  • s499 - なし
  • s500 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s1024 - sRGB IEC61966-2-1 black scaled
  • s1280 - sRGB IEC61966-2-1 black scaled
  • s1919 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s1920 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s1921 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s2047 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s2048 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s2049 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)
  • s0 - オリジナルのプロファイル (ただし EXIFやXMP などは削除)

なぜか s500 でオリジナルが適用されていたり、だいたいオリジナルが適用されるかと思いきや s1024 や s1280 では sRGB になったりと意味不明です。

落ち着く

あきらかに挙動に疑問があるので、一旦冷静になります。さすがに Google といえどファイル内容を見てプロファイルを埋め込むかどうかを判定しているわけではないだろうし、なぜこんなことに……

と少し時間が経過してから再度検証してみたところ、結局 s0 以外は全て sRGB になりました。つまり

  • 動的にリサイズする場合はプロファイルが保持される (s0 はリサイズしないのでそのまま)
  • リサイズ結果は sRGB となり静的にキャッシュされる

が真相のようでした。動的にリサイズする場合はプロファイル変換までやるとオーバーヘッドがあるためプロファイルを埋め込むみたいな戦略なんでしょうかね?

  1. トップ
  2. tech
  3. Google Photos の ICC カラープロファイルの扱いの続き

Material Design Lite のテキストフィールドの input 要素を Vue.js で扱うとき、普通に v-model で two way binding すると、ラベル位置が更新されなくて文字が重なってしまったりする。つまりこれは Vue.js側の更新処理がMDL側に適切に伝わっていないために起こる。

MDLのソースを軽く読んだ解決として、mdl-js-textfield クラスがついている親要素に v-mdl 属性を追加し、以下のようにカスタムディレクティブを定義すると解決する。あんまり美しくないがしかたない。

静的な要素だけなら upgradeElementは必須ではないが、動的になると必須になるためついでにやっている。

Vue.directive('mdl', {
	bind: function (el) {
		componentHandler.upgradeElement(el);
	},

	update: function (el, binding, vnode) {
		const textfield = el.MaterialTextfield;
		if (textfield) {
			Vue.nextTick(function () {
				textfield.checkDisabled();
				textfield.checkValidity();
				textfield.checkDirty();
				textfield.checkFocus();
			});
		}
	}
});
  1. トップ
  2. tech
  3. Material Design Lite のテキストフィールドと Vue.js の相性があんまりよくない

Sequel はドキュメント見ると SQL そのまま書くやりかたもとクエリビルダを介すやりかたも許されていると感じるので (別に他のライブラリでも可能だろうが)、導入負荷が低くてよさそうです。結構機能はもりだくさんありますが必要なければ使わないのも許されてる感じもよさそうです。

Sequel でのクエリ発行のしかたは sequel/querying.rdoc at master · jeremyevans/sequel · GitHub を読むとだいたい網羅できるが、特に自分に重要なところだけ別途メモしておく。

モデルを使っても使わなくても SQL クエリはそのまま発行できる。複雑な JOIN も安心。

モデルを使わない場合

SQL を発行して Hash として取得できる。

dastaset = DB["SELECT * FROM foo"]
dataset.all # 全インスタンス化

モデルを使う場合

任意の SQL を発行しつつあるモデルとしてインスタンス化したい場合

class Foo < Sequel::Model(:foo)
end

dataset = Foo.with_sql("SELECT * FROM foo")
dataset.all # 全インスタンス化

Sequel::Model(:foo) の :foo はテーブル名を渡す。何も渡さないとクラス名を複数形にしたものを探そうとする。が明示したほうが良いと思います。

どういうときにモデルを使うか

使いたいときに使う。単にクエリ投げたいだけならモデルはいらないし、特に JOIN がからむなら余計なことせず Hash で返ってくるのは気楽で良い。

機能的な面からいえば、DBからひいてきたインスタンスにメソッドを生やしたいというときはモデルを使ったほうが楽。既存の行を update したいときもモデルがあったほうが楽。

Sequel のモデルも若干マジカルで、DBコネクションがないとモデル定義できなかったりする。キモいけどテーブル情報を使ってアクセサを定義したりするっぽい。

  1. トップ
  2. tech
  3. Ruby Sequel で生 SQL をメインに使う

https://github.com/mqttjs/MQTT.js

  • ブラウザ (MQTT over WebSocket) でも node.js でもほぼ同じ使いかたができる
  • 自動でリコネクトしてくれる
  • API がモダン

Eclipse Paho の JS 版を一時期使っていたが、完全に乗り換えました。

MQTT over WebSocket の場合

ドキュメントの通りだけど以下のようにする。TLS なら wss にするだけ。

		const client = mqtt.connect("ws://" + location.hostname + ":" + (location.port || 80) + "/mqtt", {
			username: USER,
			password: PASS,
			reconnectPeriod: 500
		});
  1. トップ
  2. tech
  3. JavaScript で MQTT するなら MQTT.js が良い



最初のほう。

あんまりスクリーンショット撮ってなかった。

祠さん……

ライネルさん……

まじゲーム下手なので最初はヒノックスすら怯えてて、ライネルとか全く勝てなかったけど、片手剣のライネルなら安定して倒せるようになっておもしろくなった。よくできてるなあと思った。

ゲーム内のカメラを使わないと自録りができないんだけど、そうするとフルスクリーンで撮影できないのがもったいない。

カメラ向けると喋ってるNPCも目線くれるのおもしろい。

Sierra になる前はキーチェーンに勝手に登録されてうまいことやってくれてた気がするけど、うまいことやってくれなくなった。

機能が削除されたわけではなくてデフォルトで無効化されたらしい。

Host *
AddKeysToAgent yes
UseKeychain yes

を ~/.ssh/config に追記した

以下のような環境で日本語が化けるようになった。

  • macOS Sierra
  • リモートで screen を使っている
  • ssh host -t screen -r で復帰している

問題ないケース

  • Sierra にする前は問題なかった
  • ssh host して手動で screen -r

解決方法

どうやら ssh -t したとき、特定の環境変数がリモートに渡されなくなったみたいだった。以下のように ~/.ssh/config に追記した

SendEnv LANG

Sierra での man ssh から抜粋。複数書く場合はスペース区切りか SendEnv 自体を複数書けば良い。

Specifies what variables from the local environ(7) should be sent to the server. The server must also support it, and the server must be configured to accept these environment variables. Note that the TERM environment variable is always sent whenever a pseudo-terminal is requested as it is required by the protocol. Refer to AcceptEnv in sshd_config(5) for how to configure the server. Variables are specified by name, which may contain wildcard characters. Multiple environment variables may be separated by whitespace or spread across multiple SendEnv directives. The default is not to send any environment variables.

  1. トップ
  2. tech
  3. Sierra にしたらリモートの日本語が化けるようになった

子供の写真って面白くて、成長が早いので「去年と同じ写真」になることがない。よって可能な限り撮りまくっても飽きない。

そして子供に限らないけど人物を撮るとピントや画質に敏感になる。人間の認知機能が人物認識に寄っているせいだと思う。子供の写真を撮ってなかったらそこまで画質厨にならなかった可能性もある。

  1. トップ
  2. photo

Google Keep が使用に耐えないぐらい重かったり、挙動不審だったりする。

  • ブラウザ版で WebGL 停止の警告がでたりする
  • ブラウザ版で入力するときに入力が遅い
  • ブラウザ版でテキストをペーストすると \n\n が \n\n\n\n になる
  • Android 版で入力するとき、入力のたびに上部からカーソル位置までスクロールがかかる

Google Keep は特に入力まわりがとてもひどくて、これまで Input Method を使った入力ができなくなったり (普通に考えてIMを使ってるエンジニアやQAが1人でもいればこんなことは起きないと思う) したこともあった。

Google Keep で気に入ってる点は、Google アカウントで同期されて、特に何もしなくてもアプリケーションが入ってるところが大きい。アプリケーション自体の良さってわけでもない。

ということでもう他の何かに移行するか、自分用にメモアプリを作りたい。

Google Keep のデータエクスポート

Google Takeout で HTML 形式のメモリをすべてダウンロードできる https://takeout.google.com/settings/takeout/custom/keep

α7R II を買った。SONY の FE レンズは買わずに SIGMA MC-11 を一緒に買った。

動機

今まで使っていた 5D Mark II は2010年に買ってたので7年ぐらい使ってた。思ったより長い。そしてEOS 5D Mark II にはそれほど大きい不満があるというわけでもなく、一眼レフカメラとしてはもうこ以上買う気はそんなに起きないぐらいには満足してた。

しかしもはや一眼レフってのもなという状況になってきた。もしキヤノンがボディ内手ぶれ補正をつけたフルサイズミラーレスを出すなら買いたいけど、やっとAPS-Cサイズで本気出してきたぐらいで、これから数年経ってもでることがなさそう…… キヤノン的にはミラーがあってもミラーアップしてライブビューで撮れば同じようなもんやろと思っているかもしれない。

ひとこと

とりあえず本体の画質は文句なしに良い。ボタンの配置が微妙なのとダイヤルのクリック感がゴミみたいな感じなのとかは画質と相殺して我慢できるレベル。

画素数が多いので、高分解能のレンズだと今までよりさらにクリアになったと感じる。ローパスレスなせいか等倍にしてもピクセル間のコントラストが強い。ローパスフィルタの必要性はわかるが、今のところモアレがでるような被写体を撮ってないのでローパスレスでのデメリットは感じられてない。高分解能のレンズほどモアレがでやすいはずだけど、どのぐらいのランクのレンズから影響があるのかはわかってない。

ググればいくらでも高感度特性とか出てくるので主観的にいくつかインプレッションを書いておく。

ピクセル数

44Mピクセルになって、8K(33M) を超えた。8K を超える画素数は一つの目安だと思っている。8K ぐらいでようやくそれなりの大画面でも人間の認識能力に届くようなピクセル密度になってくる。

4K ディスプレイでかなり古いカメラの画像を見かえしていたりすると、ピクセル数が足りないだけで残念な気分になる。8K はもはや未来ではなく、数年後ぐらいのそう遠くないうちに8K未満の画像だと残念になることが予見できる。

ISO AUTO低速限界

手ぶれ補正を効果的に防ぐ安全策として強力に機能する。α7R II にはボディ内手ぶれ補正もあるけど、「より高速」に設定して2段分はやいシャッタースピードを設定するようにしてる。おかげでAvで撮影するときはほぼ完全にシャッタースピードを気にする必要がなくなり、いちいち手動でISO感度を変える必要がなくなった。

普通のISO AUTOだけだと、1/焦点距離でISO感度を上げようとするが、これだと遅すぎるので今までかなり不満で、ISO感度の切り替えを手動でやる頻度がかなりおおかった。α6000にもつけてほしい。

ボディ内手振れ補正

レンズ内補正がない単焦点で嬉しい。撮影時にファインダー像が安定するのは地味に効く。

レンズ

SIGMA MC-11 と手元のEFレンズを使ってる。

MC-11 は EF -> E のマウントコンバーター。SIGMA の最近の製品用のコンバーターだけど、EFマウントの他のレンズでも結構使える (SIGMAとしてのサポートはされてないけど、ファームウェアアップデートで考慮されるぐらいにはサポートされている)。手元にあるレンズはすべてAF 可能だった。ただしSIGMA の最近のレンズ以外だとできないことも多い。

MC-11 が存在していなければαを買うことはなかっただろう。

各レンズごとに挙動が違うので別にエントリを書く

SONY ミラーレス一眼 α7R II ボディ ILCE-7RM2 -

5.0 / 5.0

SIGMA マウントコンバーター MC-11 キヤノンEF-E用 キヤノン⇔ソニーEマウント -

5.0 / 5.0

  1. トップ
  2. photo
  3. SONY α7R II + SIGMA MC-11 を買った