Mapping Labels to Iptc Location Created

Post Reply
tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Mapping Labels to Iptc Location Created

Post by tstoddard » 02 Oct 12 2:24

I updated to 1.0.5.59 and tried out some of the changes that were made. I like the save as capability. That resolved some of the questions I was asking myself about how to accomplish exactly that.

I've been reading the Iptc Specification, thank you for pointing me in that direction. Now that I've been educated about the Iptc specification I thought I should try mapping some keywords (labels) to some of the metadata fields. I started with places. I have some photos from Key West Florida so I've created a hierarchy Places>Florida>Key West. I have Key West configured to also assign its parents. I then mapped Florida to the Ictp4xmpExt:LocationInImage.Iptc4xpmExt:State and Key West to Ictp4xmpExt:LocationInImage.Iptc4xmpExt:City. I also checked the "Also process parent mapping" checkbox, thinking that if I didn't do this that the state wouldn't get entered when I assigned the city. When I assigned the Key West Label to an image and synchronized I ended up with two entries in the Ictp4xmpExt:LocationInImage field. One entry includes the city and the state and the other entry includes the state only. I then unchecked the "Also process parent mapping" checkbox and I got the result I desired. One entry that includes the city and state.

In this scenario it is not a problem. I can just leave the "also process parent mapping" unchecked and I'll get the desired result, but this might not always work. What if I don't want the parent mapping processed? I'm not sure why I wouldn't want to do that but leaving that checkbox unchecked certainly leads the user to believe that the parent mapping won't get done. I guess that there is some logic here that makes sense. If I don't assign the parent label and still want to process the parent mapping I can do that by not assigning the parent label but checking the "also process parent mapping" check box.

It's just a little confusing and I thought it would be helpful to share this everyone else who might get tripped up by this.

Great job on the fixes and improvements, Hert!
Tom Stoddard

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 7:18

Tom, I note that you're using the IPTC Extension "Location in Image" fields, rather than the "Location Created" fields. I wonder if that if causing the issue that you are seeing.

You see, the "Location in Image" fields have a Cardinality of 0..unbounded, i. e. there can be multiple sets of values (an image can show multiple locations), while the "Location Created" fields have a Cardinality of 0..1, i.e., there can only be one set of values. Hert has put in code to ensure that the "location Created" fields can only have one set of values; I don't think that he has done the same (and he may not be able to) for the "Location in Image" fields, since, by definition, there can be multiple values.

For this reason, I've elected to use the "Location Created" fields for my automatic mapping, and set it up like this:

At each level in the Catalog Labels "Places" hierarchy, I'm doing a mapping. Thus:

World Region level - Iptc4xmpExt:LocationCreated.Iptc4xmpExt:WorldRegion
Country level - photoshop:Country,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:CountryName
Province/State level - photoshop:State,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:ProvinceState
City level - photoshop:City,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:City
Sublocation level - Iptc4xmpCore:Location,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:Sublocation

I also have "process parent mapping" enabled at the Country, Province/State, City and Sublocation levels.

One thing I'm particularly pleased about is that at the Country level, I also have Detail Profiles defined that have the 3-letter ISO Country Code defined for the country. This gets added to the IPTC Extension Location Created bag, along with the other properties that are being defined by the mappings. So I can then have a conformant IPTC Extension Location Created element with all six properties correctly defined.

This all works perfectly, and I'm very pleased with the result.

I may use "Location in Image" fields in the future, but I will always enter the data manually - this can't be an automatic process, since it needs a human to examine the image and define the locations...
Hope this helps.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Re: Mapping Labels to Iptc Location Created

Post by tstoddard » 02 Oct 12 12:36

Geoff,

Thanks for pointing that out. I missed that detail. The user notes in the specs seem to indicate that you should only use both fields if the location in the image differs from the location in which it was created. They don't indicate which field should be used if they are the same. Now that you've pointed this out to me, it makes sense to use the Location Created field when they are the same.

I just changed my mapping to use Location Created instead of Location Shown and I'm still able to get both city and state mapped without having to check "Also process parent mapping". I assume that the only time I would need to check that box is if I don't specify that I want the parent labels assigned. Can you think of any reason why I should check that box anyway. Based on the way that mapping was applied when I used the Location Shown fields, it seems to me that it would be more efficient not to check "Also process parent mappings". I'm thinking that it requires less steps when applying mapping to a large number of labels, especially when using a complete hierarchy like you have. For example, if you assign the sublocation label and all labels are configured to assign their parent labels then I envision the mapping process taking place at each level in the hierarchy.

- the sublocation label is assigned
- the sublocation mapping is processed
- the state mapping gets processed
- the country mapping gets processed
- the world region mapping gets processed

Then
- the city label gets assigned
- the city mapping gets processed
- the state mapping gets processed
- the country mapping gets processed
- the region mapping gets processed

this pattern continues .....

I could be mistaken about how this happens but if I'm correct, it seems that there could be a significant effect on efficiency. I'd be curious to hear from Hert on this to find out if my assumptions are correct.
Tom Stoddard

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 13:39

I'm surprised that when you apply a City label, that you are getting both City and State mapped if you have the "Also process parent mapping" box unchecked.

To my way of thinking, if that box is not checked, then applying the City label should just do the mapping for City into the Location Created fields. The State should NOT get mapped into the fields, UNLESS you also explicitly assign the State label to the image as well...

That's always been my experience of how it worked.

I've just created a hierarchy of Place names:

Middle Earth - Mapped to photoshop:Country,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:CountryName
The Shire - Mapped to photoshop:State,Iptc4xmpExt:LocationInImage.Iptc4xmpExt:ProvinceState
Hobbiton - Mapped to photoshop:City,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:City
Bilbo's House - Mapped to Iptc4xmpCore:Location,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:Sublocation

None of these Labels have "Also process parent mapping" checked.

And, as expected, when I assign the label "Bilbo's House" to an image, I get [Bilbo's House] just in the IPTC Core Location and the IPTC Extension Sublocation fields.
Similarly, when I assign the label "The Shire" to an image, I get [The Shire] just in the Photoshop City and the IPTC Extension City fields...

By NOT checking the "Also process parent mapping", I'm only getting a single level shown in the image metadata - not the full hierarchy.

HOWEVER, there is indeed something odd going on with the metadata... If I subsequently unassign the labels from the images, then the metadata fields are NOT cleared. They can be overwritten with new values, but not cleared. Therefore I suspect what you are seeing is some sort of additive effect of several operations.

I need to play around with this a bit more, and possibly report a bug around the clearing process...
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 14:26

Yes, I'm seeing the following:

1) Set up "process parent mapping" and assign "Bilbo's House" to an image.
2) That produces the IPTC Extension Location Created bag containing [Bilbo's House]. Then the subsequent parent mappings add in the other levels so that you end up with [Bilbo's House, Hobbiton, The Shire, Middle Earth].
3) it also writes out "Bilbo's House" into the IPTC Core Location, and the parent mappings of "Hobbiton", "The Shire", and "Middle Earth" get added into the IPTC Core fields on the cycle through the parent processing.
4) If you unassign the label "Bilbo's House" from the image, the image metadata remains unchanged. Even explicitly saving the metadata to the file does not clear it.
5) If you now clear the "Also process parent mappings" checkbox, and assign the label "Bilbo's House" to the image again, you will see this:
a ) the IPTC Extension Location Created fields get reduced to the single term [Bilbo's House], but
b ) The higher level IPTC Core fields do not get cleared - they still have "Hobbiton, "The Shire" and "Middle Earth" in them.

Only if you assign a completely different Place Label to the image will the metadata get overwritten with the new values.

This seems to me to be a bug.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Re: Mapping Labels to Iptc Location Created

Post by tstoddard » 02 Oct 12 15:04

Geoff,

In my case, I was intentionally assigning parent labels. That was my point. If I assign parent labels AND I process parent mappings, it appears that the result is the iterative process that I explained in my last post. This is probably not a bug but it can cause confusion and inefficiency. Perhaps the code should detect when a parent label is to be assigned and ignore the parent mapping process when this is the case. Perhaps my concerns are unfounded.

I also noticed that the metadata fields don't get cleared if you change the mappings but, after some thought, I realized that it is probably not a bug, just a design decision. How would the program know whether or not there are values in the metadata fields that were entered or modified manually? I imagine it would also add considerable overhead to the mapping process internally.

I'm taking a lot of guesses as to why things are happening the way they are. Hert probably has explanations for all of this behavior. Whether or not any of it should be changed is up to him but I wanted to at least point out some of the confusion that exists. What it comes down to is that the user needs to think about the combination of configuration settings being applied during the label assigning process in order to be able to accurately predict the results.

Also, you said the you are also writing the values to the iptc core fields. Are you doing that by mapping the labels to both fields or do you accomplish that by some other means?
Tom Stoddard

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 15:31

Tom,

Ah, OK, I understand now. If you are explicitly assigning parent labels in the hierarchy, then you don't need to have the "Also process parent mapping" turned on.

As for me, I prefer to just assign one label, and know that all the parent labels are automatically assigned. It seems to me to be so much more efficient. It cuts down on the work. As the Chinese saying goes, if you keep a dog, why bark yourself?

Yes, you could be right that it's a "design decision" that fields don't get cleared - I now see that it is the same for IDI. However, I would argue that If you have a field mapped to a catalog label, then by design, the content of the field MUST reflect the label - and if the label gets removed from an image, the content of the field MUST be cleared.

It's the same with keywords - I've got the "Replace keywords with Catalog labels" setting turned on - therefore I expect the state of Photo Supreme to be reflected in the metadata content.

However, I can see that it is less of an issue for Places to behave in a "Write-only" fashion. And I can always clear them manually if it is necessary.

I've reported it as a bug, we'll see whether Hert responds with "it's not a bug, it's a feature". I can live with it, if that's his response.

The mapping feature allows multiple mappings per label, e.g. a label at the City level in the Places hierarchy is mapped to photoshop:City,Iptc4xmpExt:LocationCreated.Iptc4xmpExt:City.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 16:54

Yup, Hert says it's by design - it's not a bug. Oh well, as I say, I can live with it.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Re: Mapping Labels to Iptc Location Created

Post by tstoddard » 02 Oct 12 19:04

As for me, I prefer to just assign one label, and know that all the parent labels are automatically assigned.
I'm a little confused. I would assume that what you mean by the above statement is that you have the "Also assign its parents" set to "Yes" in the individual labels. That is what I am doing. One of the points I'm trying to make is that if assigning parent labels automatically then there is no reason to have to process parent mappings. They will get processed when the parent labels are assigned, even if you don't check "also process parent mappings".

What I'd like to determine is whether or not I will cause redundant processing that will result in a performance hit by having the "also process parent mappings" checkbox checked when it is not necessary to check it. In other words, is the code smart enough to recognize that it isn't necessary to process the parent mappings for fields with cardinality of 0..1 if the parent label is going to get automatically assigned, or will it just go ahead and process the mappings twice (or three or more times in the case of a hierarchy with many levels)? In the case of fields with cardinality of 0..1, the result is the same but a lot of unnecessary processing could take place.

I hope this makes sense to you. It's more a matter of curiosity than anything else, but I would also like to know that I'm using the most efficient settings whenever possible.
Tom Stoddard

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 02 Oct 12 19:59

Tom,

OK, I see what you're doing. No I don't use my keywords and place names that way.

The thing about that setting of "Also assign its parents" is that, yes, it will assign the parent labels (all of them!), and write them out as keyword strings as well.

So, you end up with this being written into the IPTC Keywords:

Places/Middle Earth/The Shire/Hobbiton/Bilbo's House
Places/Middle Earth/The Shire/Hobbiton
Places/Middle Earth/The Shire
Places/Middle Earth

That's really not a good way of doing it. It's inefficient, and it's likely to cause interoperability issues with other tools.

I certainly don't want this repetition of keyword strings, all I want is a SINGLE hierarchical keyword in my metadata:
Places/Middle Earth/The Shire/Hobbiton/Bilbo's House

And I don't need to have multiple Catalog labels assigned to the image: Bilbo's House, Hobbiton, The Shire, Middle Earth, for the simple reason that these Labels are also in a hierarchy - so if I search the Catalog for all images that fall under Middle Earth, I will see the image of Bilbo's House, because it's in that hierarchy, even though it doesn't explicitly have the Middle Earth label. That's the power of hierarchies and Catalog labels.

For example, I have a label "Belgian horse". That's actually in a Catalog hierarchy that writes out a keyword string to the image metadata:
Nature/Animals/livestock/horses/draft horses/Belgian horse

So if I search the Catalog for Belgian horse, I'll find that image. If I look at the Catalog at the level of "draft horses", I'll see images of Belgians and Shires. If I look at the Catalog at the level of Livestock, I'll see images of horses, cattle, pigs, sheep as well.

The way I use the tool is never to use that "Also assign parent labels". The only reason I'm using the "Also process parent mapping" is for placenames only, to ensure that the full location data is being stored as metadata in the relevant IPTC Location fields. I don't use it for other catalog labels.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Re: Mapping Labels to Iptc Location Created

Post by tstoddard » 02 Oct 12 22:27

Geoff,

What you say is true but it doesn't work if you don't want to have delimited keywords. This thread is getting off topic at this point but I want to continue it to be certain that I'm not misunderstanding you.
So if I search the Catalog for Belgian horse, I'll find that image. If I look at the Catalog at the level of "draft horses", I'll see images of Belgians and Shires. If I look at the Catalog at the level of Livestock, I'll see images of horses, cattle, pigs, sheep as well.
It depends on what you mean by "look at the Catalog at the level of..."

I assume that when you say you look at the catalog at the level of "draft horses" that you are entering "draft horses" into a search field. When I want to look at my catalog at a certain level, I just click on that level in the category tree. If I'm not mistaken, clicking on "draft horses" in the category tree will not result in all images of Belgians and Shires to display in the catalog viewer pane if you haven't assigned parent labels, even if you do use delimited labels. In PS you will see a thumbnail indicating images in a child category of Belgians and one of Shires but in order to display those images you have to double click on one of those thumbnails and then you will only see images from the category you double clicked on. In order to see all individual images of Shires and Belgians at the same time you need to use some other sort of search technique. It isn't difficult but it's not as convenient as simply clicking on "draft horses" in the category tree. In IDimager, if you click on "draft horses" in the catalog tree, you won't see any images of Shires and Belgians unless you've also explicitly assigned "draft horses" to them as well.

I guess you could say that these are all trade-offs. I hope I'm not belaboring these issues too much. I'm still very new to all of this I'm just trying to decide which way I prefer before I get too far down the road. Sometimes these trade-offs don't become apparent until after you've already done a bunch of work. I appreciate your perspective on all of these issues.
Tom Stoddard

mphillips
Posts: 2035
Joined: 31 May 07 12:02
Location: Parkwood,Johannesburg,South Africa

Re: Mapping Labels to Iptc Location Created

Post by mphillips » 03 Oct 12 6:26

Hi Tom
clicking on "draft horses" in the category tree will not result in all images of Belgians and Shires to display in the catalog viewer pane if you haven't assigned parent labels
In Supreme click on the "Number" Icon (The Round Grey Oval) next to the Catalog Label to display that label and all sub labels (or folders in Folder View) - That will then allow you to display Draft Horse & All Sub Categories like Belgians and Shires - alleviating the need to assign a "higher" level catalog label when sub labels are already assigned.
03-10-2012 07-30-02 AM.jpg
03-10-2012 07-30-02 AM.jpg (122.2 KiB) Viewed 4529 times
In V5 you click on the Orange Dot to achieve the same objective.
03-10-2012 07-27-16 AM.jpg
03-10-2012 07-27-16 AM.jpg (26.21 KiB) Viewed 4529 times
Regards

MikeP
Mike Phillips
http://www.mikeandmorag.co.za
D800, CNX2, Supreme

gcoupe
Posts: 603
Joined: 16 Mar 05 19:29
Location: Heelweg, The Netherlands

Re: Mapping Labels to Iptc Location Created

Post by gcoupe » 03 Oct 12 7:36

Tom,

If the discussion we're having is useful to you, then I'm perfectly happy to continue. There's a lot of power and flexibility in these tools, and, as you say, some of the trade-offs are not always apparent at first. And thanks MikeP for illustrating the fact that when using the Catalog, you can choose whether you call up images just at the level of the Catalog Label, or whether you see all the images in lower levels as well.

I just want to return to the point about whether one uses simple or delimited keywords in the image metadata. That's a choice that is usually made early on.

I can well imagine that if someone is a Pro photographer producing images that will be sold to Stock Libraries, then they would probably want to have simple keywords in the image metadata. And then, you would have the "Also assign its parents" feature switched on for your Catalog Labels. Then, for an image of Belgian horses, instead of just having a keyword "Belgian horse" in the image metadata, you would also have the additional terms from your Catalog automatically added to make a simple list of keywords: "Nature, Animals, livestock, horses, draft horses, Belgian horse".

I've gone down the delimited keywords route for a different reason. Other family members don't use IDI or PS. However, they do use Microsoft's Windows Live Photo Gallery (or Windows Photo Gallery, as the latest version is now called). That does actually understand delimited keywords that have / as the delimiter character. When WPG reads in an image with Nature/Animals/livestock/horses/draft horses/Belgian horse as the keyword, it will automatically construct the same hierarchy from this as the Catalog Label structure in IDI or PS that was used to create it. So all the instances of WPG running on other family members PCs (whether on our home network, or in the houses of relatives) will automatically create and track a common keyword hierarchy. So I set up IDI and now PS to use delimited keywords with "/" as the delimiter. Not all tools have the flexibility of IDI or PS - I couldn't do this with Lightroom, for example.
Geoff Coupe
--------------
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

tstoddard
Posts: 584
Joined: 07 Sep 12 12:51

Re: Mapping Labels to Iptc Location Created

Post by tstoddard » 03 Oct 12 11:59

Mike,

Thanks for showing me that! Now that you have, I do remember reading about that feature in an earlier post. There are so many features hidden in this program that I believe one could use it for years without finding all of them.

Geoff,

Thanks for sharing your reasoning for delimited keywords. You're right about deciding early on, which is what I'm trying to do. Last night I actually changed my options to match what you are doing. I only have about 3,000 images cataloged so far and it took me a couple of hours to make the necessary changes. What I realized is that it is more difficult to remove parent keywords that have already been written then it would be to add them later if you chose to. I wouldn't want to try to do this with a large catalog of images. One feature that I would love to see added to Photo Supreme is the ability to select multiple labels and make changes to them simultaneously. I believe you can do that in IDimager. Doing it one at a time is tedious and error prone. When I went through my existing labels I found that I had some labels configured inconsistently.

Thanks again for all of you input.
Tom Stoddard

Post Reply