Photo Mechanic Plus > Feature Requests

OR variables during ingest

(1/3) > >>

ejhutch:
Hi,
Is it possible to OR variables when Ingesting (or whenever applying variables to metadata) depending on whether they are defined?

I'd like to set up a general ingest task that ingests images into folders based on the {artist} OR {id} OR {owner} OR {user} OR {comment} variables depending on which one is defined in the metadata of the image to be ingested.

From the Variables Window:
{artist} - TIFF Artist field written by some cameras.
{id} - Either {owner} (Canon) or {comment} (Nikon).
{owner} - Camera's owner (if defined; same as {user}).
{user} - Camera's user (if defined; same as {owner}).
{comment} - The comment (written by some cameras).

Can I do something like include {artist|id|owner|user|comment} in the Folder Name field in the ingest dialog window? The result would expand to whichever variable was able to be resolved first.

Thanks.
Ed

Kirk Baker:
Ed,


--- Quote from: ejhutch on November 24, 2021, 05:31:12 AM ---Is it possible to OR variables when Ingesting (or whenever applying variables to metadata) depending on whether they are defined?

I'd like to set up a general ingest task that ingests images into folders based on the {artist} OR {id} OR {owner} OR {user} OR {comment} variables depending on which one is defined in the metadata of the image to be ingested.

From the Variables Window:
{artist} - TIFF Artist field written by some cameras.
{id} - Either {owner} (Canon) or {comment} (Nikon).
{owner} - Camera's owner (if defined; same as {user}).
{user} - Camera's user (if defined; same as {owner}).
{comment} - The comment (written by some cameras).

Can I do something like include {artist|id|owner|user|comment} in the Folder Name field in the ingest dialog window? The result would expand to whichever variable was able to be resolved first.
--- End quote ---

No, there's no such feature, but I think it's a good idea.  I'll move this to the Feature Requests board.

-Kirk

ejhutch:
Would you want to kill me then for asking for full regular expression pattern matching support (Such as PCREs) when expanding variables? Because I am. Thanks!
Ed

Kirk Baker:
Ed,


--- Quote from: ejhutch on November 25, 2021, 02:36:02 PM ---Would you want to kill me then for asking for full regular expression pattern matching support (Such as PCREs) when expanding variables? Because I am. Thanks!
--- End quote ---

I'm not against such a thing (we already have an engine in PM for this) but what would the syntax look like?

-Kirk

ejhutch:
That... is a good question. And probably a long discussion as well. I'll have to work on some possible examples and use cases and get back to you. I know I've done stuff like this in various scripting and macro languages. So any examples I provide are more about what to do, rather then about how (syntax, etc) to do it.

I have a love/hate relationship with regular expressions.

 I can say that the first case that got me thinking about it was the way PM Plus works with variables and path names.

You've currently got {filename}, {folder}, {folderpath}, {path}, and {parentfolderpath} variables.

And I know we can use regexes in searching the catalog.  However, when exploring variable substitution, I found the current implementation a bit limiting for what I wanted to do, especially considering that substring extraction and translation are limited to fixed, defined lengths from the starting to ending character positions.

I had a copy/move case where I wanted to extract and utilize more levels of the full path than just up to the parent folder, and realized it would be pretty easy if the variable substring extraction capabilities were expanded to be able to search for say /an/arbitrarily/long/pathname/to/a/photo.jpg and implement something like  {folderpath:pathindexstart,pathindexend,pathdelimiter} such as {folderpath:1,/} for an (starting at the beginning of the folder path), or {folder path:-1,/} for the parent a (starting at the end and counting backwards), or even something like {folderpath:-1,-5,/} for arbitrarily/long/pathname/to/a (which could also be {folderpath:2,6,/}, or even other variations like {folderpath:,6,/} (the first six folders in the path starting at the beginning) or {folderpath:,-6,/} (the last 6 folders in the path). Of course, there are many ways to accomplish, this, and keep the scope limited, but I can also see incredibly powerful utility in broadly supporting a more complete implementation of regular expression pattern matching, grouping, search-and-replacing, etc. for variable substring manipulation.

However, I realize you've got limited resources, and regexes can get pretty complex quickly, and I'm not sure how much capability 80% of your user base would be able to make use of. You'd know that better than I.

What are your thoughts?

Navigation

[0] Message Index

[#] Next page