✖
✖
✖
✖
✖
仕事を中心にして考えてるのがそもそもの間違いだと思う。あたりまえだけど業務時間外は「自分の時間」であって、仕事のための勉強をする時間ではない。
前も書いたけど、趣味すなわち自分の時間で自分の意思によって主体的に行うことが一番重要なのであって、仕事はそれに付随しているものでしかない。
「趣味でやった結果がなんとなく仕事に役に立つ」は良いが「仕事のために趣味の時間を使う」のは間違えている。
僕が嫌だなと思うのは、趣味で好きでやってた結果仕事に役に立って金を稼いでいるケースなのにも関わらず、それを「努力」の結果だとしようとするところで、一見マトモそうな人でもこういうことを平然と言ったりするので気が萎える。あくまで、仕事に役に立つことに興味を持ってとりくんでいるのは「たまたま」なので、それでマウンティングかけるようなのはイライラしてしまう。
趣味と仕事が直結しているのは (たとえば自分もそうだけど)、基本的にはチートなので、あんまりおおっぴらに誇れることではなくて、たまたまそういう状態にあるというだけだと思う。まぁチート・ずると言うとトゲがあるけど、業務の視点からいえば残業して評価をあげるのとなんら変わらない。
コミュニケーションには非対称性があって、立場が違うと言っていいこととわるいことが変わる。趣味と仕事が結びついていなくても、ある行為を自分のためにすることかどうかというのが肝心だと思う。
経営者が「個人の時間を使わないと不利益があるぞ」というのは全くダメだし、もともと業務時間内だけでも十分成果が出せるような人はいるので、時間の使いかたに口を出すのは間違えてる。
とはいえ「個人の時間を使わないと不利益があるぞ」というのは正しい。このとき「今の仕事」だけで考えてはダメで、従業員的には1つの会社にバインドされるのを避けないといけない。このときにする「勉強」っていうのは業務すなわち所属会社のためのものではなくて、自分の生存のためのものでリスクヘッジのためにある。それが結果的に今の仕事に役に立つことはあるかもしれないけど、それは「たまたま」である。
見沼代用水西縁緑道
氷川神社・氷川女體神社
氷川女體神社 → 氷川神社と行ってみた。
氷川女體神社
東浦和から徒歩でいった。1時間ぐらい歩く。
だいたい見沼代用水西縁緑道を歩いていけば気持ちよく歩ける。元々見沼だったところは開発規制されているので、びっくりするほど田舎の風景が広がっている。
前に訪れたときは本殿改修中だったが今回は大丈夫だった。
祭祀遺跡というのがあってちょっと面白い。RPG に出てくるみたいな離れ小島みたいなものがある。
氷川神社
大宮駅から、先に本殿に御参りしてから参道を逆に歩き、さいたま新都心駅まで。
氷川神社、訪れたことがあったはずと思っていたけど、どうやら別の氷川神社だったみたいで、完全に初見だった。
大宮駅自体も下車するのは初めて (新幹線に乗るために行くことはある)。思ったより駅前が開発されてないんだなという印象。
思ったよりもかなり参拝客が多かった。大宮駅に近いことは近いが、微妙に歩く必要がある (明治神宮と原宿みたいな近さではない)
境内も広くて立派な神社だった。
氷川神社は参道が 2km と全国最長とのこと。ちゃんと参道を一の鳥居から歩くならさいたま新都心駅で降りないといけない。まぁ参道といっても車道が通っていたり住宅が隣接したりしていて、純粋に参道っぽい参道はかなり短い。
この参道入口はブラタモリの大宮編に出てきたので見たことある人は多そう。
ほか
氷川神社 (男体社) と氷川女體神社 (女体社) を直線で結んだ中間あたりに中山神社 (中氷川神社・氷王子社)というのがあって、これも行きたかったが今回は諦めた。
これら3つの神社は見沼というかつてさいたまにあった沼の辺に建っていたらしい。
もともと沼も含めて (今は分かれている) 3つの神社が本来1つの神社として広大な神域を持っていた説があるらしくて夢がある。
✖
関連画像を表示
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 に書いてあるのとほぼ同じ。
✖
✖
redeveloped タグをつけてる写真は過去の写真を演出… | Thu, Jul 13. 2017 - 氾濫原 をやろうと思って、画像ハッシュ化方法である pHash (64bit) avgHash (64bit) を試してみたけど、ウーンって感じだった。まぁまぁうまくいっている気もするけど、全然似てない写真の距離が近いこともある。
理由として想像すると
- pHash も avgHash も色情報を捨ててる
- 64bit (8x8) だと足りない
なので、色を考慮したハッシュ化をしたい。チャンネルごとに pHash にするとかなのかなあ。8x8 のままで RGB 3chとると単純に192bitになる。
もうちょっとコントロール可能にするなら、YCbCr にして、それぞれハミング距離を求めつつ、チャンネルごとに係数をかける (どの程度色情報を考慮するか決定する) とか？
✖
✖
redeveloped タグをつけてる写真は過去の写真を演出を変えて再現像したものになってる。
なので、過去のエントリがあるならリンクを貼りたいなと思ったけど、日記のどこに貼ったかは全くわからないので難しい。しかも全て画像は Google Photos にある。
やるとしたら
- 一度日記内の画像を全てダウンロードして特徴量検出とインデックス化をする
- 日記保存時にも同様のことしつつ、類似画像を検索する
みたいになるのかなあ。「類似」といっても、現像パラメータの違いだけなので、ほとんど全く同じなんだよなあ。
✖
