• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Stop struggling with Lightroom! There's no need to spend hours hunting for the answers to your Lightroom Classic questions. All the information you need is in Adobe Lightroom Classic - The Missing FAQ!

    To help you get started, there's a series of easy tutorials to guide you through a simple workflow. As you grow in confidence, the book switches to a conversational FAQ format, so you can quickly find answers to advanced questions. And better still, the eBooks are updated for every release, so it's always up to date.
  • Dark mode now has a single preference for the whole site! It's a simple toggle switch in the bottom right-hand corner of any page. As it uses a cookie to store your preference, you may need to dismiss the cookie banner before you can see it. Any problems, please let us know!

Is there a way for a plugin to write to another plugin's custom metadata fields?

Status
Not open for further replies.

trych

New Member
Joined
Aug 29, 2020
Messages
11
Lightroom Experience
Power User
Lightroom Version
Classic
Lightroom Version Number
Lightroom 6.14
Operating System
  1. macOS 10.13 High Sierra
Hi there,

I am new here and have been trying to write some little helper plugins for my specific workflows in managing a large archive of scanned family photos.
For this, I have created a plugin that holds a lot of custom metadata fields.

I now wanted to start writing another plugin that automatically writes to some of these fields after reading some external data. However, I did not find a way to write to another plugin's metadata. I seem to be able to read this data, via the photo:getPropertyForPlugin() method, but the photo:setPropertyForPlugin() method does not seem to let me reference another (as the the parent) plugin and thus write to its metadata.

Am I missing something here? Or is there any workaround / any other way to write to a plugin's metadata? Help would be greatly appreciated!

Thanks!
trych
 
Last edited:
Unfortunately, a plugin can't modify another plugin's custom metadata fields. If both plugins are yours, I think your only option is to merge them into a single plugin.
 
Hm, that is very unfortunate indeed and seems like a really strange omission.

I wonder, is there any other good way to fill custom metadata from external data somewhat automatically? Is there any possibilty to "map" a certain exotic EXIF or IPTC field to a metadata field? In the same way that LR's standard fields work (i.e. when LR detects that there is a creator info in the file, it automatically will show up in LR's creator field). Is something similar with custom Plugin metadata fields, so that it would autofill the field as soon as LR detects the field in the file?
 
Can you write to them via scripts instead of plugins (an option for someone in a DIY mode perhaps). Note I just saw this done and think it happened I do not script against LR myself.
 
Can you write to them via scripts instead of plugins (an option for someone in a DIY mode perhaps). Note I just saw this done and think it happened I do not script against LR myself.

No, the LR scripts are just simpler versions of the LR plugins, but use the exact same Lua SDK and therefore suffer from the same limitations as plugins. So if I cannot write to the fields via plugins, I would not be able to write to them with a script either unfortunately.
 
Is something similar with custom Plugin metadata fields, so that it would autofill the field as soon as LR detects the field in the file?
Could you give a more detailed specific example of what you want to do? I'm not quite following exactly what you want. With more details, I could suggest some approaches.
 
Could you give a more detailed specific example of what you want to do? I'm not quite following exactly what you want. With more details, I could suggest some approaches.

Sure, I'll try.
I am setting up this large archive of scanned analog photos. For this archive , in addition to the regular metadata (location, creator, keywords etc.) I need a lot of extra metadata that is very specific to my workflow (film brand, condition the films are in, boxes and locations where the films are stored etc, all in all 50+ different fields). Now I set up a custom plugin that provides all these custom metadata fields within LR and I can manage them there.
However, I have other people participating in this whole metadating / archiving / keywording process that will help me tag my files basically. For this I am planning to write a simple web frontend where the metadata can be changed and updated. Photos along with their regular and custom metadata are exported to this web interface, so people can help me tagging.

Now, once these newly added metadata comes in via the web interface, I somehow need to get them back into LR. For regular metadata I can use the LR Transporter plugin, to add them back in via .csv files. I was somehow expecting that it could also write to custom metadata fields, but it turns out, it can "only" read from those. Then I thought I would need to write my own plugin just to find out that a plugin cannot write to another plugins metadata in general.

I now realize my options would be to add all these extra functionality to my existing plugin as well, however, even the custom metadata fields I have so far are already split up in three separate plugins, as they all fulfill somewhat different purposes. So it would be rather inconvenient for me to merge this all together into one mega-plugin. However, if this is my only option, I will have to look into this.

Having said that, it would be much easier if I could – as I described in my last post – somehow map some other (usually unused) EXIF or IPTC fields to my custom metadata fields, so LR would automatically recognize and fill them once they are externally added to the photo, but it seems this is not possible?
 
If you do a search on "film exif" you will get links to several different solutions. Observing how they work may, may give you some useful ideas.
 
John Beardsworth, are you around? I thought that is what you did once for me? Script to write to a plugin's data?
Remind me. But what John Ellis said is true - only the plugin that defines the custom fields is able to change them. A single plugin is the way to go.
 
You sent me a script that was to reset the
Remind me. But what John Ellis said is true - only the plugin that defines the custom fields is able to change them. A single plugin is the way to go.
You sent me a script that was to reset the published status from the Smugmug Plugin. I had other issues, but my impression was you managed to have the script update their data? Or maybe it wasn't a field specific to the Smugmug plugin, but a generic field.
 
OK, I remember now. Adobe lets plugins/scripts update many of the properties of published plugins such as adding collections or photos, or setting a published status flag. But custom fields defined by another plugin are not writable.
 
OK, I remember now. Adobe lets plugins/scripts update many of the properties of published plugins such as adding collections or photos, or setting a published status flag. But custom fields defined by another plugin are not writable.
John,

Where are these custom fields stored? In the catalog or in some "sidecar" database? Can your ListView plug-in read these custom fields?

I'm going to go way out on a limb here. If a plug-in author is willing (and brave enough) to write directly to the catalog using sqlite commands, maybe those custom fields are writeable. But I'm just speculating wildly here, since I don't know Lua or the Lightroom SDK.

Phil Burton
 
"somehow map some other (usually unused) EXIF or IPTC fields to my custom metadata fields, so LR would automatically recognize and fill them once they are externally added to the photo"

This is possible to do with a plugin though not particularly easy.

Suppose you wanted to map IPTC:JobIdentifier to a custom metadata field F, such that whenever JobIdentifier changed, it would get automatically copied to F. The plugin would "poll" for changes to every photo, comparing JobIdentifier with F, and if they're different, copying JobIdentifier into F.

The polling could be made much more efficient by using catalog:findPhotos() to find all photos whose metadata stored in the catalog had changed in some way (metadata or develop settings) since the last time it called findPhotos(). It would use the the "touchTime" criterion, which is the same as Edit Date in the smart-collection user interface, which is the same as "lastEditTime" in photo:getRawMetadata (love the consistency in naming). If the plugin polled every 30 or 60 seconds or so (or even 15 seconds), the extra CPU utilization would be miniscule.

What I've described above compares the value of the IPTC:JobIdentifier field in the catalog as last read in by LR. LR will only read in changed metadata from a file if a user does Metadata > Read Metadata From File or a plugin calls the undocumented photo:readMetadata(). The plugin could notice when a file has changed since the last time LR read its metadata in two ways:

- periodically poll with catalog:findPhotos() using the undocumented "metadataStatus" criterion. This would be very efficient to call every 15 - 60 seconds or so, but the downside is you have to wait for LR to itself notice that a file has been modified on disk, and my casual observations in the past suggest it's pretty random in how long LR takes to notice.

- periodically poll by comparing the last-modified date of all the files with the last time the plugin polled. If the plugin did this every couple of minutes, I think the load on CPU utilization and disk access would be small.

Of course, these approaches require that the plugin have write access to the custom metadata field F, that is, that the plugin itself defines F.
 
Where are these custom fields stored? In the catalog or in some "sidecar" database? Can your ListView plug-in read these custom fields?

Entirely in the catalogue. ListView doesn't read them, but it could. However, I don't plan to update it - too old, too early in my Lua experience - but there may be a new ListView at some point. So following the rule that one plugin cannot write another's metadata, any plugin can read another's metadata although there's no guarantee that it will know what it means

I'm going to go way out on a limb here. If a plug-in author is willing (and brave enough) to write directly to the catalog using sqlite commands, maybe those custom fields are writeable. But I'm just speculating wildly here, since I don't know Lua or the Lightroom SDK.

Possible, theoretically. But writing to SQL is an undocumented method not approved by Adobe, so is it really wise to do so? And updating the data of someone else's plugin, that's not a risk? Can you imagine how livid I would be if I wasted time on a "bug" in my plugin which turned out to be the result of someone accessing the SQL? Lifting an analogy from Brexit, one would hope that any plugin author competent enough to implement the idea would be competent enough not to do so!
 
This is possible to do with a plugin though not particularly easy.

Thanks for this, quite interesting. This might be a very convenient way for me to update these custom fields.
I will look into all these options and then decide, what will best work in my current situation.

Thanks to all!
 
Possible, theoretically. But writing to SQL is an undocumented method not approved by Adobe, so is it really wise to do so? And updating the data of someone else's plugin, that's not a risk? Can you imagine how livid I would be if I wasted time on a "bug" in my plugin which turned out to be the result of someone accessing the SQL? Lifting an analogy from Brexit, one would hope that any plugin author competent enough to implement the idea would be competent enough not to do so!
The analogy is very apt here. My idea was just that, an idea.

Phil
 
Status
Not open for further replies.
Back
Top