Label revocation: findings + comments

Posts: 1594
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: Label revocation: findings + comments

Post by fbungarz » 08 Sep 15 22:39

I never recommended using single keywords. As Vlad states, my recommendation is to use hierarchical keywords.
Sorry if I got that wrong. But now I am really confused!
I thought disabling delimited keywords would result in simple keywords being written? Does that mean if I uncheck delimited keywords only hierarchical keywords will be written?
The preferences say: "write delimited keywords (uncheck for simple keywords; DEPRECATED)". By default the option is disabled. I thought that means two separate sets of keywords are being written; LR hierarchical keywords plus non-hierarchical, simple ones. Are simple keywords written only if both delimited keywords and hierarchical ones are not checked?

BTW - I am sorry that this discussion now has strayed so far off the main topic: label revocation. This was not my intention.

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: Label revocation: findings + comments

Post by Mike Buckley » 09 Sep 15 1:31


If you uncheck Write delimited keywords, the simple keywords will be displayed in the Keywords area of the Descriptions sub-panel. If you also check Write hierarchical keywords, they will be displayed in the lr section of the XMP Advanced sub-panel. To display that sub-panel, click the icon in the very top right corner of the Details panel and select Advanced.

That is the configuration I use and I can't think of a situation that is not covered but it, nor can I think of a situation that is harmed by it.

Posts: 114
Joined: 29 Aug 07 22:34
Location: Germany

Re: Label revocation: findings + comments

Post by bimo » 09 Sep 15 22:48

iptc4xmp:Event can only hold one keyword (Why? – Family Meeting could well occur with Birthday, Christmas, etc.) This field is only cleared when a single assigned Event label is revoked. If several Event labels have been assigned, and the one in iptc4xmp:Event is revoked, the content of that field is replaced with another of the assigned events (which one seems unpredictable). Assigning an additional Event will sometimes cause what is in iptc4xmp:Event to be replaced with the new Event. This too seems unpredictable, although using the as-supplied list nothing seems to displace “Birthday”.
If an Event is explicitly mapped to Iptc4xmpExt:Event the behaviour seems to be the same as mentioned for People (see above). Thus, assigning “Halloween” in addition to “Birthday” will not ordinarily displace the latter from Iptc4xmpExt:Event, but if “Halloween” is explicitly mapped to Iptc4xmpExt:Event then that field will change from "Birthday" to “Halloween”. Also like People, if the Category name “Events” is changed to something else, assigning a label will still impact iptc4xmp:Event.
Charles, might explain why "Halloween" wins the competition.

But, as Vlad already explained, your "multiple Event-issue" can't be solved by PSU, because you ignore the IPTC specs, while PSU follows them.


Posts: 114
Joined: 29 Aug 07 22:34
Location: Germany

Re: Label revocation: findings + comments

Post by bimo » 09 Sep 15 23:03

Hert wrote:
Indeed, that's what I stated above: PSU will not erase manually created mapping or manually added metadata in a catalog label.
This async behaviour of PSU forced me to have a special label ("clear") that erases all that metadata that I (potentially) created by mapping. BTW, I never add metadata directly, always via mapping. And I always do the mapping explicitly, even for events, people and location (LocationCreated and LocationShown)...

I'm satiesfied with that approach.

Posts: 895
Joined: 01 Sep 08 15:20

Re: Label revocation: findings + comments

Post by vlad » 10 Sep 15 11:53

bimo wrote:Charles, might explain why "Halloween" wins the competition.

But, as Vlad already explained, your "multiple Event-issue" can't be solved by PSU, because you ignore the IPTC specs, while PSU follows them.
Michael, I understand the explanation for why "Halloween" wins the competition when it has been explicitly mapped to Iptc4xmpExt:Event. Still, it's not entirely clear why it doesn't win it when it's not explicitly mapped. In a different thread, Charles reported that the (photoshop) location fields always reflect the latest assignment of a location label. I would expect the policies to line up (either first assignment wins or the last assignment wins), irrespective of the label category or the specific mapped field.
This async behaviour of PSU forced me to have a special label ("clear") that erases all that metadata that I (potentially) created by mapping.
That's a clever workaround. I guess you defined a detail profile that simply clears all fields of interest? Does the metadata clearing require that only the "clear" label is assigned, or can that label be assigned in addition to other labels (which may have their own mappings)?


Posts: 46
Joined: 28 May 12 18:21

Re: Label revocation: findings + comments

Post by chuckhebert40 » 29 Sep 15 20:44

Based on the points made by Vlad at the beginning of this thread, I’ve tried to list below issues related to label revocation which I think need addressing. If any of these are based on false premises, please put me right! If there are reasons for preserving the status quo I would really like to understand why.

I am ignoring the processing of keywords and hierarchical keywords following a label revocation. These seem to work fine, apart from the issue about one label being revoked where other(s) remain with the same parent (in Mantis, #2836).

1. I would prefer to see all mappings based on explicit labels
Hert, you have stated that
PSU maintains the Event and People and Place metadata from catalog labels in the respective top category's structure.
This doesn’t according with my experience/understanding in respect of Places.

Provided there is no explicit mapping, then assigning/revoking an Event or People label will indeed generate/clear a metadata entry, but assigning a Place label with no explicit mapping generates no metadata. What is the reason for treating Event and People categories differently from all others?

I would prefer PSU to be consistent. Setting a default mapping for a particular category of label could perhaps best be handled by some form of category-specific template as suggested by Vlad (Mantis #2844).

2. The impact of revoking a label with explicit mapping should be consistent.

The previous issue is a design consideration, but there is another issue concerning People labels and metadata which I am assuming is not intended. If it is intended, why? (Note: this is a current issue which would cease to exist if all mapping was explicit).

As I reported previously,
If various People labels are assigned to an image, and if any of those labels are explicitly mapped to PersonInImage, then only those labels will appear in the PersonInImage field – i.e. they negate the PSU built-in mapping of this field.
I have since realised that if all such explicitly mapped labels are revoked, then metadata is created for any other (implicitly mapped) people labels.

The same consideration applies to Event, although this only allows one value.

This is out of line with the general rule (see next), that revoking a label with explicit metadata mapping will not clear that metadata. (I have come across another example where metadata generated from explicit mapping is cleared when a label is revoked. I mapped three Object labels to Iptc4xmpCore:SubjectCode and assigned them all to one image. I then revoked them one by one. The first two to be revoked were cleared from the metadata; the third was not.)

3. If a label is revoked, the metadata which remains should be as if the label had never been assigned.

As mentioned by Hert,
PSU will not erase manually created mapping
I don’t understand the rationale for this, and am completely with Mke:
I can't think of an obvious reason for not clearing the metadata, nor for why the two cases should be handled differently. It doesn't happen very often, but the normal reason I remove a label is because it was incorrectly assigned - and if I unassign the label for that reason, I wouldn't want incorrect information to persist in the metadata.

The actual process of clearing the metadata cannot simply involve reversal of what happens when the label was assigned; this leads to the issue mentioned in my second paragraph above (& see Mantis 2836). Hence the wording in the underlined sentence above.

4. For any metadata field with cardinality 0..1 the most recent assignment should dictate the content of the metadata field, and in the event of the last-assigned label being revoked the previous last-assigned label should update the metadata field.

If multiple Event labels are assigned, the resultant metadata will always reflect the label with the lowest value. Thus, regardless of the assignment sequence, Birthday will always take precedence over Halloween, which will in turn take precedence over Thanksgiving. Besides being counter-intuitive (I would expect the one most recently assigned would take precedence), it means that if you assign more than one Event label (perfectly plausible) then it is not possible to ensure that a particular value occupies the Iptc4xmpExt:Event field. What I am suggesting for Event (and other single-value fields) is how photoshop:city appears to be handled currently when more than one city label is assigned or the last one revoked.

5. Metadata should be maintained via a Catalog label, or directly, but not both.
(This is an issue, but for us as users, not for PSU if the preceding points have been dealt with)

Earlier I wrote
if I assign "Paris" to an image, and the Country and City fields in the metadata are populated, then if I revoke that assignment then the consequently populated metadata fields should also be cleared.
and in response, Vlad, you said:
That seems logical. But what if you already had France and Paris filled in the Country and City fields even before defining or assigning the Paris label (which simply overwrote the previous field values with identical values)? In this particular scenario, Photo Supreme would actually clear prior info rather than actually reverting to the previous state (where the label was not assigned, but the Country and City info did exist). That's why I've said that complete reversibility, in its true sense, is a difficult
Although I am seeking reversibility, I think that doing it completely in a situation such as you describe, Vlad, is not worth trying to achieve. The issue here, in my view, comes down to one of what are you using to maintain the metadata? There seem to be four places metadata might be created and/or maintained:

(i) the camera (i.e. on the original image)
(ii) software other than PSU (typically pre-import, but possibly subsequently)
(iii) in PSU, directly, using the Details or GEO Tag panels
(iv) in PSU, indirectly, using mapped labels

For the present discussion we can ignore much camera-generated metadata which is unlikely to be changed (e.g. exposure info), or data which might have to be changed directly once, such as date and time of creation. However, other camera-generated data, such as GPS and location info, and people in image (i.e. any data likely to be held in the Catalog), are clearly significant.

In the context of label revocation, any metadata created before importing an image to PSU is essentially the same as metadata from the camera. If metadata is maintained (or corrupted!) by software other than PSU after the image has been imported into PSU, then this could create problems PSU can’t be expected to deal with. This is another way of saying that, once an image has been imported into PSU, then, surely, only PSU should be used to maintain metadata (i.e. (iii) & (iv) above).

If you choose (for example) to set photoshop:city equal to ‘Paris’ directly (e.g. via the Details panel), or it’s come from the camera, that’s OK, and if you decide it should be ‘Prague’ instead you can change it. This would be true even if you have a label for Paris, provided it isn’t mapped to photoshop:city. However, in my book, as soon as you set up a label for Paris, and map it, you are effectively saying “I want to manage ‘Paris’ as metadata using the Catalog.” In the situation you mention, Vlad, if I revoke Paris then I would indeed expect to clear the metadata (and ‘France’ from the Country field if Parent processing was set, and France was mapped). If you have set up a mapped label for ‘Paris’, I can’t conceive why you might want to maintain ‘Paris’ as metadata independently – this seems to be asking for trouble just as much as if you were maintaining the metadata using two different bits of software. The same hazard is there if your original photo metadata contains ‘Paris’ and ‘France’, and in your Catalog you map City fields but not Country fields – you could end up with City = ‘Prague’ and Country = ‘France’. I am keen on consistency from PSU, but clearly there must consistency of approach and data if you are to avoid problems.

I can imagine a situation where my camera has recorded ‘X’ as the city, where ’X’ is a suburb of the city ‘Y’. In this situation, if I create a mapped label for X, all is well. However, if I decide to assign a mapped label for Y then I lose X in the metadata. If the label for Y is not mapped, then I can assign Y, retaining X in the city field, and have Y as a keyword. I could then search for either. (I'm not for a moment suggesting I'd want to do this! However, the possibility is there).

The related issue of GEO data also needs to be considered. My thinking on this is that if you revoke a label which has coordinates, then any coordinates in the metadata should only be removed if they are identical to those on the label.

[Currently, use of the reverse lookup in the GEO Tag panel creates (as necessary) City, State and Country labels, mapped to photoshop and Iptc4xmpExt.LocationCreated fields, so use of this feature would seem to prevent you from keeping the metadata and labels separate - or is there some way to turn off such label generation?]
Charles Hebert

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

Re: Label revocation: findings + comments

Post by gcoupe » 05 Oct 15 13:59

Interesting discussion (and my brain hurts), but one statement prompts a quick question. Charles mentions "camera-generated data such as GPS and location data".

Cameras that generate GPS coordinate data are legion, but are there any cameras on the market that generate textual location info? If so, then indeed "here be dragons"...
Geoff Coupe
Photo Supreme /Windows 10 Pro 64 bits + Windows Home Server 2011 = DAM

Posts: 46
Joined: 28 May 12 18:21

Re: Label revocation: findings + comments

Post by chuckhebert40 » 05 Oct 15 21:57

'Yes' is the answer to your question, Geoff. Mine does, and it's about 18 months old!
Charles Hebert

Posts: 895
Joined: 01 Sep 08 15:20

Re: Label revocation: findings + comments

Post by vlad » 02 Mar 16 14:02

I realize that's a long and old thread, but I would like to finally conclude it with a specific feature request for the developer (Hert). For the sake of transparency and sorting up my own thoughts, here is what I am planning to request:

1) A sensible policy for label revocation, according to a set of global preferences for "Label revocation policy":
1.1) "Delete metadata mapped to label" (Yes | No)
1.2) "Delete metadata mapped to parent labels (when parent mapping processing is set)" (Yes | No)
1.3) "Delete geo coordinates mapped to label" (Yes | No | Only when GEO overwrite is set)

- Simple and hierarchical keywords would always be deleted (like it has always been the case)
- Metadata written via detail profiles applied by labels would never be deleted. (That's a sensible limitation, imho.)
- All settings should default to No, to preserve by default the current (conservative) behaviour
- When unassigning or deleting a label, the metadata controlled by all lower labels should be cleared too (according to settings)
- When relocating (moving) a label, only the metadata mapped to the old parent labels should be cleared (if applicable)
- When merging a label into some other label, the location metadata previously controlled by the merged label should also be cleared (if applicable)
- As we can easily verify for keyword mappings, the clearing of metadata only happens upon write-synching the image(s) affected by the label revocation; if any metadata clearing is always implemented before any metadata writing (and that already appears to be the case!), then I would expect all cases to be correctly and smoothly handled.
(For example, say labels Paris and Lyon are both set to process the parent mappings and they have a common parent label France ; if labels Paris and Lyon are both assigned to an image, then the country metadata mapped to France is also going to be written; then, if label Lyon is unassigned, the metadata mapped to France will still be preserved, since it is going to be rewritten when assigned label Paris is re-processed.)

2) If one or move label revocation settings are enabled, then we should be shown a confirmation dialog, along a warning (about possible metadata cleanup, which could not be easily restored), whenever we delete one or more catalog label. (Of course, we should be able to disable the subsequent display of the confirmation dialog.)

Although the fine details, along with the past discussions, might give the appeareance of a complex feature, I actually expect that it would work very smoothly (just like label assignment already does, despite its intrinisc complexities). It would considerably improve the management of metadata (by following the natural principle of reversibile changes), for whoever cares about sensible metadata cleanup. (If you don't care about that aspect, you should not see any visible change, assuming the backwards compatible settings.)

Before I'm heading to Mantis: did I miss anything important? do you have any additional, specific suggestion or ammendment?

Posts: 895
Joined: 01 Sep 08 15:20

Re: Label revocation: findings + comments

Post by vlad » 08 Mar 16 20:59

I have just submitted the above proposal in Mantis:

Thanks to all who have contributed comments, insights and suggestions throughout the thread.

Post Reply