Delimited Keywords

[tstoddard]

I am using Photo Supreme to organize my images and add keywords and other metadata to them. I want to use AfterShot Pro to process my raw files but if I organize them in Photo Supreme before processing them in AfterShot Pro I run into several issues. One of them has to do with the handling of delimited keywords that are being written by Photo Supreme.

I am writing my keywords in a delimited format so that a keyword might look like this: "Places/United States/Pennsylvania/Gettysburg" (all one keyword). When AfterShot Pro opens these files I end up with the following keywords: "Places/United States/Pennsylvania/Gettysburg","Places";"United States";"Pennsylvania";"Gettysburg". This would not be a concern to me if it only appeared in AfterShot Pro. However; if I output a jpg from the raw file and embed my metadata into it, which I want to do, then I get the extra keywords in my jpg. Is there some way to prevent AfterShot Pro from "flattening" the delimited keywords and then adding them along with the delimited keywords? I know that I can opt not to embed the metadata into the jpg in the first place but I want the metadata embedded in the jpg, I just don't want metadata that I didn't put there in the first place.

[teknisyan]

Unfortunately, there's no way to prevent this, since Aftershot interprets your delimited keyword differently. Since Aftershot has its own photo management feature, why not just use aftershot to organize your images as well.

[ferdinand-paris]

I am writing my keywords in a delimited format so that a keyword might look like this: "Places/United States/Pennsylvania/Gettysburg" (all one keyword). When AfterShot Pro opens these files I end up with the following keywords: "Places/United States/Pennsylvania/Gettysburg","Places";"United States";"Pennsylvania";"Gettysburg".

I'm not familiar with Photo Supreme but the approach you describe is not commonly used in my experience, like I've never seen it before. Keywords is usually a multiple entry field, whether they are stored in IPTC or XMP. Personally I think that the problem is either your approach and/or the software you're using. I suspect you would get a similar result in most raw converters.

F_P

[tstoddard]

Photo Supreme is the successor to IDImager. Both IDImager and Photo Supreme allow you to write keywords as flat keywords or as delimited keywords. The advantage of writing delimited keywords is that the delimited keywords are self documenting in that they indicate the hierarchy when you are using hierarchical keywords. Some other programs can interpret them and ASP obviously interprets them to some degree. How would it know to write flat keywords in the keyword field if it didn't? I believe it's actually more complicated than that, however. Since this is happening with raw files, that means that it is getting the data from the xmp sidecar file that Photo Supreme creates. In that file, the hierarchy is also represented using xml syntax. ASP is obviously misinterpreting Photo Supreme's xmp schema.

As far as using ASP to organize my files, I find it to be terribly lacking. IDImager and Photo Supreme can do so much more than ASP that there is no comparison. ASP shouldn't even try to represent itself as a cataloging program. Unless I'm missing something, ASP only gives you access to a very small subset of the metadata that is contained in an image file. It appears the ASP doesn't even recognize any of the IPTC Extension standards. There are three different places in the IPTC standard where you can put the location information for an image. In the extension standard, you can specify the location of the content of the image and the location at which the image was created. For example, if you were in New Jersey taking a picture of New York City, the location created would be different than the Location of the content. This is just one example but there are many others.

In order to enable users to fully populate the appropriate metadata fields, Photo Supreme and IDImager allow the user to map labels (keywords) to metadata fields and to cascade that mapping up the keyword hierarchy. For example, if I create a keyword hierarchy that has a category named "Places" with a label "United States" with a sub label "Pennsylvania" and then another sub label "Gettysburg", I can map United States to the country field(s) that I want to populate, Pennsylvania to the state field(s) and Gettysburg to the city field(s). I usually map them to both the IPTC core location fields and the IPTC extension "location created" fields. All I have to do is assign the "Gettysburg" label to my image and all of the metadata fields will be populated. The Pennsylvania and United States label will also be assigned and I can decide whether I want the keywords to be written to the IPTC keyword field as separate "flat" keywords or as one "delimited" keyword. Clicking on one label populates six metadata fields and adds 4 keywords to an image.

The wisdom of using delimited keywords is something that I'm still a little undecided about and what's happening to me in ASP is making me reconsider, but there are times when it is very helpful. Lightroom and Windows Photo Gallery both take advantage of delimited keywords to interpret the hierarchy that I've created. Whether I use delimited keywords or not isn't the point. I can't imagine having to populate all of the appropriate metadata fields individually (even if I could, which I can't in ASP because they're not there). I guess ignorance is bliss. ASP figures that if they don't tell you that those fields are there that you won't miss them.

[tstoddard]

Since Aftershot has its own photo management feature, why not just use aftershot to organize your images as well.

Abiel,

Your comment has prompted me to start experimenting with Aftershot's photo management features and I have some concerns with the limited capabilities. In my previous post I pointed out that Aftershot doesn't appear to support the entire lptc standard. That may or may not be a problem. I like being able to map keywords to metadata fields but it is probably not a necessity for me personally. An area that I do find very limited is in the searching or selecting of images based on a combination of keywords. I can't find a way to select images that have two or more keywords. In other words, If I want pictures that have both me and my wife, and only pictures where we are both in them, I am unable to do that. I can easily select pictures that have either of us in them (basically an OR query) but I can't find a way to query the catalog for pictures with "me AND my wife". I find it interesting that when I select two keywords in the metadata browser and click "refine", I get a filter that says "keyword1 AND keyword2". However; the set that is returned contains all photos with keyword1 OR keyword2.

Am I missing something?

Edit: I've experimented some more and see that I can accomplish an "AND" set if I select two keywords that are in different categories but not if they are in the same category. In other words, if I pick Tom and Joe from People, I get all photos with either Tom or Joe in them. If I pick Tom from People and Pittsburgh from Places I get only photos that have both Tom and Pittsburgh in their keywords. This may be by design but it is inconsistent and limiting. Please tell me if I'm mistaken or I'm missing something.

[ferdinand-paris]

Putting hierarchical keywords in either the IPTC Keywords or XMP Subject fields is potentially troublesome, as these fields were intended for flat keywords. Adobe uses the XMP:HierarchicalSubject field for hierarchical keywords, and they tend to set the standard by force of their size and steamroller-like behaviour. I have been helping IDImager uses migrate to iMatch over on the iMatch forum, and so I know that IDI could write to this field, but I don't know about Photo Supreme. Also, the use of the "/" character as the delimiter in the hierarchy is novel - Adobe uses "|". I suspect if you were able to use this field and delimiter then your problem would be solved.

You shouldn't need to use ASP's primitive cataloguing function if you use a capable DAM, and have it configured correctly.

F_P

[tstoddard]

F_P,

Thank you for your feedback. Like I said in my earlier post, I'm questioning the wisdom of using delimited keywords and I always have. When I first started using IDImager I had submitted a question to their forum about it and the responses I got influenced me to use them. I was puzzled why anyone would want to do that but then I heard from others who claimed it enabled them to interact with other programs more effectively. I figured that there was little harm in using them since I expected to use Photo Supreme for all of my cataloguing needs. Then I saw what happened in ASP when I created some jpg's from raw files that I had previously assigned keywords to in Photo Supreme. Now I have to rethink everything. Fortunately, it will be pretty easy to change my configuration in Photo Supreme and to synchronize my data to reflect the changes and replace the delimited keywords with flat keywords. At this point, I only have about 7,000 photos cataloged.

I started using IDImager by downloading the 30-day trial and before my trial period expired they had discontinued development on it so I switched to Photo Supreme and found that it was suitable for my purposes. I've started using ASP because I find the raw converting to be easy, fast, and effective compared to using Photo Supreme or Raw Therapee. Also, the price was right. I'm an amateur who is new to processing raw files so I'm doing a lot of experimenting and have learned a lot but still have a lot more to learn.

After reading some of the other topics on this forum, I'm concerned about the future of ASP. Corel seems to be awfully quiet about it so I'm very hesitant to invest too much time and effort into it. I sure wish that there was one program that would do both DAM and raw processing well. So many are close but they always seem to be missing a few key elements.

[grubernd]

hierarchical keywords in ASP are ";" semicolon-delimited.

want to hear my opinion? unless you are documenting only biological specimen or other hard hierarchical systems where you NEED the output images contain the exact hierarchy then do yourself a favor:

don't use hierarchical keywords. just don't. too much work for little payback.

PS: geography is better covered with the iptc fields location, city, state, country.

[afx]

don't use hierarchical keywords. just don't. too much work for little payback.

AMEN!
afx

[ferdinand-paris]

don't use hierarchical keywords. just don't. too much work for little payback.

AMEN!
afx

I disagree, but with the proviso that you manage them entirely in a *REAL* DAM that understands metadata. This does not include ASP.

F_P

[grubernd]

I disagree, but with the proviso that you manage them entirely in a *REAL* DAM that understands metadata. This does not include ASP.

well.. i discovered the uselesness of hierarchical keywords and categories *while* using a real DAM (imatch) when i was still highly enthusastic about all it could do. then i realised that the way websearches evolved from categorical finegrained multiclicking directories to a single "search here" field might not be a bad idea after all. and presto.. typing a keyword and then looking through 200 thumbs for the right image proofed so much more efficient and fun than trying to get an image assigned to the right category in the hierarchy. and creating those hierarchies before. and adjusting them to changes in style, shooting preferences, topics etc etc.

[tstoddard]

PS: geography is better covered with the iptc fields location, city, state, country.

I agree with this statement but keep in mind that if you include the iptc extension standard (which ASP opts to ignore) there are no less than three different places in which you could store geographic information about the content of the image in the iptc namespace. There are also fields in which to store geographic information about the creator of the image. One reason that I put geographic information in my keywords is because I use a program that enables me to map keywords to iptc fields and to cascade that mapping functionality. As I explained earlier, when properly configured, Photo Supreme or IDImager (and I think iMatch) will enable you to populate a multitude of iptc fields just by assigning one keyword. This is tremendously time saving and much less error prone than manually populating iptc fields. So while I agree that putting the information in iptc fields is the best practice, the use of hierarchical keywords is a great way to do that consistently.

This issue is unrelated to delimited keywords which are just another option some programs offer. Whether or not you opt to write the keywords out in a delimited format, you can still take advantage of your hierarchy to achieve workflow efficiencies. I have read several opinions both for and against hierarchical keywords and I have come to the conclusion that the real advantage of using a hierarchical structure is in assigning keywords and other metadata to image files. It makes for a much more efficient process. This obviously doesn't hold true for everybody but I think most of us have at least some images of wildlife or some other interest that result in photos that can easily be categorized and organized into hierarchies. Nothing says that you have to categorize all of the keywords you use but if you have some that would benefit from being organized in that manner, why not do it for those?

[grubernd]

well, as i stated, it's my personal experience and opinion that maintaining hierarchical keywords is too much hassle. if it works for you i wont talk you out of it, after all workflow is very circumstancial.

because i like to poke around and debug stuff, i just played around with regular xmp files created by ASP, wrote them out, edited them, merged them again and so on. you might want to look at the xmp files that Photo Supreme writes, because this is what i found:

keyword "Places/United States/Pennsylvania/Gettysburg" gets written out as:

Code: Select all

   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>Places/United States/Pennsylvania/Gettysburg</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>
   <dc:subject>
    <rdf:Bag>
     <rdf:li>Places/United States/Pennsylvania/Gettysburg</rdf:li>
    </rdf:Bag>
   </dc:subject>

merge it, and it will show as "Places/United States/Pennsylvania/Gettysburg"

while keyword "Places|United States|Pennsylvania|Gettysburg" gets written out as:

Code: Select all

   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>Places|United States|Pennsylvania|Gettysburg</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>
   <dc:subject>
    <rdf:Bag>
     <rdf:li>Places</rdf:li>
     <rdf:li>United States</rdf:li>
     <rdf:li>Pennsylvania</rdf:li>
     <rdf:li>Gettysburg</rdf:li>
    </rdf:Bag>
   </dc:subject>

merge it and you get also only "Places|United States|Pennsylvania|Gettysburg" in ASP.

but reimport an xmp file with this content:

Code: Select all

   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>Places/United States/Pennsylvania/Gettysburg</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>
   <dc:subject>
    <rdf:Bag>
     <rdf:li>Places</rdf:li>
     <rdf:li>United States</rdf:li>
     <rdf:li>Pennsylvania</rdf:li>
     <rdf:li> Gettysburg</rdf:li>
    </rdf:Bag>
   </dc:subject>

and ASP shows keywords as "Gettysburg, Pennsylvania, Places, Places/United States/Pennsylvania/Gettysburg, United States"

which suggests that if a software recognizes the delimited keywords then it writes them out two times according to some xmp-rules, making them available to other software that dont know about hierarchical keywords. since ASP does not recognize "/" as a correct delimiter it shows both entries. if you have a recognized delimiter - either ";" semicolon or the "|" pipe in the hierarchicalSubject ASP will not import and show the split up keywords.

"persuade" your DAM to use the official xmp-delimiter "|" (vertical bar) and you should be in the clear.
if Photo Supreme suggests to use "/" as a delimiter, tell them it's a bug.

PS: this little exercise shows that the xmp-parser in ASP is actually pretty well done and does adhere to some clear rules.

PPS: "/" as a delimiter is a very bad idea anyway because it is heavily related to file system structures on all *nix systems, which includes Macs, and is also part of xml structural code. "|" or ";" arent without any other usages, but at least they are more neutral if that makes any sense.

[afx]

don't use hierarchical keywords. just don't. too much work for little payback.

AMEN!
afx

I disagree, but with the proviso that you manage them entirely in a *REAL* DAM that understands metadata. This does not include ASP.

When you are thinking iMatch hierarchical categories, that is a totally different thing from keywords.
Keywords for me is explicitly the IPTC keyword field where I think hierarchical keywords are completely wrong.
iMatch categories are a very useful way to handle other forms of meta information (that I would never ever want to see in images that I pass on, in contrast to proper keywords).

cheers
afx

[afx]

... if you include the iptc extension standard (which ASP opts to ignore) there are no less than three different places in which you could store geographic information about the content of the image in the iptc namespace.

Which ones?

One reason that I put geographic information in my keywords is because I use a program that enables me to map keywords to iptc fields and to cascade that mapping functionality. As I explained earlier, when properly configured, Photo Supreme or IDImager (and I think iMatch) will enable you to populate a multitude of iptc fields just by assigning one keyword. This is tremendously time saving and much less error prone than manually populating iptc fields.

So you duplicate information in a non standard way and rely on non standard behavior in software.

Not a good idea.
As that stuff is application specific you should not expect it to be transparent for other applications.

As long as there is no real standard for hierarchical keywords and the quasi standard is what LR does, I would not use anything but what LR uses.

cheers
afx