何回も書いてきたわけですが。できが悪いんです。データベース設計が絶望的に悪くて、version up のたびに「ライブラリのバージョンアップをしますか?」と言われれる。もちろん、元には戻れない。
紆余曲折の結果、
元 Master/2013/02/01/20130201-103002/
変更 Preview/2013/02/01/20130201-103002/
みたいな形式になったようですが、Photo Stream が、この下に subdirectory を作る(らしい)。その前にも「ロール 1」とかだったり、その場で読み込んだファイル名だったり、 Jul\ 15,\ 2008/ だったり、2005:10:14 だったり。
これが bitcasa で、そのまま出ちゃうのでデタラメな感じに。
これはイベント名にもなっているのだが、イベント名は別データベースで持っているらしく、イベント名を変更しても folder 名は変わらず。 気持ちはわかるんだ。iPhoto は外部に写真を持つことができたので写真があるパスは別管理なんだよね。
もちろん、これを勝手に変えると iPhoto は写真を見失ってしまう。昔はライブラリの修復ってのがあったはずだが、今はない。DB の構成が複雑すぎて sqlite3 いじれば良いというわけでもないらしい。path が散らばりすぎ。
もう一つ空の iPhoto を作って、そこに読み込むと、
Master/2013/02/01/20130201-103002/
の下に全部読み込まれる。あ、そうですか。このどうしようもなさよ。
見捨てたいソフト No.1 なんですが、Photo Stream がなぁ。まぁ、それはたまに手で移動するでも良いんだけど。
Picasa でも試すか? あぁ、でも Picasa もフォルダは、そのままなのか。iPhoto の方が Picasa よりはデザインは良いか。 これは、まず写真を定型的な folder に移してから、Picasa に読み込むのが良いのか? 悩むところだ。
Cloud 上では、Google の Blogger を使っている関係で Picasa です。Picasa に全部上げるという手もあるが、信用してないで。Bitcasa もメインで使うにはちょっとね。Bitcasa 側を rename するのが良いかなと思って script は書いたんですが、遅いです。遅い。それに rename 受け付けるのかどうか怪しい。
それでも、実家の「そこら中にアルバムと年賀状がある」という状況よりはましだとは思ってます。
No comments:
Post a Comment