snapshot-on-export-20220120.87.zip
· FAQ
· Version History
· Update Log via RSS
· Installation instructions
· “Donationware” Registration Info
· More Lightroom Goodies
· All-Plugin Update Log via RSS
· My Photo-Tech Posts
· My Blog
This plugin for Adobe Lightroom Classic allows you to have Develop snapshots created automatically upon image export and, optionally, set image metadata like keywords.
This plugin works in Lightroom Classic, 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.
Introduction
Creating snapshots on export can be useful so that even if you later make develop/cropping changes to an image — on purpose or by accident — you'll be able to inspect (or even revert to) the as-exported state.
For example, I incorporate this plugin into the Export Preset that I use to generate photos I intend to include on my personal blog. This ensures that I can always return to the settings used to create the images that I show publicly, either to regenerate them, or to use them as a starting point for further adjustments.
Essentially, it's a form of data backup, and like other kinds of backups, it can provide a bit of peace of mind.
Note that the base snapshot-creation functionality is already included in my export plugins (for Flickr, SmugMug, Facebook, etc.), so you do not need this plugin when exporting via those plugins, unless you want the extra metadata-related functionality this plugin supplies.
This plugin is useful for exports to local disk, or those using any of the many other export plugins available for Lightroom, most of which can be found on Adobe's Lightroom Exchange web site.
Overview
If you're not familiar with Lightroom's Develop snapshots, they're available via a section in the left side of the Develop Module. This screenshot highlights the Snapshots section, with one snapshot named ”Exported for blog 2010-01-24 23:20:13“ already created...
If you don't see the panels in your Develop module, tap the tab key. If you don't see the “Snapshots” section, right-click on any of the section titles and be sure “Snapshots” is enabled.
When you create a Develop snapshot — with a plugin, or by hand by clicking on the “+” in the section header just above the purple arrow in the screenshot above — you are creating a named record of all the various settings used by Lightroom to convert from your original master “negative” image to the version you have in the Develop module now, including any crop, white-balance settings, sharpening and grain, locally-painted corrections, exposure adjustments, etc. etc. etc.
Note that a Develop snapshot does not include Library-module metadata, such as the caption, keywords, a geoencoded location, etc. To save those as well, you'll want to create a virtual copy (which at the moment can not be done by a plugin).
Lower-left corner of
the Export Dialog
Installation
First, download the plugin using the link in the upper-right corner of this page, and unzip it to a location on disk where you'll keep it.
Then follow the normal Lightroom plugin install instructions to install and enable the plugin in your copy of Lightroom.
Then, start an export to bring up the Export Dialog, or with Publish, bring up the Publishing Manager. In either case, note the “Post-Process Actions” section in the lower-right of the dialog, as highlighted by the red arrow in the image at right. “Post-Process Actions” are Adobe's name for what normal users might call “Export Filters”... the most popular of which are likely my Metadata Wrangler (for selectively stripping embedded metadata from exported images, for privacy) and Tim Armes' LR2/Mogrify watermarking-and-more plugin.
Highlight the lower “Snapshot on Export” (the red arrow) and click the “Insert” button (the yellow arrow) to add the plugin to your export. The export dialog will now contain a “Snapshot on Export” section.
Configuring Automatic Snapshots
After installing and enabling the plugin, then adding the plugin's “Post-Process Action” as described above, your export dialog will contain a section like this:
(The “extra metadata” functionality, in the section marked with a red line above, is discussed below.)
The green arrow highlights where to enter the title you want for automatic snapshots. You can use the many template tokens supported by my plugins to make a snapshot-name pattern for use in computing the title as each snapshot is created, as I did in the screenshot above, but you can also just enter a name, such as “Latest Export”.
If it turns out that there's already a Develop snapshot with that name, it will normally be updated in place (that is, overwritten), but you can have the plugin come up with a unique name if you like; the plugin will append the date and time to the name you've chosen.
When a photo has multiple Develop snapshots, they are listed in alphabetical order (which surprised me; I would have thought they would be listed in chronological order), so the default snapshot-name pattern,
Export at {yyyy}-{mm}-{dd} {hh}:{min}:{ss}
includes the date and time in such a way that an alphabetical sort is the same as a chronological sort. You're free, of course, to choose any naming pattern you like.
Two Important Snapshot-Related Warnings
- Develop snapshots are shared among a master image and all its virtual copies
(See this presentation if you're not familiar with Lightroom's virtual-copy feature.)A great feature of virtual copies is that they are mutually independent, but they do share one common snapshot list. It's important to remember this when naming snapshots because unless the name somehow indicates which copy it's from, you have only your memory to rely on... something that is, at least in my case, unreliable.
Personally, I tend to create a virtual copy when I need two different crops of the same picture for my blog (such as the first two photos on this post about my nephew), or when I want to do some extreme processing (such as this, these, this, or these).
To ensure that each Develop snapshot is named such that I can tell which copy it belongs to, I enable the copy-name prefix option, as highlighted by the blue arrow in the Export-Dialog screenshot above. “Copy name” is a bit of metadata about each image in Lightroom's library: it's originally empty for master images, and “Copy 1”, “Copy 2”, etc., for virtual images, but you can change any of them as you like (I tend to use short descriptive phrases like “original”, “crop”, “edgy”, “B&W”,....). Prepending the copy name to the Develop snapshot helps one keep things straight.
- Develop snapshots created automatically are made after an image has exported
The develop settings used in rendering the images in any one export session are locked in at the moment the export is launched, but develop settings recorded in each snapshot are not locked in for a particular image until after it has actually rendered.
This means that if you launch a big export with many photos, then continue editing the same photos as the export progresses in the background, develop changes you make to an image before it's exported will be encapsulated in the automatic Develop preset this plugin creates, but will not actually be reflected in the exported copy. So, to avoid this kind of develop-setting skew, avoid editing images as they export.
Extra Metadata
The plugin also allows you to set some image metadata for the image selected for export. You can set:
- its color label (red, yellow, green, ...)
- its image flag (“pick”, “unflagged”, or “rejected”)
- set or clear a keyword.
If the image selected for export is a virtual copy, you can independently set metadata for its master image.
And finally, if you import the exported copy back into Lightroom as its own image, you can set the metadata for that as well.
As Part of an Export Preset
Export Presets are a great way to make common exports easy, allowing you to encapsulate all the settings for a particular need into one simple preset that can be selected in the Export Dialog (see its upper-left area), or launched directly via the File > Export with Preset menu. If you have export presets that you'd like to update to include this snapshot-on-export functionality, follow these steps:
Bring up the Export Dialog.
Click on the name of the Export Preset in question (in the upper-left of the Export Dialog).
Add the plugin's Post-Process Action to the export, as illustrated with the red and yellow arrows earlier in this post.
Configure the snapshot-on-export settings as you like.
Right-click on the name of the Export Preset, to bring up a context menu, then select “Update with Current Settings”.
(Now that the Export Preset has been updated, you can dismiss the Export Dialog.)
Availability
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.
Version History
(
Update Log via RSS
)
20220120.87 |
Added the WEEKNUM token, along with DAYNUM, weeknum, and daynum. Whack-a-mole with PayPal's random changes. |
20211219.86 |
Warn when PayPal seems to have given a bogus code in the web-confirmation page. Fixed that the Province template token did not respect the plugin-specific geo-privacy settings. Fixed an issue with the {Newline} token, and added {Comma}, {Hyphen}, and {Space} for good measure. Fixed a problem with filters on the {Keyword} token. |
20210415.85 |
Reworked the Keywords token to better accept filters. Added 'separated by' to the People token. |
20201224.84 |
More debug logging to try to track down a problem. Added the ImageViewDirection and ImageViewBearing tokens. Working around 'constant table overflow' error. |
20201103.83 |
Added the PF filter to turn typographic fractions into plain-ASCII fractions. |
20201017.82 |
Updates for Lr10 Added the SpeedKnots token. Worked around an "unknown key captureTime" error. Added the {PlusCode} and {GeoHash} tokens. Work around a Windows bug related to canceling out of the registration dialog. Some of the filename-related tokens could be incorrect in rare situations. |
20191216.81 |
Added some extra debug logging to track down a problem. Added some extra debug logging to note whether the plugin is enabled. |
20191011.80 |
Added the LensInfo template token. Updated the Exposure token to allow customization. More token work: added {Urls}, and updated {ISO} and {Copyright} to allow customization. Added the {RelativeFolder} token. |
20190810.79 |
Fixed the SST1 and SST2 tokens. |
20190731.78 |
Updated the PublishCollectionName token (and CollectionNames and CollectionFullNames) to remove the MIRROR: prefix from the name that mirrored collections within my Collection Publisher plugin automatically get. |
20190708.77 |
Added the PEOPLE variable to the LUA token. Fixed a problem with the SpeedKPH token. Added TempC and TempF to the template tokens that my plugins understand. Added the TempC and TempF tokens. Updated the keyword-related tokens to accept standard filters. Work around a bug that sometimes causes plugins to be disabled when starting Lightroom via clicking on a catalog file. Fix an "Unknown key: captureTime" crash. Added the GPSCoords token. Fixed a problem related to template tokens and photos without capture times. Added functions uc(), ucFirst(), lc(), and lcFirst() to the LUA token. |
20181015.76 |
Updates for Lr8 (Lightroom Classic CC Version 8). Added the special PP() function to the {LUA} token. Added hierarchical options to the Keywords token. Try to work around a Lightroom bug related to photo timezones and how Lightroom handles accessing plugin data. |
20181004.75 |
Added the 'nicknames' modifier to the {People} token. Added the SST1, SST2, and SS3 tokens to the template tokens that the plugin understands. |
20180906.74 |
Try to avoid having unexpectedly-long error messages create too-big a dialog. |
20180606.73 |
Fixed a bug when 'Token Examples' invoked in certain situations. Clicking on the version number in the Plugin Manager now copies version info to the clipboard Updated the PublishCollectionName token to allow numeric arguments along the lines of the CollectionName token. Added the folowing template tokens: {home}, {desktop}, {temp}, {pictures}, {documents}, IptcDateTaken Added the 'PCH' variable to the {LUA} tag. Added a bunch of token filters: F2D F2S F2X B2D B2S B2X S2X A2D A2S A2X |
20171229.72 |
Updates to the data templates that my plugins understand: updated the Keywords token, added CollectionNames and CollectionFullNames tokens, and added a bunch of stuff (KWf, CN, CFN, CNf, CFNf) to the {LUA} token. |
20171019.71 |
Oops, more Lr7 stuff. |
20171019.70 |
Updates for Lr7. Better handle some character-encoding issues related to template tokens. Allow the "If Exists" feature of Templat Tokens to work with the PluginProperty token. Update registration support to handle a stupid bug at PayPal that PayPal refuses to fix )-: |
20170710.69 |
Fixed a bug introuded the other day in template tokens, related to Windows filenames. |
20170621.68 |
Added the Newline template token. Enhanced the FolderName token Added the "only if it has a value" feature to template tokens. |
20170309.67 |
Switch the log-sending mechanism to https. Added the following tokens to the template tokens that my plugins understand: Artworks, ArtworkTitle, ArtworkCopyright, ArtworkSource, ArtworkCreator, ArtworkDateCreated, ArtworkInventoryNum, ISO8601Date |
20161212.66 |
Made even the create-snapshot part optional. Added the following tokens to the templates that my plugins understand: FileModYYYY, FileModYY, FileModMM, FileModDD, FileModHH, FileModMIN, FileModSS, FileYYYY, FileYY, FileMM, FileDD, FileHH, FileMIN, FileSS, Weekday, Wday, weekday, p wday, FilenameNumber. Fixed a bug with the keyword tables in the LUA token. |
20160510.65 |
Try to get better dialog spacing on large screens. Added Russian-langauge support for the People-Support |
20160207.64 |
Added {SpeedKPH} and {SpeedMPH} to the list of template tokens supported by my plugins. The {People} token wasn't working properly for some keywords without a registered birthday. Added ChildOf and DescendantOf filters to the {Keywords} and {KeywordsAll} tokens. Fixed how custom {People} formatting works with people keywords that have no birthday associated with them. Try to avoid yet another place where Lightroom gets hung because it can't handle certain kinds of dialogs at the same time. |
20150528.63 | Add some extra debug logging to try to track down a rare transient error. |
20150517.62 |
Fixed the "SpecPeople:259: attemt to index al nil value" error. |
20150205.61 |
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. |
20150131.60 |
Fix to the date_diff() function supported by the LUA template token. Updated the camera-name code to try to guess the actual camera model of Hasselblad H5D files, since in their infinite wisdom Hasselblad decided to encode three distinct models with the same internal code, making it impossible to know for sure what camera produced a given image file. |
20141229.59 | For the keyword stuff, try to find the keyword via name if not found via internal identifier. |
20141019.58 | Windows Only: Add a one-time check for the POODLE security vulnerability, and alert the user if it exists. |
20140923.57 | Added the LrMD5, LrLocalization, LrSystemInfo, and LrMath packages to the {LUA} template token. |
20140902.56 | New build system |
20140802.55 |
Made the {GPSAltitude}, {Altitude}, and {GPSCoordinates} tokens subject to the geo-privacy settings like the other geo-related tokens. |
20140731.54 | Registration fix for Lr5.6 |
20140720.53 | More Creative-Cloud support. |
20140715.52 |
Fixed an issue with Creative-Cloud revalidation. |
20140712.51 |
Lr5.5 and later Creative-Cloud installs can now revalidate themselves if needed. |
20140710.50 | Sigh, had a bug in the Creative-Cloud support. |
20140708.49 |
Now supports Lr5.5+ Creative-Cloud Installs. |
20140704.48 | Sigh, introduced an error for some folks with the rebuild the other day. |
20140630.47 | Build-system update |
20140613.46 |
Added date_diff() and raw_time_diff() functions to the special {LUA} token understood by the plugin. |
20140509.45 |
Added new tokens to the template language the plugin understands: LrVersion, LrVersionMajor, LrVersionMinor, LrVersionRevision, LrVersionBuild, Location, CatalogName, CatalogPath, OperatingSystem, OS Added new token filters: NS and LO |
20140423.44 | Fix a location-related template-token bug introduced in a recent build. |
20140422.43 |
Fixed a bug in the "smoother revalidation" stuff recently added. |
20140417.42 |
The {Empty} template token wasn't working properly. Make the revalidation process smoother, especially for folks using Lr5.4 and later. |
20130926.41 | Oops, fix a bug introduced in the previous update |
20130925.40 |
Added a bunch of tokens to the preset templates supported: ExportFormat, ExportColorSpace, ExportBitDepth, ExportQuality, ExportSharpeningLevel, ExportSharpeningMedia, IpernityUrl, GoogleDriveUrl, and TumblrUrl. The token-examples dialog had been broken. Also deprecated Folder and Path tokens in preference to FolderName and FolderPath tokens. |
20130820.39 |
Added the ability to set the flag (pick/reject) for the image and/or its master. When importing the exported copy back into Lightroom, added the ability to set its metadata. Fixed the KW/KWE tables in template tokens; they had been broken when using load for the script. |
20130704.37 | Enhanced the keyword processing to allow keyword removal. |
20130613.36 | Better support for plugin revalidation. |
20130611.35 | Yet another Lr5 update |
20130610.34 | Final update for Lr5 |
20130501.33 | Update for Lr5 |
20130412.32 | Keyword filter to help with huge keyword lists. |
20130328.31 | Fix for the registration system. |
20130220.30 |
Added support for some new template tokens: FlagStatus (requires Lr4.1 or later), and for Lr3 and later, a bunch of IPTC extended metadata: AdditionalModelInfo, CodeOfOrgShown, DigImageGUID, Event, ImageSupplierImageId, MinorModelAge, ModelAge, ModelReleaseID, ModelReleaseStatus, NameOfOrgShown, PersonShown, PlusVersion, PropertyReleaseID, PropertyReleaseStatus, and SourceType. |
20130210.29 | Fix translations related to label colors. |
20130210.28 | Add the ability to set the color/keyword for the master image of an exported virtual copy. |
20130209.27 | More build-system maintenance |
20130206.26 | Tweak for my registration system |
20121029.24 |
Added some debug logging to track down a problem with keywords. Enhance the {EMPTY} template token so that it interrupts the squelching of superfluous joining characters. |
20121003.23 |
Added the ability for the plugin to set a color label and keywords when creating a snapshot. Updates to the environment in the {LUA} token (in the template tokens in my plugins) to include photoTime() and currentTime(), and other changes to match the updated docs at that link. . |
20120608.22 | Fix an "attempt to perform arithmetic on field" error. |
20120526.21 |
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. Added to the template tokens supported by the plugin: {FullMasterFile}, {FullMasterFolder}, {FullExportedFile}, and {FullExportedFolder}. |
20120330.20 | Update to handle 4.1RC |
20120309.19 | Update to the debug logging to better track down timing issues that might arise. |
20120304.18 |
More on the march toward Lr4, including upheaval in the code to handle Lightroom APIs being discontinued in Lr4. Added the {AspectRatio} token to the token templates understood by the plugin, and added the Length=num filter. |
20120114.17 | More tweaks for Lr4b |
20120112.16 |
Update for Lr4 beta: explain in the plugin manager that the plugin can't be registered in the beta. |
20111210.15 |
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. |
20110703.14 | It seems there's a bug with Lightroom that causes this plugin to crash under certain multi-export circumstances. This build includes something to reduce the chance of hitting the problem. |
20110113.13 | Added {CroppedWidth} and {CroppedHeight} to the template tokens used by my plugins. |
20100829.12 | Made the revalidation process much simpler, doing away with the silly need for a revalidation file. |
20100820.11 |
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. |
20100817.10 |
Added code to allow plugin revalidation after having been locked due to a bad Lightroom serial number. |
20100707.9 | Oops, left in the plugin expiration that was supposed to be only for the Lr3 beta. Sorry about that... this has no expiration. |
20100625.8 | Yikes, shaking out some more build issues. |
20100624.7 | Discovered a nasty build bug; pushing a new version in case it affects this plugin. |
20100608.6 |
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. |
20100516.5 | Update for the Lr3 beta. |
20100411.4 | Yikes, turns out that unchecking the "enabled" checkbox in the export dialog actually caused the whole export to become disabled, not just this plugin. Fixed. |
20100327.3 | Hahahaha, I'd gone to so much trouble to create the "prepend copy name" stuff (it was a lot more work to implement in the export dialog than you might imagine, given how little a thing it seems), but I forgot to actually *use* it during the actual export when creating the snapshot name. Doh! |
20100323.1 | Initial release |
This is THE feature I’ve been wishing LR had for years. Jeffrey, you’re a genius! Can’t wait to start getting my chops round LR3 now.
Hi Jeffrey – Thanks for your excellent plugins! I’ve tried searching for an answer to this question, but no luck.
When I used the LR Export-To-SmugMug plugin, it does not seem to properly handle the Virtual Copies created in lightroom. If I have one original and say, one or two virtual copies, upon export the plugin will not rename them with the “-1” or “-2” at the end of the filename. This causes the last virtual copy to replace the previous file on smugmug (assuming I have the replace option enabled) even if its not the same file. If I use LR’s export to file feature, it will rename each virtual upon export with the appropriate “-1” “-2” etc.
Am I doing something wrong, or is this a known issue?
Thanks!
I’m a little confused about whether you’re referring to a problem with snapshots in the local Lr catalog, filenames created during the export, or with uploads to SmugMug? As for snapshots, they are shared among all virtual copies and their master, so they will indeed overwrite each other if not named separately (e.g. by using the copy name). As for the file names, the Export-to-SumgMug export dialog has the same File Naming and Export Location settings as the standard export dialog, so check your settings to ensure that “overwrite” is off. But whether the filenames are the same or different doesn’t matter to SmugMug or the plugin, and each upload is treated as its own image at SM. —Jeffrey
This feature is genius! IMO this – and a lot of your creations – should be included in LR by default, this especially so.
I’m still on 2.7 as 3B1/2 are dog slow for me sadly. Still, if it’s up to 2.7 speed upon final launch I’ll be using this a lot!
Thanks for your hard work on these extensions, they really make LR what it is – or should be!
Is there a possibility that this same plugin could add to some searchable metadata field the export preset name or some keywords? This way i could track back these images.
It took a while, but I’ve finally added this as of version .23. —Jeffrey
Hi Jeffrey! Is there a way to get the same functionality in printing a photo? ie, ‘Snapshot on Print’
No, as far as I know there’s no plugin access to anything in Print. —Jeffrey
Hi Jeffrey, wonderful plugin, thanks very much!
But there’s one more thing I’d really love to see: The ability for this plugin to add a keyword to an image upon export. Say I export an image for my blog, then it’d be great for the plugin to add “exported_to_blog” as keyword to the image. That way, I can later on conveniently search for all images that I have exported to my blog at some stage…
Thanks again,
Florian
It took a while, but I’ve finally added this as of version .23. —Jeffrey
Hi, greetings from Finland.
Just installed your plug-in to export photos from LR to photo bucket. I keep getting a error message: Debug:1205: networkConnectionLost.
After exporting some 15-20 frames, the message appears. Any idea what I can do?
Best Regards,
Timo
Sounds like your network connection is flaky… not much the plugin can do but report errors when it encounters them. —Jeffrey
Hi Jeffrey,
I’ve been a user of your plugin for quite a while! Just recently, however, I keep encountering an error when uploading my photographs to facebook. It will upload like 4 photos then get an error message.
The error specifically says: “Debug:1205: Error reply from Facebook: Unsupported get request”
Any ideas on how to fix it? I don’t believe it’s a network issue because my internet works great at home. But then again, you’re the expert. Hope to hear from you soon!
This is a bug at FB that tickles only a few people. Welcome to the club! )-: I’ve reported it with details, so they should have enough info to fix it if they want. We’ll see. —Jeffrey
hey Jeffrey,
Thanks for the plugin.
Is there a way to auto export. I.e i have the LR watch a folder and auto import the images, apply a preset grade and then i want LR to auto export any new images without a user having to click. a fully automated lightroom export function.
The use is to be on site taking photo’s, these images get sent to the pc through a few different option, tethers, wireless whatever. Then LR imports the watched folder (or directly if using lightroom tethered shooting) applies preset and exports to a folder to be printed or watched by another software.
Would love some help, cant seem to find much info on the web.
thanks ,
stu
You can definitely do this if you write your own plugin, but I don’t know of any plugin that does the export part. —Jeffrey
Thanks again (from French Riviera) for the recent addition of the keyword set in this plug-in.
I’ve been using this plug-in (with many of your other magic plug-in) for a while as it is a great way to keep track of export.
Now, I wanted to set a keyword to be able on some key export, to use your Safe plug-in to detect automatically (smart collec) that these picture need to be protected.
I’m using it for the feature to set it on a virtual copy (for which I do not see other mean to do it)
However, I’m completing it by a use of run any command plug-in as I want in that case to tag with the same keyword, not only the worked picture (could be a tif from PS) but also my original NEF stored in the same folder (stacked with it) hence the command
“F:\_exiftool_for run-any-command\exiftool.exe” -overwrite_original -keywords+=”Portfolio” “{Path}\{LIBRARYFILENAME:Length=14}*.tif” “{Path}\{LIBRARYFILENAME:Length=14}*.xmp” “{Path}\{LIBRARYFILENAME:Length=14}*.jpg”
It could be useful (even though it makes thing more complex) to be able to set a filename filter with tokens that would allow to set the keyword not only to the virtual copy but optionally on all copy of the same original and even some file with other extension
Updating the metadata for the master image files outside of Lightroom puts it in conflict with Lightroom, so this seems dangerous…. a good way to lose data, I’d think. Anyway, I just pushed a new version with this new featured added. 😉 —Jeffrey
I also noticed a small display bug (using release 20130201.25) on the Set Image Color label.
All radio button have the same label. Which seems to be using the localized version of LR as it shows in French in my version (all label says Red in French)
Maybe because I defined a text for all these label in LR ?
Not a big deal anyhow 🙂
Thanks for the heads up… I’ve pushed a version that fixes it. —Jeffrey
Hi Jeffrey,
Writing to you from just outside of Rochester, NY. Just wanted to say thanks for the great plugin! It was something I was looking for a couple of years ago when I found this plugin. Now its a critical part of my workflow and I use it in ways that I hadn’t originally intended. I really appreciate your hard work on this and your other plugins (I purchased Metadata Wrangler too)!
Tom
Hi Jeffrey, I’m using this plugin with the “Hard Drive” publish service. (I am putting a “signature” watermark at the bottom of all my images before I upload them to Smugmug, where I add another “proof” watermark to the images – that way they are displayed in my gallery with “proof” stamped on them, to discourage screen captures, but when they are purchased, they only have my signature on them)
The problem is this: I think since the snapshot is taken following the publish of each photo, all the photos get marked as “modified photo to re-publish” immediately after they are published. The fix I’ve used is to simply mark all of them as up-to-date after the publish is completed. Is there something you can do to to include that?
I don’t think the “modified..” thing is related to this plugin because I occasionally see it in vanilla publish services. I think Lightroom is just flaky in this regard. —Jeffrey
Hi Jeffrey. I just reported a similar issue with another plugin. I’m pretty sure that Adobe introduced a feature in Lightroom 5.3 that is causing problems for some of your plugins.
I see the issue when I use the “If the copy created for export is then imported back into the catalog” feature of your “snapshot on export” plugin.
My export process is that I first export a file from LR and then I call a Photoshop droplet to further process the file.
In LR 5.2 and earlier, I could use your plugin to set a keyword in the exported file, and then the keyword would be carried through the Photoshop processing. But now, in LR 5.3, it appears that the Photoshop droplet is being called before the keyword is added to the file, so it doesn’t show up in the final file. So what I see is that after the export process, the keyword is in the intermediate file (the one exported from Lightroom) but not in the final file (the intermediate file after Photoshop processing).
I suspect a timing issue, because I find that if I quit Photoshop before calling the export script, the time it takes for Photoshop to launch is enough to fix the problem. Lightroom creates the export file, then launches Photoshop, then writes the metadata, but Photoshop launches slowly enough that the metadata is there by the time Photoshop is ready.
I’m not sure what to do other than report this to you. There are easy work-arounds for my problem, but it appears that one of your plug-in’s features is less useful now than it was in the past.
Best wishes.
Alan
How do you invoke the Photoshop droplet? The way Lightroom works, the snapshot-on-export thing is invoked and completed before Lightroom moves on down the export stack, so there should be no race conditions here. Perhaps send more info via a snapshot-on-export log? —Jeffrey
Hi Jeffery,
I’m using a couple of your excellent plugins but have come across a problem since installing LR5.5 . It’s now a fully CC version, was previously standalone even though I’ve been in CC for a year.
Anyway the plugin has become deregistered as expected but there in no registration button. There is a small block of text saying that the button will be visible once LR is registered with Adobe. As far as I know it is registered with Adobe – I used the CC app to install it so it must be.
I’ve tried deleting the plist but that gets recreated – including the plugin sections. Creative Cloud must be caching the details of the plist somewhere.
Any suggestions?
Cheers,
Paul
Unfortunately, this is a known problem as of yet without a known solution. I’ve just created this FAQ about it. —Jeffrey
Hi Jeffrey,
thanks for your great plugin. I’d have a little feature request if you don’t mind. Using multiple Catalogues, I have an export preset using “Snapshot on Export”, adding a certain keyword for exported images. When switching between catalogues, the plugin doesn’t work well, claiming there is “no keyword chosen” (the keyword exists in both catalogues!). The keyword became deselected after the Catalogue switch.
I assume this may have to do with the way you are storing the selected keyword (using some kind of internal keyword ID rather than the actual keyword string). Would there be a way for the plugin to work cross-catalogues?
Cheers and keep up the good work,
Florian
I hadn’t thought of that. Yes, the keyword is remembered via internal catalog ID. I’ve just pushed a version that will try to find the keyword via name (if there’s only one keyword with that name) if not found via ID. This means it’ll work for any catalog that has the keyword and not just ones you’ve already linked the keyword to. Thanks for the idea. —Jeffrey
When can we expect an update for LR CC? Keep up the great work!
Modern versions of the plugin should already work. —Jeffrey
Hi Jeffrey, wonderful plugin (Snapshot on export) I am using it with smart collections that are set up for publishing exports (dropbox, smugmug, copy, flickr, 500px and LRGallery). in the smart collection (one for each service) I use the keyword as above plus I use the rating flags (one star = 500px, 2 stars = copy, 3 stars = dropbox etc). So when I publish the collection they then clear themselves)
Could I suggest that the selection/clearing of rating flags be included in the plugin to make it more automatic? I am also sure if this was possible the plugin would become very versatile indeed.
cheers and thanks for some wonderful tools.
MB
Hi Jeffrey,
Many thanks for this wonderful plugin. There’s only one issue I have with my new 4K monitor (set to 150%): The input box “Filter display by” is too small on my screen. All other input fields have a correct size, only “Filter display by” is too small (I can only enter one letter in the box).
Can you have a look at this?
Thomas
Would you mind sending a screenshot? Thanks. —Jeffrey
I wish there’s a plugin to export all snapshots of a photo to jpeg with 1 click
That’d be nice, but Lightroom doesn’t give plugins any access to snapshots, other than the ability to create one. —Jeffrey
Not sure if this plugin can do this, but perhaps you know of a way: My client often refers to selects from a group files I export based on the name of the exported file ( different from the image filename). If there were a way to capture that name in metadata upon export, finding it when they send me a select would be MUCH easier. thoughts?
In theory a plugin can note the name of the file as known to Lightroom at the time the plugin is invoked during the export stack, but the final export handler (e.g. a publish plugin) can change the name further, and it’d be up to that plugin to save the exported filename somewhere. So without coordination among all plugin publishers (or Adobe), it’d be a haphazard solution. One idea would be to write the name for export to a metadata field prior to export (e.g. the Job Identifier field, for example), then use that field for the filename during actual export. Then you can search in the metadata field for the name as reported by the client. My “folder publisher” and “collection publisher” plugins have an extended renaming feature that can tap into the other metadata field for the filename, and my “extended search” plugin can accept a cut-n-pasted list of filenames (from the client) and search in that field to isolate the ones that match. —Jeffrey
This is awesome. Right now I’m using the adobe renaming feature to pull the name of the subject from the “Title” field and add on my initials and the number from the initial file. In the scenario above, what tool would I used to create this client-mandated naming scheme before getting it written to the metadata via your “write data field” tool? BTW, is that a plugin in itself or is it part of another plugin? Thanks so much for the help!
“Write data field” is part of my Bag-o-Goodies plugin. FWIW, you can do the renaming during export without the need for the intermediate step with my Collection Publisher plugin or my Folder Publisher plugin, which include advance-renaming features. —Jeffrey
Hi Jeffrey, I came across your “Snapshot on Export” plugin, via a blog link by The Creative Photographer, Andrew S. Gibson, who is also a top notch bloke in his own right. I will certainly be giving it a go after reading all the positive remarks, and as importantly, your honest unbiased response to any problems encountered. I have no doubt you are a genuine, helpful and sincere person deserving all the plaudits and recognition for your hard work. I thank you in advance of downloading the Plugin.
Ian. Scotland. United Kingdom.
Hi Jeffrey,
Long time user of your plugins 🙂
When I export to Zenfolio with the Snapshot on export plugin, I often getba bunch of errors like these:
LrPhoto:addSnapshot: must be called from within a withWriteAccessDo block
and
?:0: attempt to index field ‘createDevelopSnapshot’ (a nil value)
Sometimes, the export continues after ack the messsage, sometimes it aborts. Sometimes it happens after every single photo, sometimes it happens after some dozens photos were exported…
Any idea what’s happening?
JF
This seems to be some kind of new bug with Lr9. I’ve gotten one other (very complete) report about it with another plugin, and I can’t see the cause other than anything but a bug in Lightroom. I’ll tell Adobe about it, but otherwise I don’t think there’s anything we can do other than to avoid things that trigger the bug, e.g., avoid the snapshot-creation features of my plugins. —Jeffrey
I’m sure you’re aware, but if not, this plugin doesn’t work on LR 10.0.
Sorry about the delay… I pushed out new versions a few hours after Lr10 was announced. —Jeffrey
Hi Jeffrey, I’m using Snapshot on Export–great plug-in idea–with Lightroom Classic ver. 10.3. When I complete the info form for Export and click on export, the photo exports, and a snapshot with the correct designations appears in the left hand panel in Lightroom. The problem I’m having is that the next time I return to the catalog folder from which I exported, there are no snapshots to be found. This disappearing act happens even without closing and restarting LR. The snapshot is listed for about 8 hours, then goes away from the Snapshot list. I’ve looked through LR Preferences to see if I’m missing a setting and cannot find anything that looks like it would correct the problem. Any thoughts on what might be causing this to happen? Thanks very much.
I can only imagine catalog corruption or user error, and both of those are difficult to imagine here. Perhaps make a catalog backup just after creating the snapshot, then again just after noticing the snapshot is missing. Once you have both those backup .LRCAT files, perhaps they can be investigated for clues…. —Jeffrey
Hi Jeffrey,
thank you for your work.
Are you aware of the following bug? If I export photos with your snapshot plugin and at the same time click the “Add to this catalog” option, it breaks off after a few photos and shows the error “LrPhoto:addSnapshot: must be called from within a withWriteAccessDo block”. Do you have a solution for that?
Thanks,
Dominic
Sadly, this seems to be a bug in Lightroom. I could repeat it, but the code is definitely calling from within a withWriteAccessDo block. Sigh. The way Adobe designed catalog-update access, there’s really no way for a plugin to ensure it works…. the best it can do is cross its fingers and try and hope. But this error is simply wrong. Sigh. I can’t think of any workaround. Sigh. —Jeffrey