Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
How to write the "Event" to metadata
The DAM Forum
Welcome, Guest. Please login or register.
October 29, 2020, 11:51:57 PM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
+  The DAM Forum
|-+  Software Discussions
| |-+  Media Pro & Expression Media
| | |-+  How to write the "Event" to metadata
« previous next »
Pages: [1] Print
Author Topic: How to write the "Event" to metadata  (Read 3494 times)
jayp
Newbie
*
Posts: 25


View Profile
« on: August 30, 2009, 10:51:05 AM »

Here is my goal. I've been wanting to add some metadata for keeping track of a photo session, like someone's birthday party or wedding. A quick search for "John Smith" in this field could bring up the relevant photos nicely. The Event field in EM seemed perfect.

However, I soon realized that I couldn't get Photoshop to see this field, and I further quickly realized that this was due to what one might call the proprietary nature of the field. Sure, XMP is an open spec. But there are inherit risks (or at least increased difficulties) in using a field that other software can't see easily.

I'll spare the whole story, but I tried in vain to get Photoshop CS3 to see EM metadata like Events and CatalogSets. I finally ordered an upgrade to CS4 as I've been considering it for other reasons, and hopefully I can use John Beardy's graciously provided extension to use EM's XMP fields in Photoshop.

My question is simple. Is there a better metadata field to store event info? One that will be future proof and work across different software with no extra effort, (say if I were to switch from EM to something else). I didn't want to use the caption field, because it's more specific to an individual photo. Plus, at times it might be necessary to update the event field in bulk, and if you have a caption that includes the event plus other information about an individual picture, now you can't change the caption in bulk without overwriting previous data. I could use a keyword, but now when I search for "John Smith", I'm going to possibly get back pictures of the birthday cake as opposed to only those pictures of John Smith.

I've search these forums repeatedly and haven't found much. I'll also embarrassingly confess to not having the 2nd edition of The DAM book.  Cheesy (The 1st edition was too good Peter, and as a graduate student who's not really a photographer, I already spend more that I really ought to on this hobby.)

Thanks everyone for any advice.
Logged

Jay Packer
peterkrogh
Administrator
Hero Member
*****
Posts: 5682


View Profile Email
« Reply #1 on: August 30, 2009, 02:55:01 PM »

Jay,
Just use a keyword.  You can select on the Keyword John Smith, and on the keyword Birthday, and should come up with pictures from his celebration.  If you want to make a more targeted collection (I use the term "intent" in the new book to define images that have been purposely grouped together), then you can make a further grouping with Catalog sets.  If you anted that data to be readable outside EM, then you ccould make a keyword called "John Smith Birthday Slideshow", but I would suggest you probably don't need to do that until you leave Expression Media behind for good, and want your organizational work to travel to your new catalog/DAM.
Peter

Logged
jayp
Newbie
*
Posts: 25


View Profile
« Reply #2 on: August 30, 2009, 04:38:48 PM »

Hi Peter. I agree that CatalogSets are perfect for what you call intent, and I'm already using them for that very purpose. I cringe a bit at the keyword suggestion, and the main reason is that now I would have a huge number of pictures that didn't have "John Smith" in them but instead were of his birthday party. Now a keyword search for John Smith returns pictures of a wrapped present, the family pet, and the sunset outside the house... Whereas if I keep this out of the keywords, a search for "John Smith" returns only pictures of the person.

Do you or others think it's a bad idea to use the Event field? Bad as in it ties me to one piece of Software (xMedia) and makes me work harder with other (like Photoshop) to ensure that the Event data stays with a field through subsequent derivatives?

I know that ImageIngester has an Event field and I assume it's the same field as xMedia's.

Sorry if I'm making this more difficult than it needs to be. It just seems simple and there seems to be a perfect solution available (the Event field), but I'm trying to make sure I understand its implications.

Edit:
And I just discovered that EM shows a nice Event dropdown list right under the File Type on the Organize pane... Very nice.
« Last Edit: August 30, 2009, 04:44:48 PM by jayp » Logged

Jay Packer
jayp
Newbie
*
Posts: 25


View Profile
« Reply #3 on: August 30, 2009, 04:52:26 PM »

Hmmm. Maybe I am being way too silly about this question. I had thought that since Photoshop couldn't see the xMedia XMP fields (like CatalogSets or Event) that it was removing them when I made derivative files. But upon further testing, that doesn't appear to be the case at all, and I must have been confused. Derivatives still have the Event just fine and xMedia can read it. That makes sense for Photoshop. Just because it can't read an XMP namespace doesn't mean it should destroy it upon writing a file.

So the only real question would seem to be whether my idea is a good one to begin with. I freely concede that it might not be but if so am trying to understand why.
Logged

Jay Packer
peterkrogh
Administrator
Hero Member
*****
Posts: 5682


View Profile Email
« Reply #4 on: August 30, 2009, 05:01:17 PM »

Jay,

>I cringe a bit at the keyword suggestion, and the main reason is that now I would have a huge number of pictures that didn't have "John Smith" in them but >instead were of his birthday party. Now a keyword search for John Smith returns pictures of a wrapped present, the family pet, and the sunset outside the >house...

That's a bigger issue that's been around for a while. Some pictures *about* John Smith, may not be *of* John Smith.  So a picture of a present give to John Smith is "about" him, even though he may not be in the picture. This is a huge issue for stock libraries, where good pictures of Barrack Obama may be greatly outnumbered in a collection by pictures about his events' supporters, etc.

The new IPTC addresses this with the creation of a field that specifically names those pictured. So the Keyword John Smith would return the pictures of the presents and the people, but the People PIctured field would only return the images John is in. Of course, this creates a *lot* more work for the person doing annotations, but it's certainly worth it for stock images that are distributed by searchable database. (You could use the iView People Field as a stopgap to hold this information, if you like).

I would submit that for the individual photographer, it's totally fine to have the larger filtered grouping be the one that is broad, and that if you're going to do lots of additional work, it should be based on intent.  So it's okay that Josie and all her 10 year-old friends come in a cross-referenced search of Josie and Birthday. The *most important* value, in my opinion, would be the custom grouping I do with the cross-filtered results. The sideshow of her last 10 birthdays, which includes pictures of her friends and her favorite presents is a much more important place to spend effort than simply making any photo of Josie exclude all photos of Ellie.

This is where the concept of filtering vs intent becomes important. Filtering will always be rough, unsequenced, and a way to narrow down the search to the most likely images.  The images grouped with Intent are the valuable groupings, since this grouping reflects lots of additional work, as well as some editorial purpose for the grouping's very existence.

Peter
Logged
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!