.lrcat っていったい何なのか

カタログファイルの実体である lrcat は SQLite の DB ファイルそのもの。sqlite3 foo.lrcat すると中身を見ることもできる。

部分的に見た結果をメモしておく

# 画像に対応するテーブル?
Adobe_images
# Exif 情報に対応するテーブル?
AgHarvestedExifMetadata
# ファイルに対応するテーブル?
AgLibraryFile
AgLibraryFolder

# 画像とファイルのリレーション?
select Adobe_images.captureTime, baseName, modTime from Adobe_images inner join AgLibraryFile on Adobe_images.rootFile = AgLibraryFile.id_local;

# 画像と exif のリレーション?
select * from Adobe_images join AgHarvestedExifMetadata on AgHarvestedExifMetadata.image = Adobe_images.id_local;

たとえば

sqlite> .schema AgHarvestedExifMetadata
CREATE TABLE AgHarvestedExifMetadata (
    id_local INTEGER PRIMARY KEY,
    image INTEGER,
    aperture,
    cameraModelRef INTEGER,
    cameraSNRef INTEGER,
    dateDay,
    dateMonth,
    dateYear,
    flashFired INTEGER,
    focalLength,
    gpsLatitude,
    gpsLongitude,
    gpsSequence NOT NULL DEFAULT 0,
    hasGPS INTEGER,
    isoSpeedRating,
    lensRef INTEGER,
    shutterSpeed
);

なので (index は省略)、dateYear ごとの focalLength 統計を求めたい場合は

select dateYear, focalLength, count(*) from AgHarvestedExifMetadata group by dateYear, focalLength;

とか、もっとシンプルにレンズ焦点距離の使用頻度なら

sqlite> select focalLength, count(*) as cnt from AgHarvestedExifMetadata group by focalLength order by cnt;
...
24.2|1003
35.0|1037
|1093
200.0|1139
18.0|1153
22.0|1307
24.0|1378
70.0|1928
50.0|1978
30.0|4265
100.0|4522

みたいなことはできる。

レンズ名ごとの撮影枚数 (Lightroom 上でもわかるが) なら

 select AgInternedExifLens.value, count(*) as cnt from AgHarvestedExifMetadata join AgInternedExifLens on AgHarvestedExifMetadata.lensRef = AgInternedExifLens.id_local group by lensRef order by cnt;

とか。

今年の統計 (これも Lightroom 上でもわかるが) だけならこんな感じとか

select AgInternedExifLens.value, count(*) as cnt from AgHarvestedExifMetadata join AgInternedExifLens on AgHarvestedExifMetadata.lensRef = AgInternedExifLens.id_local where dateYear = CAST(strftime("%Y") AS NUMERIC) group by lensRef order by cnt;
24-70mm|10
20mm|17
EF50mm f/1.4 USM|75
EF-M22mm f/2 STM|77
EF70-200mm f/2.8L IS II USM|253
EF100mm f/2.8L Macro IS USM|353
35mm|428
E PZ 16-50mm F3.5-5.6 OSS|1260
30mm F1.4 DC DN | Contemporary 016|4083

もうちょっと Lightroom 上で見れない統計を出したいと思ったが思いつかなかったので思いついたら続きを書く

筐体全体の設計

穴あけ

穴あけは CNC フライスで行いました。配置検討した Fusion 360 からそのまま穴あけもモデリングして筐体の各面の CAM データを作成し、Gcode を出力して加工しました。

加工は φ1mm のエンドミルで切り込み 0.1mm、フィード 50mm/min でやりました。最近ようやく切り込みは限りなく小さくしてフィードレードをあげたほうが安全(折れにくい)ということがわかってきました。もっと太いエンドミルを使ったほうが早いですが、ちょっと細かいところもあって面倒だったので基本一括 1mm としました。

ただ、φ1mm のエンドミルだと Fusion 360 は φ1mm の穴のパスを作ってくれないので、該当部分だけ φ0.8mm で加工しました。

頑張って組む

設計ミスをリワーク

テスト中の様子

中はケーブルがかなりを占める

配線が結構多いので大変でした。100V を引き込むようにしたので、そのへんははんだ付け後にビニールテープで覆って、うっかり触れないようにしてあります。

電圧計・電流計 (どちらもスピンドル用) をどうしても付けたかったので余計配線が複雑化しました。

その他

筐体前面に出ている LED は BBB の USR LED そのままにしたかったので、光ファイバーで引き出しています。

非常ボタンはもともとツバがついていませんが、これも削り出してつくっています。

感想

かなり初歩的ではありますが 3D CAD を活用して筐体設計もそこそこ簡単にできることがわかりました。あとやはりモデリングは細部まで行うことが大事だという教訓を得られました。

自分用メモ：使いかた

1. 主電源を入れる
2. 自動的に BBB にも電源が入り、電源 LED が点灯する。起動プロセスに入るので USR LED 4つも明滅する
3. 起動するまで少々待ってから、VNC で接続する (Finder で Cmd+K)
4. (加工する)
5. 電源ボタンを押すと BBB はシャットダウン開始される
6. しばらく USR LED が明滅したのち、完全に消灯すれば主電源を切ることができる

追記 スピンドルコントロール

こういうのをPWM経由で制御している。

なぜ USB 3.1 Gen2 のハブ を探していたか

USB 3.1 Gen1 (USB 3.0) は伝送路における基本波が 2.5GHz なため、ISM バンドの 2.45GHz 帯 (2.4GHz〜2.5GHz)で電波障害が起きやすい。Gen2 なら問題ないはずなので、どうせ買うなら Gen2 に置き換えていきたいと思ったのでした。しかしまだ早かった。

USB 3.1 Gen1 = USB 3.0 ?

USB 3.1 Specification Language Usage Guidelines from USB-IF には以下のような記述がある。

Google Photos の画像の exif を得る

Google Photos の画像から exif 情報を得るのは簡単ではない。表示しているサムネイルのURLから exif 情報をとれるのが一番簡単なのだが、これはたぶんできない。URL にオリジナル画像や、後述するAPIリクエストに必要な情報が含まれているように見えない。

幸いこの日記では picasa へのリンク ( https://picasaweb.google.com/[userid/[albumid]#[photoid] みたいな形式 ) は保存してあったので、これを利用することにした。

exif を取得したい場合大きくわけると2つの方法がある

• オリジナル画像をダウンロードして自力で exif を解析する
• API 経由で取得する

が、オリジナル画像の URL を取得するためには API リクエストをしないといけないので、とにかく API リクエストを行う必要がある。オリジナル画像の URL を取得するレスポンスには exif のメタデータも含むため、これで足りるならわざわざオリジナル画像をダウンロードする必要はない

Invalid な albumid を回避する

Picasa API という既にメンテされていないAPIを使わなければならないのだが、userid albumid photoid 全てがわかっていないと画像のメタデータを取得することができない。

保存されている picasa へのリンクに全てあるのだが、albumid に invalid なものが含まれることがある。これは Google Picker API 経由で取得したものなので、 Picker API がなんか不思議な URL を返すようだ。意味がわからないんだけどなぜかそうなっている。

これじゃあ無理かと思いつつ試していたところ、albumid は valid で存在してさえいれば、photoid の親でなくとも良いということがわかった。画像が含まれるアルバムのIDというのを知る必要はないのだ。

ということで、userid は簡単に調べられるし、albumid には適当に存在する albumid を指定しておけばよいということなので、実質的には photoid だけでメタデータを取得できた。