Lightroom SDK: Support all data types in custom metadata

  • 5
  • Idea
  • Updated 4 years ago
This is my #1 feature request for the Lightroom SDK

Presently, custom metadata values do not have to be text, but they will be treated as text anyway in library filter & smart collections. There are four problems with this:

1. If plugin assigns a numeric value of 1.667 to some metadata field, as example, then if the user tries to match all fields whose value is 1.667, there won't be a match, because the filtering software is looking for "1.667" as a text string, yet the numeric data value of 1.667, does not look like the equivalent text string to the software (although it looks exactly like it to the user). To the user, it just appears flaky / broken.

2. Plugin programmers would be wise to convert all numeric / date / boolean... values to text before assigning to custom metadata fields, which is a big bummer, since once this problem is fixed, all existing metadata will need to be converted to its proper data-type, and all plugins that support metadata will need to be updated accordingly.

3. Custom metadata that really should not be textual does not behave like it would if it were native.

4. There is presently no support for constraining custom metadata numerically, or as date...
For example, there is no (good) way to find all photos whose DevMeta/Highlight-Recovery is greater than 1, since numeric comparison does not work on text strings... Likewise, there is no way to constrain ExifMeta/Last-Update to old dates only... - since dates are also handled like text...

Summary:
------------
Although I have many high hopes for Lightroom SDK, if only one thing were fixed - this one would have my vote.

Note to Adobe: If a separate Lightroom SDK sub-product type is created for this site - please move this FR/Idea there.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
  • admittedly bummed about this one...

Posted 7 years ago

  • 5
Photo of Photographe

Photographe

  • 243 Posts
  • 31 Reply Likes
Seems like a good idea to me.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
I'd rest a lot easier if this one were at least acknowledged by Adobe - I'm not sure why this isn't just fixed in the next dot release, but please please please do not let it persist into Lr4.

Note to users who don't use plugins: this won't really take away from other features - it's a small thing to fix that's a big thing for (metadata) plugin users.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
still not fixed @Lr4b
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
I hope this hole is plugged in Lr5.
Photo of Rory Hill

Rory Hill

  • 240 Posts
  • 33 Reply Likes
This is why I do not use Adobe SDKs. For example, they have a bug in the Bridge CS6 javascript implementation where you cannot use scriptui, thereby crippling virtually all bridge scripts that have a UI. This has been known for a year now and still nothing. I could go on. Who wants to sit on their thumbs for years in the hope things get fixed. Adobe simply does not support their SDKs.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
I'm not wholly disappointed with Lr's SDK. In fact, in many respects, it's quite good.

That said, it is extremely frustrating when seemingly quick-to-fix things go unfixed for so long. Aarggghhhhh....

I realize this one isn't a 5-minute fix, but I bet it could be done in a few hours - all things considered and included...

Thanks for the heads up about Bridge's SDK ;-}.

Cheers,
Rob
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 378 Reply Likes
Adobe: please add support for numerics & date/time in Lr6 - this is still my #1 feature request for the SDK.

Boolean would be nice too, but can be implemented as enum so less critical.

PS - If you can't muster what it takes for date/time, at least give us numerics - please, please, please...

Thanks for listening...
Rob