XMP template with label by hand not working

[Dawnne Gee]

Peter, if this isn't the right place, I apologize. There isn't a thread dedicated wholly to metadata, so I did a best-guess while I'm getting prepared for a client visit.

I've mentioned before that coming from a programming background, that I like to address the XMP metadata from a textual standpoint. For example, my "Copyright Basic" template was derived from a photo, but I edited it in a text editor long ago because there were some temporary glitches with CS1 that would (or seemed to) overwrite EXIF data during an append. So, I stripped all the EXIF data from that template and brought it down exclusively to the xmlns:photoshop, xmlns:xapRights, and xmlns:Iptc4xmpCore containers, which are the only ones needed. This template has served me quite well for original-download purposes for a couple of years now, with the only tweak being the changes in the year.

Now, I know hitting Ctrl-6 isn't that big of a deal, but since my original template has worked so well, it was a natural thought for me to simply add the xmlns:xap container in my template and save me that one, little step. With each wedding typically being over 1,000 photos (heck, sometimes over 2,000!), the time for Ctrl-6 to populate itself in full buckets is appreciable.

Alas, adding this data to my template has been met with some frustration. I've been very careful to ensure that I have everything syntactically correct (syntactical correctness still being a major portion of what I do as a programmer), but with xap label data in this template, all elements of the template are simply ignored -- not even my original stuff gets appended to file metadata anymore. I've troubleshot this as far as it can be taken, fully ensuring tag hierarchy is conformed to in the xmp file, and even trying a template that ONLY had the label data in it, and trying it as a Replace on some trash files. Still a no-go. The bottom line being that label data cannot be appended to a file this way.

I'm not sure if that is WAD or if it is a bug. What do you guys with bigger brains think? To me, it seems like any valid data that is in an xmp file should be able to be appended to another file. Is label data part of what is protected by Append? Adding label data this way also didn't work as a Replace, either, though. So, I'm stumped. I thought this would be a simple thing -- and again, don't get me wrong -- I'm not advocating that Ctrl-6 is too hard to do! I just thought this would be slightly more effective, but as Murphy's Law would have it, it actually turned out to be a bit of a time-waster.

Thanks for your insights.

~Dawnne

[peterkrogh]

Dawnne,
first, I can't imagine why you are doing this.  You can invoke the Label with a menu item, or a keystroke (don't even need the modifier key if you have preferences set right) and you can do it to multiple files at once.  What am I missing?

There are a couple possible issues:
The syntax in which the label data is contained
The behavior of the application applying the XMP data
The behavior of Bridge reading the data

Have you determined that you have created a valid syntax? (Make an XMP file that only has label in it.)  The XMP data is stored in blocks, and you need the right header on the block.

Are you applying this template with Bridge, or some other application?  I know Bridge used to apply Lable data as part of a template, but some people considered it a bug (just as you saw the EFIF problem with CS1.  It may have changed in more recent versions of Bridge.

And lastly, I assume you are reading it out with Bridge.  are labels just not showing?  Are they white (indicating mismatch)?
Peter

[Dawnne Gee]

Hey....

As I stated in my original message, there's no real issue with being able to use [6] or [Ctrl-6] (i have it set to Ctrl+key so it's the same in Bridge as in ACR) to set the "Unrated" label. Laying aside whether a person's keyboard-shortcut preferences are "right" or "wrong", what I am bringing up is a potential bug in Bridge (mis)reading and not applying XMP metadata that already includes label syntax.

Addressing your possible issues:

• The syntax in which the label data is contained ~ literally copy-n-pasted from an XMP file that contains such a label applied from Bridge. if the syntax is "wrong", it would a) be Bridge's fault, and b) be arbitrarily applied
• The behavior of the application applying the XMP data ~ I'm talking about Bridge appending an XMP metadata template via File Info (regardless of whether from the right-click context menu or metadata flyout menu or Bridge menu)
• The behavior of Bridge reading the data ~ and there you have the reason for my post!

As I mentioned in my original message, I'm confident the syntax, including parent wrappers ("headers" as you call them), is proper, and I did indeed try one with just the label syntax in it. More relevant, as part of my troubleshooting of this error, I simply made a new metadata template from a file that contained label information. When appending that metadata template to another file, I experienced the same behavior: no metadata from the template was appended to the file(s) being processed.

I'm applying the template within Bridge, and reading it out in Bridge. Not only are the labels applied this way not showing, the other properly-formed metadata cited in my original message also is not read into the metadata files when the label data is in there. They do not show white -- they literally are not applied to the file. Looking at the resulting files in a text editor confirms that when label data exists in the template, the resulting image metadata files contain NONE of the template metadata at all.

[peterkrogh]

Dawnne,
Are you saying that you created a template in Bridge - using the tools in Bridge to create a template - and it was not applied when you chose Bridge's "apply Metadata Template"?

Or are you saying that you created a template in a text editor (or other application) and when you tried to apply it with the Bridge "Apply Template" command it was not applied?

Peter

[Dawnne Gee]

Hey, Peter.

Originally, I had created a template by hand and experienced the problems I talked about. "By hand," though, in regards to the label data, was copy-and-pasted from an XMP file that contained label data.

In the process of troubleshooting that, I created a template from a file that had a label. I checked in my text-editor (UltraEdit) to ensure that this Bridge-generated template contained the syntax for the label. When I applied this template to another file, the label data was not passed through, and the target files did not become labeled by virtue of applying the new template to them.

In retrospect, I believe this is WAD. "File Info" only applies metadata from the tabs in it's own dialog. Since labels are settable via scripting, it's probably not that big of a deal, but it does strike me as odd that label metadata is "protected" in the same regard that EXIF metadata is. After I realized why it was working this way, I didn't try it with a rating, but I still think that kind of metadata should be able to be applied via a metadata template, as it is, after all, metadata.

To answer your original question, I am personally inclined to do things like this via text, because doing so with a decent text-editor is much faster than Bridge. Quite frequently, I use global search-and-replace functions with regular expressions to delete, replace, or append keywords to existing metadata files. I also use this method for applying generic metadata (photographer and copyright information) to wedding shoots after they're downloaded. This was the first time I'd tried it with labels, and since everything else had worked just fine for several years, it caught me by surprise, is all.

[peterkrogh]

tDawnne,
There were lots of problems that came up when Bridge would apply all data in a template.

Say you had rated or labeled a shoot before adding template metadata.  You'd be pretty unhappy if adding photographer info wiped out all the ratings.  Same with Camera Raw settings, so Bridge excludes these as well.

By the design of the tool, for most people metadata templates will be applied to many images at a time.  Ratings and Labels, by their design, tend to be applied to images one-at-a-time or in small groups (although the functionality also easily allows applying them to many files at once.)
Peter

[Dawnne Gee]

Say you had rated or labeled a shoot before adding template metadata.  You'd be pretty unhappy if adding photographer info wiped out all the ratings.  Same with Camera Raw settings, so Bridge excludes these as well.

Understood, but that's exactly what I was after: On import, if I could automatically rate everything as "Unrated" when I apply my "Copyright Basic" metadata, that would be a least a tish more elegant than having to go into each bucket to label the contents manually.

I'm not wanting Bridge to apply ALL metadata! But if I apply a template that has label data, shouldn't that label data be applied? I realize that in most circumstances, ratings are individualized. But per your workflow, every photo's initial rating (or label as the case may be), is applied ubiquitously, so there's at least some argument for Bridge either producing an alert prompt a la [Your metadata template will overwrite existing label data! Continue? YES/NO], or make it a user-definable option. It's a minor inconvenience workflow-wise, but it's representative of limitations on usability.

[peterkrogh]

But per your workflow, every photo's initial rating (or label as the case may be), is applied ubiquitously, so there's at least some argument for Bridge either producing an alert prompt a la [Your metadata template will overwrite existing label data! Continue? YES/NO], or make it a user-definable option. It's a minor inconvenience workflow-wise, but it's representative of limitations on usability.

I actually don't apply the Unrated label, unless I am skipping initial rating as I bring the images through ACR Adjustments.  So, I don't apply this to all images very often.

As to the ability of Bridge (and pretty much all other DAM applications) needing to get smarter about segmenting the treatment of different types of metadata, and giving you more granular control over how you are applying it, and what to do in the case of mismatch, well, yes, I would agree there is much room for improvement.
Peter

[Dawnne Gee]

I actually don't apply the Unrated label, unless I am skipping initial rating as I bring the images through ACR Adjustments.  So, I don't apply this to all images very often.

I started (re-)researching workflow as it became obvious I was spending more time on wedding shoots than I had planned for. I chalked it up to "diligence" (which it was, insofar as intentions go), but through research discovered that some of what I'm dealing with time-wise is simply bad workflow. Luckily, workflow is one of those things I constantly re-evaluate as time allows, but with one surgery, a leg injury, several weddings, and two last-minute sports-coverage contracts starting up right at the end of ths summer, my subjective time became severely constrained. Add to that somewhere just shy of 150K photos from 1999 onward to bring in and get cataloged, and I've got my over-winter work cut out for me. It didn't take me long to figure out that Peter's and John's experience are formidable and that I'd be a fool not to listen to them, but I also recognize that having worked on my own since 1995, I have a few....er...quirks.

My first shoots to which I applied Peter's "inbound" workflow were from several hunting sessions over the Thanksgiving holidays and a Christmas concert I captured last night. I found immediately that bringing in photos with the "unrated" label was extremely helpful to me. There's nothing quite like a field of red in Bridge's thumbnail view to motivate me to work effectively -- in fact, after just a few hours this morning, I ploughed through nearly a thousand photos using RapidFixer. For what it's worth, my default XMP file contains basic copyright information plus the "Unrated" label and it all comes through into Bridge just fine, after having been applied through ImageIngester.

[peterkrogh]

Dawnne,
Glad it's working for you. 
Peter