Moving Picasa database from Window to Mac OS X

In the process of consolidating the digital presence of the family on a beefed-up MacBook, I have come to the point of moving the digital photo library. Moving the files almost did the trick, but to get my Picasa albums across, some hacking was required: We currently handle the library with Google Picasa which (apart from being very nice to work with) does things “the right way”: It does not touch your original photo files, allowing you organize your them according to your desires, and it stores the metadata in the most accessible form possible:

  • Image edits does not affect original files: instead the edits are stored in picasa.ini files in the same folder as the file.
  • Keywords (tags) and captions are stored as IPTC comments directly in the photo files.

This means that if you just move your photos (with associated picasa.ini files) across from Windows to Mac, and fire up Picasa you are almost back to start with the only thing missing being information about albums (ordered collections of photos). The following is a recipe for getting that last piece across.

Outline:

Move photo files to mac. Make sure to grab a copy of 

  1. <picasadir>/Picasa3Albums (as a zip file)
  2. <picasadir>/Contacts/contacts.xml



Install and start Picasa, create an album and quit when scan has completed (skip face scan).

Edit album (.pal) files to match new file location.

Put .pal files as ~/Library/Application Support/Google/Picasa3/Picasa3Albums/<databaseid>/<albumid>.pal

Replace <picasadir>/contacts/contacts.xml with old version

Delete ~/Library/Application Support/Google/Picasa3/db3 to force database rebuild.

Start Picasa and watch your albums and people appear :)

Detailed notes

The album information are stored in .pal files below your google folder:

google
+ Database ID
  + Album1 ID.pal
  + Album2 ID.pal
  + Album3 ID.pal
  + ....

where Database ID and Album ID are MD5 hash strings. The google folder is located as follows:

Vista
C:\Users\<username>\AppData\Local\Google

XP
C:\Documents and Settings\<username>\local application\Google

OS X
/Users/<username>/Library/Application Support/Google/Picassa3/

You want to grab the whole folder Database ID and copy it to a zip on the mac (keep the original zipped because Picasa eats the pal files if it sees them when scanning). The .pal files are xml files. Search and replace over all of them to get the image paths right. I used two passes: first pass to convert \ to /, and second pass to correct the beginning of the paths.

Update

Just added step 5 to include the ‘people’ data as well. The image-specific data is stored in the picasa.ini file (again, Google is doing things the rights way), but this only links a given person to a unique number. To link that number to an actual person, you need to copy the file contacts.xml across as well.

Update 2

According to Milan’s comment below, the contacts trick doesn’t work if you are moving from Windows to Mac. Just for reference, here is how the contact info seems to be stored:
From <picasadir>/contacts/contacts.xml: ``

<contacts>
 <contact id="f...1" name="L..." >
 <subject user="j...h" id="2...9" person_id="3...Z-t...g"/>
 </contact>
</contacts>

From Picasa.ini: ``

[IMG_0150.JPG]
IIDLIST_j...h=4...2
faces=rect64(2ca08e7f3c00a6ff),f...1
backuphash=1493
[Contacts]
f...1=j...h,2...9

So the connecting path is “Image” -> “Picasa.ini” -> faces -> (subject.user,subject.id) -> “contacts.xml” -> contact.id. It seems from Milan’s comment that you might need to do some search and replace in contacts.xml after a move (followed by clearing the database). Note that subject.user and subject.id both match my user data in the case above. I don’t know whether this needs to be the case. Also I have no idea how the subject.user and subject.id are assigned when you create a new picasa database.
One thing I can’t quite grok is that the Exif.Photo.ImageUniqueID stored with the image is ‘c…5’, which doesn’t match any of the ID’s above. What the relation to the Unique ID and Unique ID(DB) mentioned by codesmith below is also a bit unclear :)