Author Topic: Treat Code Replacement as Variable sometimes  (Read 3353 times)

Offline ajmast

  • Newcomer
  • *
  • Posts: 48
    • View Profile
Treat Code Replacement as Variable sometimes
« on: April 04, 2015, 04:42:22 AM »
So here is the situation, I have some information (Caption, Keywords, etc...) that is going to change every day. I need this information to be in multiple IPTC snapshots (perhaps even across multiple computers).

So I put it in a code replacement file (and put that file in Dropbox or on a network accessible drive).

At present in order for that information to be updated with each ingest, I go put the code replacement Key in an unused job variable, then reference that in my ingest IPTC Stationary.
Example: in job usercustom1 I put the Code Replacement key IndyKeys with delimiters \IndyKeys\ then in the ingest IPTC Keywords field I put {usercustom1}.

While this works, it is a bit clunky and requires setting up each computers Job pad.

So could you after evaluating Variables, if there is no match, you evaluate CodeReplacement Keys
{IndyKeys} would resolve to codereplacement because there is no IndyKeys Variable.

Or treat {\IndyKeys\} like a variable and evaluate at Apply.

Or some other method to accomplish the same thing.

Please and Thank you,


Offline dennis

  • President
  • Camera Bits Staff
  • Sr. Member
  • *****
  • Posts: 426
    • View Profile
    • Camera Bits, Inc.
Re: Treat Code Replacement as Variable sometimes
« Reply #1 on: April 07, 2015, 03:20:58 PM »
Hi AJ,

Well this is interesting and I *think* I understand the basic problem which is that the IPTC Stationery Pad will evaluate code replacements right away (interactively).  What you want are multiple IPTC Stationery Pads (snapshots?) that you want to remain static for each day/job?  All these share some common IPTC fields like Caption and Keywords that depend on the job.  So rather than update all the IPTC Stationery Pads for each job, you refer these fields to user/client variables instead (via {usercustom1} etc), and since the User/Client Variables dialog does NOT evaluate code replacements right away you can put your code replacements there and only have to distribute a code replacement file (and possibly update the code replacement in User1 to \IndyKeys\ for example).  But why not just stick with something generic like \CodeKeys\ so you don't have to setup the User/Client Variables dialog on each computer?

So first of all I'd say it is a "bug" or omission that the User/Client Variables dialog does NOT immediately evaluate code replacements, but if it did then your workflow would be broken.  So we aren't gonna "fix this" unless we have another solution for you.

An option is to not "interactively" evaluate code replacements in the IPTC Stationery Pad.  The end result would be the same (other than if you were to change code replacement files after closing the IPTC Stationery Pad).  The problem is that some people use code replacements for a lot of text shortcuts, e.g. "\s\" for "Lucas Oil Stadium" and they expect that to happen throughout the program (although apparently it doesn't in some places like User/Client or for the contact sheet labels in the preferences).

Unfortunately if you type in {\IndyKeys\} then PM would interactively lookup the code for "IndyKeys" so we would have to disable the lookup if it were prefixed by the curly brace.  Then we could have special logic for variables to see if it is a code replacement instead.  This could get tricky.

I am curious why you have multiple IPTC Stationery Pads?  Is it because of something like the Photographer/Title changing?  If so, try using something like the camera serial number as part of a code.  For example, if Joe Schmoe's camera serials are 1234 and 5678 then you can have codes with 2 replacements:

1234   Joe Schmoe    Staff
5678   Joe Schmoe    Staff

Then in the byline (photographer) field you put "\{serial}\", and for the title (position) you put "\{serial}#2\" etc.  Then you just distribute the IPTC Stationery Pad and updated code replacement file to effectuate multiple SPAD versions that differ only on something that can be determined from the camera serial.  Of course this means you better know all the serial numbers!  We are working on a much more sophisticated way of doing this that would provide flexibility, clarity, and robustness for missing info but that is all I'm gonna say about that right now.  Another option is to use the custom chars that most cameras allow you to setup for the filenames.  E.g. ABC_1234.JPG and _ABC1234.JPG.  You could use "\{fbas:0,4}\" and then have the code replacements for either sRGB or Adobe RGB files as:

ABC_   Joe Schmoe   Staff
_ABC   Joe Schmoe   Staff

We are investigating a solution for you.  The simplest is to not interactively evaluate code replacements in the IPTC Stationery Pad, maybe instead have an "Eval" option when holding down the Option key (Mac) like we do for the IPTC Info dialog.  But we will surely get a bunch of "hell" about this for those who rely upon interactive code replacements.



Offline ajmast

  • Newcomer
  • *
  • Posts: 48
    • View Profile
Re: Treat Code Replacement as Variable sometimes
« Reply #2 on: May 09, 2015, 07:43:20 PM »
Sorry just got back into this.

I do know about using serial numbers and do that all the time. The particular instance I was working with had 3 people ingesting on three different computers. And each day the captions and keywords would change.

So my goal is to set up the stationary pad one time on each computer, referencing a Dropbox shared code replacement file wit the caption and keywords in it. Then I could change that file each day and have that be reflected on all the ingests.

My workaround gets the job done, but it is kludgy.

I love having code replacement do it's thing right away, I just need an option to delay it some times until applied. Maybe it is as simple as specifying a delayed-delimiter in the Code Replacement dialogue box. "\" apply right now, "=" applies when saved/applied.

I can also see this being useful for big events where you run a few FTP servers to handle live X-Mits and live ingest to not have to change each machine every day.