This plugin imports face data from Google's Picasa Photo-management app.
This document describes version of the plugin from 20141120.58 (released on or after Nov 20th, 2014). Prior versions
of the plugin worked differently; users of older versions are encouraged to update the plugin to the latest version.
This plugin works in Lightroom 6/CC (and older versions as far back as
Lightroom 3, though some features depend on the
version of Lightroom).
The same download works for both Windows and Mac. See the box to the upper right for the download link (in orange) and installation instructions.
When considering whether to use the Picasa desktop application on the
photos in your Lightroom catalog, be warned that Picasa may update your image files with its own
metadata. This could cause a conflict between the apps, and worse for
some, it means that your master image files can be changed without notice
(some people prefer a workflow in which the out-of-camera master image
files are absolutely immutable — that is, never, ever, changed).
It's best to understand exactly if/when Picasa might want to change your
files, and avoid it. In my case, I simply ensured that 1) I had a good backup before giving it a try,
and 2) that every image file was marked
Prior versions of this plugin required that Picasa's
“Store face tags in image files”
option was disabled. As of plugin version 20141120.58 it no longer matters.
Using the Plugin
Before importing face data the first time, invoke “File > Plugin Extras > Picasa Face-Data Settings”
to choose whether face-related keywords created by this plugin should be marked “included on export”. By default they are not.
From then on, once you have done new face-recognition work on some
images in Picasa, simply select the same images in Lightroom and invoke
“File > Plugin Extras > Import Picasa
Face Data”. The plugin creates and maintains a list of
face-name keywords under an all-encompassing parent keywords “Picasa
The plugin matches up image data via image filename and path, so both
Picasa and Lightroom must be working with the exact same image files (and
not, for example, merely identical copies).
If you make changes in the list of faces for an image in Picasa, simply
re-invoke the face-data import in Lightroom to read the new data.
You can move or rename the “Picasa Faces” parent keyword as you like,
but generally, you should not rename or move child keywords that the plugin
creates under it. The plugin creates keywords with names from the Picasa
database, and assigns and unassigns them to photos as appropriate.
When the face-data import is going on, for each name referenced by the
photos, the plugin ensures that there's a similarly-named child keyword
under the “Picasa Faces” parent, creating it if required. Then, for each
photo under consideration, the plugin ensures there's a child keyword for
each Picasa-assigned name, and that there are no extra child keywords.
This means that all face maintenance must be done in Picasa:
adding, removing, or renaming face-related keywords in Lightroom does
not reflect changes back to Picasa; any such changes for a photo are
lost the next time you do a face-data import for the photo.
Renaming a Face — If you rename a face in Picasa, it's the
same to this plugin as deleting one face and adding another. However, if
you rename a face in Picasa and apply the same rename operation on
the associated child keyword prior to the next face-data import, the
renamed keyword should be used as expected. This won't matter either way
for most people, but it is important if you have made custom changes to the
keyword settings, such as whether to include it on export, or created
Count of Faces
The plugin keeps one item of custom per-image metadata, “Faces”,
a count of how many faces have been registered for the photo. It starts off
as “Unknown” for photos that have not been subject to face-data
import, but becomes “none”, “1”, “2”, “3”, etc.
to reflect the number of faces. This field can be used within the library grid filter
(select “Faces” in a “Metadata” column) and smart-collection rules.
This plugin is distributed as “donationware”. I have chosen to make it available for free — everyone can use
it forever, without cost of any kind — but unless registered, its functionality is somewhat reduced after six weeks.
Registration is done via PayPal, and if you choose to register, it costs the minimum 1-cent PayPal fee; any amount you'd like to
add beyond PayPal's sliding fees as a gift to me is completely optional, and completely appreciated.
For details, see my blog post titled Lightroom Plugin Development:
Now With Added Encouragement. If you're interested in how I picked up a plugin-development hobby like this, see My Long Path To Lightroom Plugin Development.
Update Log via RSS
Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time.
In the POODLE-vunerability dialog, display a raw URL of a page on my site that discusses the issue, so that folks can be independently sure that the dialog is indeed from me and not malware.
Fixed crashes when reading some large Picasa databases.
Added a progress-bar indicator while reading the database, and allow the read to be canceled.
Completely redid the interface to Picasa's data. The plugin no longer cares about the ".ini" files,
and instead just groks Picasa's (wildly cryptic and circa-1970s) database.
This makes the plugin much more robust because modern versions of Picasa didn't always keep the INI files up to date.
Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists.
Fixed an issue with Creative-Cloud revalidation.
Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed.
Sigh, had a bug in the Creative-Cloud support.
Now supports Lr5.5+ Creative-Cloud Installs.
Sigh, introduced an error for some folks with the rebuild the other day.
Added an "Expunge Plugin Data" section to the plugin manager, to allow plugin data to be cleared from the catalog.
Fixed a bug in the "smoother revalidation" stuff recently added.
Make the revalidation process smoother, especially for folks using Lr5.4 and later.
Worked around an intermittent problem in Lightroom that caused the plugin to wedgie in the plugin manager
Added the ability to bulk set/clear the "Include on Export" flag for all face keywords.
Fix an "attempt to perform arithmetic on field" error.
Update to handle the Mac App Store version of Lightroom.
Tweak for Lr4.1RC2.
Enhanced the send-log dialog to hopefully make reports more meaningful to me,
yielding, I hope, the ability to respond more sensibly to more reports.
Had broken registrations in Lr2; Update to the debug logging to better track down timing issues that might arise.
More on the march toward Lr4, including upheaval in the code to handle Lightroom APIs being discontinued in Lr4.
Fixed "attempt to index a boolean value" error.
Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta.
Had issues with the registration button sometimes not showing.
When doing a plugin upgrade, offer the ability to flush all the old copies of the plugin.
Added a system-clock check and reports to the user if the system clock is more than a minute out of
date. An incorrect system clock can cause problems with various kinds of communication and authentication
with some of my plugins, so I've just gone ahead and added this to every plugin.
Handle the situation where Lightroom has raw+JPG, but Picasa has only JPG.
If the plugin can't find the Picasa db3 files where it was told, give the user a chance to change
the location. Duh!
Added a new setting to allow face keywords to remain even if the face is no longer referenced in Picasa,
allowing you to tweak the face data manually.
Also check for face data in a folder's "Picasa.ini" (sans leading dot), since old versions of Picasa
used that. Added some extra debug logging to try to track down a db-load issue.
Fixed the plugin crash... the plugin wouldn't have worked for those with nested keywords, sorry. Fixed.
Add some debug logging to track down a plugin crash.
Rather than accumulate keyword changes until the end of the operation, write them to the catalog
in small lumps as the face-data import goes on. This has the drawback of potentially littering
the undo stack with many operations, but it avoids a potentially long period of "lockup" once
all photos have been scanned.
Yikes, was too aggressive in cleaning up unused face keywords, and was actually removing
all non-face keywords(!). Fixed.
Turns out that I was not reading the Picasa data properly, missing on average 1/16th of the names.
Now manages names with real keywords. Now requires Lr3.3.
Final version for Lr2. Subsequent versions will require Lr3.3 or later.
Made the revalidation process much simpler, doing away with the silly need for a revalidation file.
Discovered a bug in my plugin build system that caused horribly difficult-to-track-down errors in one plugin,
so am pushing out rebuilt versions of all plugins just in case.
Discovered a nasty build bug; pushing a new version in case it affects this plugin.
Remove the expiration... sorry, that had been left over from testing.
My bad, sorry, hadn't tested the previous fix on Windows.
Add a dialog that allows the user to specify where the Picasa "db3" folder is on their system, for when
the plugin can't figure it out on its own.
Completely changed how the one-click upgrade applies the newly-downloaded zip file, in the hopes that
it'll work for more people. Rather than unzipping over the old copy, it now unzips to a temporary folder,
then moves the old folder out of the way and the new folder into place. Prior versions' folders are now
maintained (with the version number in the folder) in case you want to revert a version; you may want to
clear them out from time to time. Of course, it won't take affect until you try to upgrade after
having upgraded to or beyond this version.
Turns out that there's a Lightroom limit to the length of names I can record for a photo, so to avoid
errors, I've taken the equally unappealing option of lopping off the name list at its maximum value (511
Okay, tried to be just a bit less stupid about looking for the "db3" folder.