氷川女體神社 → 氷川神社と行ってみた。

氷川女體神社


東浦和から徒歩でいった。1時間ぐらい歩く。


だいたい見沼代用水西縁緑道を歩いていけば気持ちよく歩ける。元々見沼だったところは開発規制されているので、びっくりするほど田舎の風景が広がっている。

前に訪れたときは本殿改修中だったが今回は大丈夫だった。


祭祀遺跡というのがあってちょっと面白い。RPG に出てくるみたいな離れ小島みたいなものがある。

氷川神社



大宮駅から、先に本殿に御参りしてから参道を逆に歩き、さいたま新都心駅まで。

氷川神社、訪れたことがあったはずと思っていたけど、どうやら別の氷川神社だったみたいで、完全に初見だった。

大宮駅自体も下車するのは初めて (新幹線に乗るために行くことはある)。思ったより駅前が開発されてないんだなという印象。

思ったよりもかなり参拝客が多かった。大宮駅に近いことは近いが、微妙に歩く必要がある (明治神宮と原宿みたいな近さではない)


境内も広くて立派な神社だった。


氷川神社は参道が 2km と全国最長とのこと。ちゃんと参道を一の鳥居から歩くならさいたま新都心駅で降りないといけない。まぁ参道といっても車道が通っていたり住宅が隣接したりしていて、純粋に参道っぽい参道はかなり短い。

この参道入口はブラタモリの大宮編に出てきたので見たことある人は多そう。

ほか

氷川神社 (男体社) と氷川女體神社 (女体社) を直線で結んだ中間あたりに中山神社 (中氷川神社・氷王子社)というのがあって、これも行きたかったが今回は諦めた。

これら3つの神社は見沼というかつてさいたまにあった沼の辺に建っていたらしい。

もともと沼も含めて (今は分かれている) 3つの神社が本来1つの神社として広大な神域を持っていた説があるらしくて夢がある。

  1. トップ
  2. photo
  3. 氷川神社・氷川女體神社

libpuzzle の Perl binding である Image::Libpuzzle を使って関連画像を実装してみた。pHash や avgHash も試してみたけど、どれが良いかというとなんともいえない。

現像パラメータ違いみたいな写真同士のものはちゃんとスコアが高く出ている気がするが、それ以外の場合はいまいち似ているとは言えないような感じで、いまいちよくわからない。基本的に同一画像判定用な気がするので、あまり大きな期待はできなそう。

SQLite スキーマ

CREATE TABLE images (
	`id` INTEGER PRIMARY KEY,
	`uri` TEXT NOT NULL,
	`entry_id` INTEGER NOT NULL,
	`sig` BLOB NOT NULL
);
CREATE UNIQUE INDEX index_images_uri ON images (`uri`, `entry_id`);

CREATE TABLE ngram (
	image_id INTEGER NOT NULL,
	word BLOB NOT NULL,
	PRIMARY KEY (`image_id`, `word`)
) WITHOUT ROWID;
CREATE INDEX index_word_image_id ON ngram (`word`, `image_id`);

こういう感じのスキーマ。複数のエントリに同じURLを貼ると無駄になるけど滅多にないので気にしない。

実装

Service::SimilarImage にだいたいまとめて実装した。SQL 自体は php - Libpuzzle Indexing millions of pictures? - Stack Overflow に書いてあるのとほぼ同じ。

  1. トップ
  2. tech
  3. 関連画像を表示

redeveloped タグをつけてる写真は過去の写真を演出… | Thu, Jul 13. 2017 - 氾濫原 をやろうと思って、画像ハッシュ化方法である pHash (64bit) avgHash (64bit) を試してみたけど、ウーンって感じだった。まぁまぁうまくいっている気もするけど、全然似てない写真の距離が近いこともある。

理由として想像すると

  • pHash も avgHash も色情報を捨ててる
  • 64bit (8x8) だと足りない

なので、色を考慮したハッシュ化をしたい。チャンネルごとに pHash にするとかなのかなあ。8x8 のままで RGB 3chとると単純に192bitになる。

もうちょっとコントロール可能にするなら、YCbCr にして、それぞれハミング距離を求めつつ、チャンネルごとに係数をかける (どの程度色情報を考慮するか決定する) とか?

redeveloped タグをつけてる写真は過去の写真を演出を変えて再現像したものになってる。

なので、過去のエントリがあるならリンクを貼りたいなと思ったけど、日記のどこに貼ったかは全くわからないので難しい。しかも全て画像は Google Photos にある。

やるとしたら

  1. 一度日記内の画像を全てダウンロードして特徴量検出とインデックス化をする
  2. 日記保存時にも同様のことしつつ、類似画像を検索する

みたいになるのかなあ。「類似」といっても、現像パラメータの違いだけなので、ほとんど全く同じなんだよなあ。

実際に値をセットしてみて、そのキーの容量を求めることができるコマンドがある。

https://github.com/sripathikrishnan/redis-rdb-tools

  • redis-memory-for-key [key]

このコマンドは DUMP key コマンドを発行した結果を再度 Python でパースしながら消費容量を計算している。割と面倒くさいことをして正確に出そうとしてる。

参考:ダメな方法

DUMP してサイズを見る

DUMP key して出てくる文字列のサイズを単純に見ると、これはファイルに書き出すときの形式になっており、文字列が LZF で圧縮されていたりする。

ついでにいうとキーや期限などのオーバーヘッドの容量が含まれない。

DEBUG OBJECT key の serializedlength

DUMP された結果のサイズを表示しているようで、DUMP と同様に圧縮されたサイズがでるっぽい。

  1. トップ
  2. tech
  3. Redis のメモリ消費量を見積る

ハサミを使う本を買っていて、子どもが「はさみやりたい」と言ったタイミングでときどきやってるけど、なかなかうまくいかない。

といっても直線切りは結構うまくできている。連続して開いて進めて切るということもできるし、持ちかえてやりやすいようにするのもある程度はできる。

しかし本のほうがだんだん難しくなってきて、四角形を切り抜くために途中ではさみの方向転換をするとか、小さい円を切り抜くとかになるんだけど、方向転換がうまくできない。

方向転換をするためには

  • 方向転換する角まで切り口を見ながら正確に切りすすめる
  • ハサミを動かさずに紙を持ちかえて方向転換する

という作業が必要だけど、「角まで切り口を見ながら切る」ことができず、手前でやめてしまうことが多く、そのうえハサミを動かして無理な体勢で方向転換してしまう。


昨日は小さい丸を切り抜くやつだったが、これも難しい。大きい丸なら直線の連続でもそんなにおかしいことにはならないが、曲率が大きいと雑な直線の連続で近似するのが難しく

  • ハサミを固定し一定のスピードを閉じる
  • 紙を連続的に動かして切る方向をコントロールする

を同時にできないとうまくできない。つまり四角のときにばらばらでシーケンシャルでやっていたことを、丸の場合はパラレルにやる必要があって難易度が上がる。

「はさみを持つ手は動かさないで、こっちの手で動かすんだよ」と一緒にやってたら途中で「できない」といって泣き出してしまった。わるいことをした。ちょっとすすめて方向転換を繰替えすんだよと言ったほう (コンカレント版) が直線切りの延長でできるので良かったかもしれない。慣れてればはさみを閉じるのは無意識にできるので紙のコントロールに集中できるけど、子どもはそうじゃない。反省。

くもんのすくすくノート はじめてのきりえ - くもん出版(KUMON PUBLISHING)

くもん出版(KUMON PUBLISHING)

5.0 / 5.0

↑ これは終わった。最後の1ページだけ難しかった気がする。

くもんのすくすくノート やさしいきりえ - くもん出版(KUMON PUBLISHING)

くもん出版(KUMON PUBLISHING)

5.0 / 5.0

↑ 今やってるけど難しい。

くもんのすくすくノート はじめてのかみこうさく - くもん出版(KUMON PUBLISHING)

くもん出版(KUMON PUBLISHING)

5.0 / 5.0

↑ これは終わった。ほぼ直線だから簡単だった気がする。

非合理的思考の一覧

  • 仕事のメールボックスを開くとき、何か嫌なニュースがある気がして開けない (実際はそんなことは滅多にない)
  • 不定期で自分はみんなからバカにされていると感じる (バカバカしいと思いつつ、真実であるとも感じる。特に根拠はない)
  • コミュニケーション全般。何かイヤな思いをするのではないか、うまく意志疎通できないのではないかという根拠のない不安。相手のことを考えうる限り最悪な性格である場合を想定してしまう
  • 仕事の手順のうち、文書化されてない (ないしは複数の文書にまたがる) かなり手数の多い手順を実行する際「抜けを起こさずやる」ことができない気がして無性にやりたくなくなる (実際は多少抜けてても取り返しがつくことが多い)

異常なクセ、強迫行為に準ずるもの

  • 弁当がない日に駅までついてから家に確認に帰る (滅多にない)
  • はんだごてのスイッチを切り忘れてないかある程度時間が経過してから再度確認する(実際はオフ時限タイマーを追加で付けているし、消す習慣もあるので消し忘れたことはない)
  • 指のさきにささくれをつくる

去年も今年も年間テーマが健康なのだがうまい成果があがってない。よって何かしら方針が間違えている。

不安を解消しようとすると破滅する

OCD(強迫性障害)の治療の本を読んだところ、不安をなくそうと考えると余計に囚われるので一旦思考停止して別のことに注意を向けろ (不安を受け流せ) ということが書いてあって、これを自分では「不安を直接解消しようとしてはならない」と受けとめた。今までは不安は根本的に解消すべきだと思ってたのでひとつの発見に思えた。

現状の不安の大部分は仕事に起因しており、この原因を直接的に解消するなら仕事をやめればいいのだが、なかなか難しいというか破滅する。実際、やめることで発生する不安のほうが大きいので解決にならない (逆にやめることで発生する不安のほうが少ないならやめられる)。

ということで、受け流す方法が必要になるが、結局これは能動的に不安に対する思考停止をおこなえってことだ。以下の要領で不安を処理するルーチンを定めこれを行うルールとし、できる限り実践することで健康を目指す。

  1. Getting Things Done の要領で不安の一覧を非合理的なことも含めて全て書き出して頭から追い出し思考停止させる
  2. 書き出した一覧を検討しなおし、合理的で検討に値するものだけ検討していく
  3. 合理的に検討に値するもののうち、解決可能なものを順次解決する

たまにやってくるピンホールカメラ期 | photo - 氾濫原, Eマウント ピンホールカメラの広角化 | photo - 氾濫原 とやって、前回 T=0.05mm やもう少し小さい穴を試せなかったのでさらに追試です。画角は焦点距離で14mm相当です。

T=0.05mm のステンレスシムと、φ0.1 のエンドミルを手に入れたので φ0.175mmのピンホールをあけて撮影してみました。φ0.175mm というのは、ちゃんと加工できれいればって話なんですが、エンドミルが細すぎてどうしてもしなってしまうので、ちょっと小さめになっている気がします。

見ての通りで、厚さを減らしたにも関わらず周辺光量減光はあまり改善しませんでした。よくよく観察してみると、白色光源に向けたとき、画像周辺部分では青カブリするような挙動をするため、単純な周辺光量減光というよりは、光線角度が急すぎるせいでセンサー上のマイクロレンズで捉えられる範囲外になっているような気もします。

無理して14mmにするよりレンズキャップ全面位置 (25mm) ぐらいが丁度よさそうです。

他の作例



  1. トップ
  2. tech
  3. Eマウント ピンホールカメラの広角化 - 2
  1. トップ
  2. photo
  3. Eマウント ピンホールカメラの広角化 - 2