This “export filter” plugin for Lightroom allows you to strip selected
metadata components from images as they are exported. You can use it, for
example, to remove the embedded thumbnail and any Lightroom
“develop” metadata, while retaining other metadata, such as the
exposure settings, lens information, copyright, etc.
This plugin works in
(though some features may be missing in older versions 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.
(Note: Please see the FAQ and known issues before reporting bugs.)
Here's a screenshot showing the options and features of the Metadata
Wrangler as it appears in the Export Dialog, as of its initial public
What metadata you choose to strip – and to leave intact –
can vary greatly depending on your intended use. For example, it makes
sense to strip at least the embedded thumbnail from small exports that are
themselves intended to be used as thumbnails. In such a case, it may well
make sense to strip everything but copyright information, to keep the file
On the other hand, it may well make sense to preserve most metadata
on images intended for upload to a photo-sharing site, yet remove the
embedded thumbnail that does little but increase the file size (and hence
the file-upload time).
In any case, only the exported copy of the image is affected; both the
original image and the Lightroom library are never changed by this
It's a “Filter”
I call the Metadata Wrangler an “export filter”, but in the official
Lightroom vernacular, it's a “post-process action”. The point is that
unlike a full export plugin (such as my “Export to Flickr” plugin), this
filter (post-process action) can be used with any export from
Lightroom. It can be used in conjunction with the standard “Files on Disk”
export, in conjunction with one of my other plugins (e.g. “Export to
Zenfolio”, “Export to PicasaWeb”), or any other third-party export
Metadata Can Be a Bit Tricky
I don't know that there's a good reason for it, but it's turned out that
image-file metadata formats have grown into somewhat of a mess. Luckily,
Phil Harvey has created the most excellent exiftool library
that makes this plugin's work much easier. It's the same metadata-handling
library used for the back end of my
online Exif viewer. I pass along half of any gifts I receive in relation to this
plugin to Phil.
Nevertheless, some of the “metadata mess” remains exposed to you, the
user, as evidenced by the mishmash of XMP blocks. Here's part of the
Metadata Wrangler in Lightroom's export dialog dealing with XMP blocks....
You can have all XMP data preserved or stripped by clicking on the
“preserve” or “remove” next to the “XMP Blocks” label at the top, but if
you want to be selective, you may have to do some research to see in which
block or blocks the data you're interested in lies. It's a bit cryptic for
the non-engineer, but the XMP-block
info at the exiftool site lists exactly what fields are in each block.
(The “XMP Info” button in the dialog links to that page as well.)
Two of the XMP blocks are fairly straightforward. The XMP “crs”
block contains all the information about Lightroom develop adjustments
(crop, exposure, localized corrections, etc.). You'll want to strip this
block if you want to hide – or just don't feel the need to include
with the image – all the develop changes you've made to an image.
The XMP “exif” block contains a repeat of most of the Exif data
represented individually lower in the dialog. I'm not sure that there's
100% coverage, but I generally strip it unless I intend the exported image
to be for some kind of archive.
The Metadata Wrangler supports its own preset mechanism. The dropdown
near the top of the Metadata Wrangler export-dialog section allows you to
create and recall presets of exclude/preserve decisions:
“Preserve Metadata” and “Remove Metadata” are standard presets that
adjust the settings to save/remove all metadata. You can create a new
preset by making some change to the dialog settings, then choose “save
current settings as a preset”.
The current settings for the Metadata Wrangler are also part of any
Lightroom Export Preset that you create while the Metadata Wrangler is
installed and enabled. Note that the individual settings are saved to the
Lightroom export preset, rather than any Metadata Wrangler preset name that
might be in effect. This means that if you create a Lightroom Export Preset
and then later change the meaning of a Metadata Wrangler preset, that
change is not reflected back into the Lightroom Export Preset. (This
paragraph is a bit confusing, sorry.)
Metadata Not Explicitly Listed...
The bottom of the dialog section includes a catch-all item that governs
how the whole plugin approaches its work:
When “Remove” is selected here, all metadata is removed, and then only
items explicitly listed as “Preserve” elsewhere in the dialog are added
back. Conversely, when “Preserve” is selected, the items explicitly listed
as “Remove” are manually removed from the exported image.
I believe that the end result is always the same – that all
metadata that could be in the image is listed earlier in the dialog –
but I've included this option as a “just in case”. When I'm exporting small
images for use as thumbnails on my site, for example, I strip everything
except what I explicitly want to keep: the ICC Color profile, and the
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
Note: a Lightroom major upgrade, such as
from Lr4 to Lr5, de-registers the plugin in the upgraded version, so if you
want to maintain registration, a new ($0.01 if you like) registration code
is needed in the upgraded version. It makes for a hassle every couple of
years, I know. Sorry. See this
note for details.
For details on plugin registration and on how I came into this hobby of
Lightroom plugin development, see my Plugin
As I mentioned above, this plugin relies heavily on the ExifTool
library, so I have decided to pass along half of any gifts related to this
plugin to the ExifTool library's author. If you choose to send a gift when
you register, it'll be handled automatically, but if you send a gift any
other time (they're always welcome ), please let me know so I can
share your kindness with Phil. In either case, a big thanks from Phil, too.
Update Log via RSS
Special keyword handling didn't necessarily work with non-ASCII characters.
Removed a reference (in Lr4+) to the "shadow data" maintained (in Lr2/Lr3) by my geoencoding plugin.
Apparently, a recent change broke things on Lr2, which some folks apparently still use.
Some more DNG-related updates, incuding a warning in the dialog about the dangers of removing metadata from DNGs.
Updated ExifTool to support modern DNGs, and some extra stuff to help remove metadata from DNGs.
(That last bit is a work in progress... some metadata still isn't being removed properly.)
Added the xmpMM section to the list of XMP sections the plugin deals with.
The "strip keyword suffixes" feature was broken.
Tidied up some of the debugging/logging code.
Upgraded to the embedded copy of ExifTool to version 9.09.
If a file can't be updated due to permission problems, perhaps it's because the OS is still holding the file open, so pause and retry a couple of times.
Fix an "attempt to perform arithmetic on field" error.
Update to handle the Mac App Store version of Lightroom.
Upgraded to ExifTool 8.92
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.
Found a way around the restriction of working with network shares on windows (paths that begin with \\),
and also fixed problems related to non-ASCII in file and path names. Wasted all day on this hairy area in Windows. Ugh.
Upgraded to ExifTool version 8.84.
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.
Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta.
Updated Image::ExifTool to version 8.75.
Updated Image::ExifTool to version 8.68.
Had issues with the registration button sometimes not showing.
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.
When doing a plugin upgrade, offer the ability to flush all the old copies of the plugin.
Change how perl is called under the hood on OSX.
Added some new Exif fields (Camera Serial Number, Camera Owner, Lens Make, Lens Model, Lens Serial
Number, Lens Stats, and a bunch of GPS-related fields) and re-organized the presentation to suit.
Folded the various sub-second-time fields into their respective date/time fields. Cleaner this way.
Upgraded to the embedded copy of ExifTool to
Tried to make the "remove with prejudice" option more prejudice, searching in more metadata groups for items to delete.
Also, made it so that removing "CreateDate" with prejudice now removes "DateCreated" wherever it might be,
as well as "TimeCreated", "DigitalCreationDate", and "DigitalCreationTime".
Added some extra debug logging to try to track down a Lightroom-hang issue.
Upgraded to the embedded copy of ExifTool to version 8.50.
Fixed (hopefully) a problem some have encountered when running a second time on a Windows install of Lightroom.
Upgraded to the embedded copy of ExifTool to version 8.40.
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.
Bumped up version of ExifTool to version 8.25.
Added code to allow plugin revalidation after having been locked due to a bad Lightroom serial number.
Discovered a nasty build bug; pushing a new version in case it affects this plugin.
This version can be registered in
Lightroom 3. It can run in Lightroom 2 or Lightroom 3; it does not work in the Lr3 betas.
It uses my new registration system when run on Lightroom 3,
which avoids some of the silly issues of the old one. Please take care to note
the details on the registration
page: use of this version (or later) of the plugin in Lightroom 3 requires a new
registration code, even if you had registered some older version of the plugin.
Did some internal housekeeping on the code to tidy up some messy handling of plugin
presets. Added a couple of extra built-in presets ("Touch of privacy", "Preserve only the basics")
to give new users some starting points. Also, the "set file modification date" option was advertised
to not be part of the plugin preset system, but it actually was. Fixed that, so now it is indeed not
part of the preset plugin system.
I didn't like how the special keyword stuff I added a few versions ago felt, so I redid it from
scratch, and added the ability to strip or preserve specific keywords (and/or keywords matching
filename-like patterns). I also added the ability to remove keyword prefixes or suffixes, thinking
that it might be useful. For example, you might have a set of keywords for one stock agency,
e.g. agency1-flower, agency1-dog, and another set for another (agency1-rose,
agency1-happy dog, and use the new functionality on export for the first agency by
stripping all keywords other than ones that match agency1-*, and then removing
the agency- prefix. Personally, I don't use keywords, so I don't know whether any of this
is actually useful. Let me know.
Warning: when hierarchical keywording is enabled (in the standard export-dialog
“Metadata” section), I'm not exactly sure what semantics would make most sense for the
keyword filtering and prefix/suffix removal features, so whatever it does in this version is likely not
useful, and likely to change in a future version. If you use hierarchical keywords a lot and have thoughts
about how this would work best, please drop me an email.
Added an option to have the plugin ignore output files that are not JPEG (such as when you export to DNG,
or export a raw file with a file-settings format of "Original".
Added new special-case handling for keywords. Keywords can be embedded in three different metadata
blocks, and if you merely want to suppress keywords for a particular export, deleting all three blocks
can be more than you want, so a new tri-state option for keywords, toward the bottom of the list, has
been added. By default it's set to do nothing, but you can set it to explicitly preserve or remove the
keywords in all their forms. It seems to be working, but do give it a test to be sure.
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.
I'm back from a long trip and starting
up the plugin machinery again. This version adds the "lr" XMP section (which is the "keywords as Lightroom
hierarchy", if you enable that in the "Metadata" section), and fixes a crash that some Windows users ran into
when the combination of selected items could sometimes create a command line longer than Windows could
Upgrading the built-in version of ExifTool to include support for DNG 1.3, required to work with
for DNGs made with Lightroom 1.4.
Enhanced the one-click upgrade stuff quite a bit, now
detecting ahead of time when it will fail because the plugin is installed where Lightroom
can't write (if Lightroom can't write to it, it can't update itself). I
also added a progress bar, and now download in smaller chunks to avoid 'out
of memory' errors on the larger plugins. Do remember that this new functionality becomes
available after you upgrade to or past this version, when you then upgrade with it.
Added a link in the Plugin Manager to the plugin's update-log RSS feed.
Added an option to "remove Exif items with prejudice". When enabled, marking an Exif item for
removal also removes the item from other places it might be found, including the XMP "exif" block,
inside an embedded thumbnail (which is unlikely, but possible in some strange cases where you're
exporting an original that was originally imported with a metadata-laden thumbnail), etc.
Added remove/preserve buttons to the overall "Individual Exif Items" header.
Made the "Set the exported image file's modification date to the image date" option part of
the preset state (so that it's value is saved and restored along with all the other settings).
Tweaked how the plugin tries to update itself during the one-click upgrade process,
to hopefully get things working for those few Windows users that have never had it work. Crossing
fingers. We'll see.
Changed the way files are updated, to avoid a potential problem (not yet actually seen) when
exporting huge 100MB+ files. Also added a boatload of
verbose debugging when the "extended logging" is checked in the Plugin Manager.
As requested, there's
now an option to set the file date of each exported image file to the image date. If the image has
"shadow GPS data" (from my geoencoding-support plugin) that includes a date, then that's used because it'll be the most accurate, having come from a GPS tracklog.
Otherwise, the DateTimeOriginal or DateTimeDigitized metadata value is used.
It seems that PayPal doesn't give everyone a "Unique
Transaction ID" in the registration confirmation mail; some people get a
"Receipt Number". So, the registration dialog now accepts that as well.
Fixed a bug that caused a plugin crash if my server couldn't be reached during registration.
A little boo-boo in the previous version would make it look like unregistered
versions couldn't even work for less than 10 photos after the trial period.
It would work, but told you it wouldn't. Fixed in this version.
NOTE: you may need to restart Lightroom after installing to this (or
a later) version from the previous (or an earlier) version. Please try a
restart if you get an error the first time you try to use the
As per the ongoing discussion on my blog, with this version this plugin moves over to
a "donationware" model, in which the plugin remains free, but registration eventually becomes
required (and an eventual donation hoped for ).
For details, see Lightroom Plugin
Development: Now With Added Encouragement. (For info about what
drove this decision, see What To Do When a Hobby
The plugin no longer expires, and correspondingly, I will not pay much attention to reports
of bugs that have already been fixed, so please check your version and
the version history before submitting bugs or feature requests.
There was a lot of internal upheaval in the code, so I expect that some boo-boos my
surface. If something breaks for you with this version, please let me know, but
until I fix it, feel free to revert to the
One bug fix in this release: I fixed, I think, the inability to write data to
images whose filenames
have non-ASCII characters. Working on this bug is a perfect example of why
I'm moving to a donationware model: this non-ASCII-filename situation
doesn't impact me, personally, but I spent 8+ hours today tracking down the
problem (Windows is horrid) and MacGyvering a solution. I hope it works for everyone.
More debugging for an edge-case error one user is getting.
Small housekeeping update for the new locales supported by Lightroom 2.3.
The metadata wrangler doesn't seem to work on Windows when the destination images are written to
a \\hostname share, so I now disable the export if it detects this situation. If you map the
share to a local drive letter, it should be able to work. If anyone knows why cygwin Perl can't access
a filename like "\\host\path\file.jpg", please let me know.
It turns out that the automatic upgrade stuff doesn't work if the plugin folder has been renamed from its original. That should generally not happen, but it's possible, so the plugin now checks its own location reports the issue to the user if it finds it.
Added more debugging-log stuff to the 'Upgrade Now' button action, to try to understand why it doesn't work for some people.
Added a checkbox in the Plugin Manager to turn on enhanced debugging (more stuff in the plugin's debugging log), and added a button in the same place that sends your log to me. Particularly for “the upgrade button doesn't work” and “error while uploading” type issues, this should be useful for debugging.
Updated the ExifTool install that the plugin uses to Version 7.60, which
corrects some problems that a few plugin users were seeing while working with certain Canon image files.
A message was not reporting the proper data on certain kinds of errors.
Things seem to have settled down, so pushing back the expiration for several months...
Perhaps fixed a problem whereby the "Upgrade Now" button didn't work for some Windows users. We'll see whether it works when those users upgrade from this version to whatever version is next.
No problems from the upheaval recently, so pushing back the expiration a bit.
Try#3 at this fix. Perhaps I shouldn't be programming when I have a cold....
Grrr, build problem held back the fix in .27. This should actually have the fix this time.
Fixes the Undefined subroutine &Digest::MD5::md5 error that some people are seeing.
Added some more logging to help debug the Undefined subroutine &Digest::MD5::md5 error that some people are seeing.
No new functionality in this version, but a huge upheaval in the underlying code to repair an unfortunate design choice I made early on
in the development that had limiting consequences I'd not foreseen. There are likely bugs introduced in this version, and as such, it
has a short expiration date to encourage updates as those bugs are reported and fixed. If you do run into an error, please send (via email) the log referenced in the upper-right of the Plugin Manager. Thanks.
Added "enabled" to the status line when it's enabled, just to be clear.
Attempted to address a problem that I didn't think could happen, but apparently has.
Fixed a but wherein keywords were getting flattened in some situations.
Added a bit of logging to try to track down a problem.
Fixed a situation that might have caused trouble when running two exports in tandem.
Sigh, just realized that the "check for new version" stuff did break in 2.1. Totally my fault, sorry. Fixed.
Arrrgh, my plugin build system has been broken since returning to Kyoto two weeks ago, thereby causing
new installs of this plugin to not work. Sorry! Should be fixed now.
Finally have the upgrade button working on both Win and Mac. Since I returned home last week, I now have access to both kinds of machine for the first time since LR2 was released. I can sum up the 5 hours I spent wrestling with the unzip code in three word: I hate Windows. Microsoft owes me five hours of my life back. Note that you may have to install this one by hand in order to get the newly working upgrade button... it's the next upgrade that should be easy-as-click.
Handle a race condition in the upgrade logic that sometimes results in a superfluous "You have version XYZ, but version XYZ is now available" message
Made the switch among presets a bit more efficient, and perhaps fixed a bug related to the preset name not updating in response to changes made in the various
selections when switching among Lightroom export presets. (I say perhaps because I could no longer replicate the bug I thought I was seeing, but I don't
think I changed anything that would have fixed it, so maybe there really was no bug in the first place? I dunno. In any case, it's fixed. )
A few more tweaks to report a failed upgrade attempt a bit more clearly
When upgrading, ignore a status of “50” (which means “out of
disk space”) from the unzip the plugin performs. It seems Windows often
reports this status even when there's plenty of disk space left, so until I
can understand it better, I'll just ignore that code.
Lots of little tweaks as I cleaned things up. Added a bunch of stuff to the Plugin Manager, including
a “What's New” button that shows up next to the “Upgrade Now” button when a new version is available.
Fixed infinite cycle of 'assert' messages one might get in odd situations
Moved and renamed the debugging logs to a temporary folder, and added log Show/Delete buttons to the plugin's custom section of the Plugin Manager.
Fixed the "LrShell" problem while using the one-click plugin upgrade.
Fixed the "strict.pm" error that Windows users were seeing.
An attempt to fix the "Access to undefined global: quote" bug.... we'll see.
Fruits of the debugging... should now work for more people
Added more debugging to the log file ("lr-plugin.log" in the Documents/MyDocuments folder) to help debug when things don't work.
Cosmetic change: swapped the section-heading "preserve" / "remove" buttons to match the order of the columns.