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?]