Important: The information in this article is based on my personal experience using the following setup: Dropbox v2.6.2, iPhoto '11 (version 9.4.3) and OS X Mountain Lion 10.8.5. Different versions may have different behavior. Let me know in the comments!
The wonderful Dropbox iPhoto Import feature. You just press a magic button and all your photos and videos will be copied from iPhoto into a Dropbox folder. That's great! But... How about the nerdy details?
The application will copy the photos to a top-level folder named Photos from iPhoto in your Dropbox. Within this folder, the photos will be organized into subfolders that correspond to the events from your iPhoto library.
Okay. But I still have a few questions...
- iPhoto must be running during the import?
- Both original and modified photos will be imported?
- PNG files are also imported?
- It will take seconds, minutes or hours?
- In what order the photos are imported?
- Events turn into folders?
- What about albums?
- What will be used as filenames?
- What permissions will be set for the files and folders?
- What date/time will be set to the photo file on disk?
- Photo date/time will be preserved?
- EXIF data will be preserved?
- Metadata will be preserved?
- Duplicated event names are OK?
- Unicode characters and symbols in event names are OK?
- Can I run this import multiple times?
- Can I rename or move the "Photos from iPhoto" folder?
- Can I rename or move the original iPhoto library?
- What if I have multiple iPhoto libraries?
iPhoto must be running during the import?
No, it doesn't matter. You can freely open and quit iPhoto during the import.
Just don't add/remove/edit photos during the import to avoid weirdness.
Both original and modified photos will be imported?
If you have edited the photo, only the modified version will be imported.
If you haven't edited the photo, the original will be imported.
PNG files are also imported?
It will take seconds, minutes or hours?
My experience was slooooooow.
The import process took 24 hours to copy my 14.6 GB iPhoto library (7792 photos, 348 videos) in my Mac mini (2.5 GHz Core i5 CPU, 10 GB RAM, 5400 rpm HD). And of course, some more hours to finish the upload (since it imports and uploads at the same time).
For comparison, phoshare took less than one hour to export the same library on the same machine.
However, Dropbox is usually slow here with my 200,000 files inside it. YMMV.
Now thinking about it, I should have used the "Pause Syncing" feature of Dropbox to avoid the uploading during the import process. Maybe it would have speed things up.
In what order the photos are imported?
The import happens in reverse chronological order. Dropbox starts importing the photos from the most recent event and then goes back in time, event by event, until the very first one (the oldest).
Note that this affects the auto numbering in repeated event names.
Events turn into folders?
Yes, each event will be imported into a subfolder under the main "Photos from iPhoto" folder. Examples:
Dropbox/Photos from iPhoto/LOL Cats/ Dropbox/Photos from iPhoto/Maria's Wedding/ Dropbox/Photos from iPhoto/Trip to Rio/ Dropbox/Photos from iPhoto/Weekend with Grandpa/ Dropbox/Photos from iPhoto/Xmas 2013/
Exception: If there's just a single event in iPhoto, the subfolder won't be created and all imported photos will appear directly under the "Photos from iPhoto" folder. Then if there's a second event in iPhoto in a future import, this new event will have its own subfolder. The already imported photos from the first event will remain folder-less.
What about albums?
They are ignored. Only events are imported.
What will be used as filenames?
Filenames follow the same pattern used in the Camera Uploads special folder. For example:
It's a timestamp composed by the date (
yyyy-mm-dd) and time (
hh.mm.ss) when the photo was shot. Examples:
Dropbox/Photos from iPhoto/Trip to Rio/2014-01-28 16.12.24.jpg Dropbox/Photos from iPhoto/Trip to Rio/2014-01-28 16.15.49.jpg Dropbox/Photos from iPhoto/Trip to Rio/2014-01-28 16.39.11.jpg
Note that when the photo's EXIF date differs from the iPhoto Info pane's date, Dropbox always use the iPhoto date to compose the filename. Read more about it.
What permissions will be set for the files and folders?
rwxr-xr-x(755) for folders
rw-------(600) for files
What date/time will be set to the photo file on disk?
The file modification time (mtime) will be set to the same timestamp used in the filename.
-rw------- 1 aurelio staff 855539 Jun 11 2009 2009-06-11 16.05.51.jpg -rw------- 1 aurelio staff 799298 Jun 11 2009 2009-06-11 16.05.56.jpg -rw------- 1 aurelio staff 844112 Jun 11 2009 2009-06-11 16.06.03.jpg -rw------- 1 aurelio staff 795568 Jun 11 2009 2009-06-11 16.06.16.jpg -rw------- 1 aurelio staff 737503 Jun 11 2009 2009-06-11 16.06.39.jpg
In other words, this means that in the Finder, a photo taken in the first day of 2010 will have 01/01/2010 in the Date Modified attribute.
Photo date/time will be preserved?
Yes, but with a catch.
There's the EXIF date, which is the date set by your camera at the moment the photo was shot. This date is stored in the EXIF tags named "Date/Time Original" or "Create Date" and is always preserved. Dropbox never changes it.
There's the iPhoto date, which is the date that appears in the Info pane when the photo is selected in iPhoto. This is the date Dropbox uses for the filename.
Usually these two dates are the same, then there's no problem.
But the dates will differ when you use iPhoto to fix the photo date and forget to check the "Modify original files" option. Then the EXIF tags won't be updated and the new date will only be saved in iPhoto's internal database.
Dropbox will use the fixed date for the filename, but the original incorrect date will remain in the EXIF tags, which is a problem since most photo tools rely on the EXIF tags to get the photo date. For example, the photo order will appear correct in the Finder, but wrong in Picasa.
After the Dropbox importer finishes its job, you can fix the photo's EXIF metadata with an external tool. I recommend the excellent exiftool. Here's some commands you can run on the Terminal.
# List all photos whose EXIF date differs from filename date: exiftool -createdate -filename \ -d '%Y-%m-%d %H.%M.%S' \ -csv \ ~/Dropbox/'Photos from iPhoto'/* | egrep -v '.*,([^,]*),\1' #-------------------------------------------------------------------------- # Update the EXIF dates from all photos to match the filename timestamp. # AllDates is a shortcut for DateTimeOriginal, CreateDate and ModifyDate. # Option -P is needed to preserve the file's current mtime. exiftool -P -alldates'<filename' ~/Dropbox/'Photos from iPhoto'/* #-------------------------------------------------------------------------- # Remove the _original files that exiftool created as backups: exiftool -delete_original ~/Dropbox/'Photos from iPhoto'/* # or restore from the backups if you want to revert the changes: exiftool -restore_original ~/Dropbox/'Photos from iPhoto'/*
EXIF data will be preserved?
Yes, no EXIF data will be lost.
The Dropbox importer do not add nor remove EXIF tags, it will just rewrite these four tags:
- File Name
- File Permissions
- File Modification Date/Time
The first three must be changed because Dropbox is in fact changing the filename, location and permissions, so the tag contents must be updated to the new values.
The last tag is set to the iPhoto info pane timestamp, which is the same timestamp used by Dropbox to compose the filename and to set the file modification date in the file system. Consistence is good.
Metadata will be preserved?
YES, for the EXIF metadata your photo already had before it was imported into iPhoto, such as GPS coordinates or the Rating tag. The Dropbox importer will not remove them.
NO, for any metadata you added using iPhoto:
- GPS coordinates
The photo's EXIF header would be the portable place to store most of this information, but neither iPhoto nor Dropbox importer add EXIF data to the photo.
- iPhoto never changes the original photo file, so it saves the metadata in its internal database.
- Dropbox importer do not create new EXIF tags on the imported files.
If someday one of those changes, iPhoto metadata won't be lost.
Note that in latest versions, iPhoto prevents third party apps from accessing keywords. So even if the Dropbox importer starts to save metadata to EXIF, iPhoto keywords can't be read anymore :(
Duplicated event names are OK?
Yes. Dropbox will add numeric suffixes to avoid name collision in folder names.
For example, if you have four distinct events called "My lunch" in your iPhoto library, this is how they will translate to folders in the import:
Dropbox/Photos from iPhoto/My lunch Dropbox/Photos from iPhoto/My lunch (1) Dropbox/Photos from iPhoto/My lunch (2) Dropbox/Photos from iPhoto/My lunch (3)
Note that since the import is done from the most recent to the older event, the folder name order is inverted. From the example, "My lunch (3)" will be the first (the oldest) event in iPhoto.
Unicode characters and symbols in event names are OK?
Unicode characters won't be a problem. They will be used unchanged in folder names.
But these special ASCII symbols will be replaced by hyphens:
" * / : < > ? \ |
So, if you have an event name with any of these symbols, the corresponding folder with be slightly different:
iPhoto event name: 12/21/2012: The end of the world??? Dropbox folder name: 12-21-2012- The end of the world-
Note that "???" turned into a single "-". Besides replacing symbols by hyphens, consecutive symbols are squeezed to just a single hyphen.
Yes, dear Unix geek reader, it's like a
Squeezing makes prettier names, but also opens the possibility of generating duplicated names. When you have events where the only difference in their name is a single symbol, for example:
Pictures rated * Pictures rated ** Pictures rated *** Pictures rated ****
They will end up with the same name: "Pictures rated -". Then comes in the automatic numbering to differentiate them:
Pictures rated - Pictures rated - (1) Pictures rated - (2) Pictures rated - (3)
Can I run this import multiple times?
Dropbox remembers which photos were already imported and in subsequent runs will only import the new photos (if any). This is the same behavior as the Camera Uploads feature.
If later in iPhoto you remove events or photos that were already imported into the "Photos from iPhoto" folder, Dropbox won't remove them in the next import. It's a one-time copy, not a sync.
Can I rename or move the "Photos from iPhoto" folder?
Yes, but then it will turn into a normal folder.
When you run the importer again, the default "Photos from iPhoto" folder will be recreated. But don't worry, it won't copy all the photos again. Dropbox remembers which photos were already imported and will just import the new ones (if any).
Can I rename or move the original iPhoto library?
Once you did the first import, Dropbox will remember the exact location of your iPhoto library. If you plan to run the importer again, it's safer to let the library location untouched.
If you rename or move the library and never open it in iPhoto, Dropbox won't be able to find the new library location. Then the importer will say that it haven't found any photos.
If you rename or move the library and open it in iPhoto, the references will be updated and Dropbox will find the new location. But it will copy all photos over again, creating duplicates.
What if I have multiple iPhoto libraries?
Prepare for weirdness.
When you open a second library in iPhoto and run de importer again, it will detect the new photos, but will copy them to the old folders from the first library import! Even if you clear the "Photos from iPhoto" folder it will recreate the subfolders with the old event names. It's a bug and may be corrected in future versions of Dropbox.
Meanwhile you can try to hack Dropbox to make it "forget" the old event names by emptying the cache or by renaming its internal folders (
~/.dropbox-master). I don't know if that works because I didn't dive this deep in my tests.
I've also made some tests with multiple libraries in my old machine with Lion and iPhoto '09, but Dropbox showed a dialog with the following error: "Sorry, an error occurred. Please try again later...".
It's safer to stay single-library for now.