Location labels and fields in Photo Supreme 3

[chuckhebert40]

Whatever the history, Michael, if PSU allows me to map a label to a Iptc4xmpExt:LocationShown field, then I would expect that field to be populated. It isn’t, and the same applies if I specify Iptc4xmpExt:LocationCreated fields. In checking this, I have discovered another anomaly.

In the global Synchronize Settings I have the Write settings “Include all parent level labels as keywords” and “Write hierarchical keywords”.

In the Catalog I have a hierarchy North America::United States::Illinois::Chicago. Each of the last three is mapped to the appropriate photoshop and Iptc4xmpExt:LocationShown fields, and has “Process parent mapping” checked. None of them assigns parent keywords.

If I assign Chicago using the Assign panel, dc:subject, lr:hierarchicalSubject and photoshop fields (City, State & Country) are created as expected. However, as previously reported, no Iptc4xmpExt fields are created.

Under Illinois I also have Springfield. The settings are as for Chicago except that no mapping is specified, and “Process parent mapping” is not checked. If I assign Springfield, the Photoshop City field is blank (as expected). However, the photoshop State and Country fields are populated. Why? I would not expect this, since there’s no Parent process mapping. I can stop this by removing the global setting “Include all parent level labels as keywords”, but this doesn’t seem appropriate; I have always assumed that the term ‘keywords’ is used to refer only to the content of dc:subject and lr:hierarchicalSubject, but not to metadata more generally (such as State and Country fields). I presume this is a bug; if I specify that a label is not to create a keyword, then (apart from the reported location problem) it still creates mapped metadata fields, as I’d expect.

[tstoddard]

I can confirm what Charles is saying. I have city, state, and country labels mapped to the IptcExt "location created" fields and I have the city and state labels configured to process parent mappings. I do not write keywords for any of these labels and my global setting to "include all parent level labels as keywords" is not checked. I just now looked at recent images that I've applied city labels to and I found that the location created fields are not getting populated. I looked at a city label that I use quite frequently and found the I have files from March 29, 2015 in which those fields did get populated but then files labeled since April 5, 2015 do not have those fields populated. This appears to be a bug. The "whatsnew" page doesn't give the dates on which the updates were released so I'm not sure if an update was released sometime between those two dates or not but if I was a betting man, I'd bet on it. I don't have time now to investigate but I will do so when I get a chance.

Thanks for pointing this out, Charles.

[Edit] - I should have mentioned that I also have those fields mapped to City, State, and Country tags under "Image Content", which are not IPTCext fields. Those fields are getting populated.

[bimo]

I looked at a city label that I use quite frequently and found the I have files from March 29, 2015 in which those fields did get populated but then files labeled since April 5, 2015 do not have those fields populated. This appears to be a bug.

Tom, I totally agree with your finding. I opened Mantis 2879 already on 2015-06-07 http://bugs.idimager.com/view.php?id=2879 - but no fix up to now!

@Charles: BTW as far as I can see, the LocationCreated fields are populated if using the GEO-Panel. But with mapping they aren't because the data then is written to the wrong fields (values are written to e.g. "City" instead of "LocationCreatedCity"; "City" doesn't exist in the specs for IPTC-Extension).

LocationShown works with mapping in the following manner:

Location-Shown: Detail profile instead of mapping

lshown_2.JPG (32.17 KiB) Viewed 8106 times

Detail: ...and it works...

lshown.JPG (27.69 KiB) Viewed 8106 times

HTH?!

[tstoddard]

bimo,

Thanks, I'll add to that mantis ticket once I'm at home and can describe accurately what my configuration is and what has been happening to me. Like you said, it used to work at expected but doesn't any longer. I don't want to speculate on the reason, I just want it to work right. Hopefully we can work together in mantis to get this issue recognized as a bug and corrected.

[vlad]

As an interim summary, here is what I've gathered from the latest posts:

1) There is an outstanding bug concerning the mapping of a label to Iptc4xmpExt:LocationCreated or to Iptc4xmpExt:LocationShown. The bug is already reported in Mantis (#2879) by Michael and confirmed here by both Charles and Tom.

(As an aside: do I remember correctly that the default Places hierarchy, shipped with the latest PSU build, specifies eplicit label mappings, including Iptc4xmpExt mappings?)


2) There is a different bug reported in this thread (but not on Mantis) by Charles: “Include all parent level labels as keywords” incorrectly triggers the processing of custom mappings in parent labels.

Charles, I would encourage you to formally report that bug in Mantis. (As I've already written, I had reported a similar bug (2161) regarding parent label profiles - but that was promptly fixed in V2. I can't test right now if #2161 has since reappeared.) And, just for the sake of the thread topic, you may want to check if that bug is restricted to location mappings. (I wouldn't think so.)


FYI, I submitted (in February) the suggestion to include the build dates on the "What's New" page - feel free to vote for it: http://mantis.idimager.com/view.php?id=2779

[vlad]

I looked at a city label that I use quite frequently and found the I have files from March 29, 2015 in which those fields did get populated but then files labeled since April 5, 2015 do not have those fields populated. This appears to be a bug. The "whatsnew" page doesn't give the dates on which the updates were released so I'm not sure if an update was released sometime between those two dates or not but if I was a betting man, I'd bet on it.

Tom, did you turn on the ICS writing? Even if the changelog does not (yet) include the build dates, the ICS metadata should already include both a timestamp and a build number (see Mantis #2778, marked as resolved on 2015-02-10). Could you check the build numbers recorded in your files from March 29 vs April 5? (If I was a betting man, I would bet on your side too.)

[tstoddard]

vlad,

I do have writing to ICS on.

Here's what I found in my xmp file for a picture from 4/5/2015:

Code: Select all

<rdf:Description rdf:about="" xmlns:ics="http://ns.idimager.com/ics/1.0/" ics:ImageRef="93422F87634BDB90925A7084F6E" ics:TimeStamp="2015-04-05T19:56:35.415-04:00" ics:AppVersion="IDimagerSU 3.1.0.2067">

In a file from 3/29/2015 I found this:

Code: Select all

<rdf:Description rdf:about="" xmlns:ics="http://ns.idimager.com/ics/1.0/" ics:ImageRef="393F5B5A424EBA93C174587DEEF">

There is no AppVersion attribute in this file.

Oddly enough, very few of my files seemed to have the AppVersion embedded. I did find one from 3/29/2015 that does include it:

Code: Select all

<rdf:Description rdf:about="" xmlns:ics="http://ns.idimager.com/ics/1.0/" ics:ImageRef="B53D16384144E9CB9D7BE0F9C96" ics:TimeStamp="2015-03-29T09:59:33.287-04:00" ics:AppVersion="IDimagerSU 3.0.3.2066">

I found this very strange. I do use Photo Ninja to process most of my raw files and I have had issues with PSU and Photo Ninja not agreeing on how to write xmp files, so I looked at a few more files from a wide date range. I was able to isolate one characteristic that differs consistently between the ones that show an AppVersion and the ones that do not. The ones that show it are raw files that I never rendered to jpegs in Photo Ninja, which means I would not have saved any changes to those files from withing Photo Ninja. This made me think that it is possible that Photo Ninja was responsible for removing the Iptc4xmpExt:LocationCreated data, however, after further examination I found that even the files that do show the AppVersion attribute still do not have anything written to the Iptc4xmpExt:LocationCreated tags. Both files do have data written to the photoshop:city, photoshop:state, and photoshop:country fields.

Based on what I've found so far, I still believe that PSU is not writing to the Iptc4xmpExt:LocationCreated fields and that the change occurred between build 2066 and 2067.

Before posting this, I decided to do one more test. I took a file from 3/29/2015 that had data in the Iptc4xmpExt:LocationCreated fields and I removed the city label that had been assigned to it. Nothing changed in my Iptc4xmpExt:LocationCreated fields after removing that label. Then I assigned the same label again to that file and the data in the Iptc4xmpExt:LocationCreated fields disappeared. I am now pretty certain that PSU is doing this.

Here's the difference between a file from 3/29/2015 that still has the data and one that doesn't:

Code: Select all

<rdf:Description rdf:about="" Iptc4xmpExt:City="Dillsburg" xmlns:Iptc4xmpExt="http://iptc.org/std/Iptc4xmpExt/2008-02-29/" Iptc4xmpExt:CountryName="United States" Iptc4xmpExt:ProvinceState="Pennsylvania">
      <Iptc4xmpExt:LocationCreated>
        <rdf:Bag>
          <rdf:li>
            <rdf:Description rdf:about="" xmlns:Iptc4xmpExt="http://iptc.org/std/Iptc4xmpExt/2008-02-29/">
              <Iptc4xmpExt:City>Dillsburg</Iptc4xmpExt:City>
              <Iptc4xmpExt:CountryName>United States</Iptc4xmpExt:CountryName>
              <Iptc4xmpExt:ProvinceState>Pennsylvania</Iptc4xmpExt:ProvinceState>
            </rdf:Description>
          </rdf:li>
        </rdf:Bag>
      </Iptc4xmpExt:LocationCreated>
    </rdf:Description>

<rdf:Description rdf:about="" xmlns:ics="http://ns.idimager.com/ics/1.0/" ics:ImageRef="B53D16384144E9CB9D7BE0F9C96" ics:TimeStamp="2015-03-29T09:59:33.287-04:00" ics:AppVersion="IDimagerSU 3.0.3.2066">

Code: Select all

<rdf:Description rdf:about="" Iptc4xmpExt:City="Dillsburg" xmlns:Iptc4xmpExt="http://iptc.org/std/Iptc4xmpExt/2008-02-29/" Iptc4xmpExt:CountryName="United States" Iptc4xmpExt:ProvinceState="Pennsylvania"/>

<rdf:Description rdf:about="" xmlns:ics="http://ns.idimager.com/ics/1.0/" ics:ImageRef="482CA0BE7A4538A2C7D6EA0E479" ics:TimeStamp="2015-09-21T17:38:48.433-04:00" ics:AppVersion="IDimagerSU 3.1.1.2070">

[tstoddard]

Okay, I know, I need to take this information to Mantis. I will.

[tstoddard]

I noticed that the Mantis Issue related to this problem is incorrectly marked as Photo Supreme V2. Do you suppose it is getting overlooked because of that? Is it possible to correct that in Mantis somehow without having to repost all of the information related to it?

[chuckhebert40]

Vlad, I’ve reported in Mantis #2914 the issue of the global setting “Include all parent level labels as keywords” causing parent level mapping.

I thought I would check whether the non-creation of metadata only applied to location labels, and experimented with a few object and people labels (the former not being subject to special processing built into PSU for places, people and events). My brief testing suggests that there is a general problem with metadata generation where the PSU name for the metadata field is of the form Iptc4xmpExt:xxxx.Iptc4xmpExt.yyyy (which includes the location labels we've been discussing). I've added a note to that effect in Mantis #2879, also noting there that I have some images where metadata has at some stage in the past been created for Iptc4xmpExt:PersonInImageWDetails.Iptc4xmpExt:PersonName, supporting your observation, Tom, that this appears to be a recent problem..

[vlad]

OFF TOPIC (but it would be on topic for the Bug Reporting & Feature Requests thread):

I noticed that the Mantis Issue related to this problem is incorrectly marked as Photo Supreme V2. Do you suppose it is getting overlooked because of that?

I have had similar concerns with other open tickets marked as V2 or even V1 (either incorrectly reported as such, or indeed reported in a previous version but still applicable today). IIRC, Hert mentioned (in Mantis) that any open ticket is still on the record, no matter what the project marker says.

(That's reassuring but it doesn't say anything about priorities. Could a ticket be deferred and slip under the radar just because it is marked with an older version? Maybe yes, maybe no. If we're going into speculation territory, I'd rather presume that a ticket's "freshness" factor might involve the number and recency of follow-up notes, and those may thus have a bigger impact on the ticket saliency. Perhaps Hert could reveal his secret receipe for bug & feature priorities, but I'm not holding my breathe. )

Is it possible to correct that in Mantis somehow without having to repost all of the information related to it?

Afaik, only the administrator (Hert) could do that.

[Mke]

Vlad, your request for a map in the label details will be added to the next update.

Thanks again - good to see that it's made it! Though it had me fooled for a moment - I was looking for the globe icon...