GitLocker: The Coding Marketplace

Description:

iphoto 0.2.2

Command line utilities for managing an iPhoto library.
Warning: not tested with any version of iPhoto aside from my own, which is
currently v9.5.1. Use at your own risk.
Currently requires python 3.4. Not for any serious reason, but it’s the only
version I’ve tested with.

Installation
pip install iphoto

Command line usage
Warning: exec is a dangerous, potentially destructive command that directly
operates on your iPhoto database. Backup your library before proceeding.
Warning: If you run exec and concurrently make changes via iPhoto, the
results are not predictable. The least you can expect is some lag between an
action in iPhoto and an observable change on the command line, but also be
aware of the potential for data loss, since the application could operate from
a stale cache of recent changes. iPhoto has no reasonable expectation that
other applications are using its database.
The exec command relies on some knowledge of the iPhoto object model,
which is described in its own section below.
# If you don't specify any specific actions, the `exec` script defaults to
# `print(master)`:
$ iphoto exec
The Badlands / DSC_0240
... snip ...
Unnamed event (10/30/2014) / 20141030_150848

# Unless you specify the `--commit` flag, everything is executed in
# "dry-run" mode. For instance, this lists the photos that would be
# modified by the `--reset-time` action:
$ iphoto exec --reset-time

# Different filters are available for constraining which photos `exec`
# applies to. For instance, this resets the v1 time to match the master
# time for photos in the Mayhem album:
$ iphoto exec --album='Mayhem' --reset-time --commit

# This subtracts an hour from flagged photos in the Mayhem album:
$ iphoto exec --album='Mayhem' --flagged --offset-time='-3600' --commit

# You can specify a generic python script which executes in the context of
# a single photo. For instance, this unflags everything from events
# containing photos from 10/14/2014:
$ iphoto exec --event='2014-10-14' --commit 'v1.isFlagged = 0'

# This prints the name and image path for every photo from the event of
# 10/14/2014:
$ iphoto exec --event '2014-10-14' \
'print("%s\t%s" % (master.name, master.imagePath))'

# This prints the file sizes of all flagged photos:
$ iphoto exec --flagged 'print(master.fileSize)'

Object model
iPhoto doesn’t apply any image adjustments to the originally imported “master”
image. Instead, it keeps a copy of each image’s Exif data in a SQLite database.
In fact, it actually keeps three copies–the master, v0, and v1 records, and
all of them are created on import. The properties you see in the UI all come
from the v1 record. I recommend that you stick to the same approach: edit v1,
and, if necessary, revert it by copying properties from v0 or from master.
When you export photos out of iPhoto, the properties from v1 are automatically
applied to the exported photos.

Album types
There are three types of album records:

Events: exactly what you’d think if you’ve used the UI. Each photo is
associated with exactly one event album, which is referenced by master and
version records via projectUuid.
Smart albums: custom-made albums with dynamic, query-defined contents.
The query is hidden away inside of a keyed archive, which is itself stored
in the album’s binary plist file. This album type is currently unsupported
by iphoto.py because I haven’t found or written a parser for the keyed
archive format. It’s technically similar to bplist parser, but more
complicated.
Regular albums: custom-made albums with a static, user-curated image
list. The v1 uuids of the included images are listed in the album’s binary
plist file.