Parent keywords and parent label assignment: pros and cons

[vlad]

As you all know, PSU has a great deal of settings - in particular, label and keyword settings - and there are frequent discussionss on which settings (or particular combinations of settings) are considered good practice and which are not. However, the discussions generally take place in the context of specific issues, therefore a high level overview of the pros and cons may still be missing.

Two particular settings that I often see recommended are "Write hierarchical keywords" and "Write catalog data to IDimager ICS scheme". I don't remember ever finding or reading arguments against them, so I will assume that enabling both of them is good practice. (We don't need to take this as gospel: if someone disagrees, then please explain why.) This said, I would like to raise here the more general DAM issue of writing parent keywords to the standard keyword field (xmp:dc:subject) and the PSU specific issue of parent label assignment. (They are not quite the same thing, although they are closely related.) I often see recommendations against those practices (generally dismissed as "not needed"), but I am not convinced their pros and cons have been considered and compared in detail (in a single dedicated thread, that is). I am laying down here my own analysis - hopefully it's not too flawed or hard to follow.


Part 1: Writing parent keywords to the standard keyword field (xmp:dc.subject)

Pros:
(1) Allows external tools and platforms that do not support hierarchical keywords (e.g., Picasa, Flickr) to read and expose all the applicable keywords (for image grouping, searching and filtering purposes).
(2) Increases the number of keywords per image and therefore the chances to find the cataloged images on commercial sites, platforms etc. (This is probably a pro for stock photographers. LATER EDIT: The previous statement is in question - see Mike Buckley's comments bellow.)

Cons:
(1) Duplicates information already available in the hierarchical keywords field (lr:hierarchicalSubject).
(2) May lead to an overly large number of keywords. Less is more (...unless you're a stock photographer?).
(3) May lead to keywords with a weak relevance (or even completely irrelevant) outside the PSU cataloging.
(4) May have a small performance impact in PSU (although it's likely negligeable).

My comments:

As you could see, most of the cons (1-3) actually refer to the same drawback: informational noise. A big case is sometimes made of the duplication with hierarchical keyword field. However, I do not fully understand the argument, because the complete keyword hierarchy info is available in the lr:hierarchicalKeywords and, as long as it is used, any flat keyword in xmp:dc.subject (including a leaf keyword) is by definition redundant (not needed). Similarly, storing the ICS schema introduces duplication and redundancy too (w.r.t. keywords), but it is considered good practice (and I do agree with this). I am therefore not entirely sold on the redundancy + duplication cons arguments, as long as I regard the first pro (that is: non-reliance on only those platforms which read and interpret correctly the hierarchical keyword field) to be a quite important one. Am I alone here?


Part 2: The automatic assignment of parent labels

Assuming a PSU user does want to write the parent keywords to the image - presumably because he/she has determined the pro(s) to outweigh the cons above - (s)he has at least three ways to achieve that using the PSU labels:
1) Assigning the parent labels manually
2) Enabling the global setting: "Include all parent level labels as keywords" (can be overriden only via private labels)
3) Enabling the setting "Also assign its parents" in every leaf or midlevel label (with possible exceptions)

The first one is obviously quite error-prone (assuming the parent keyword writing is desired across all - or most - hierarchies), while the second one is pretty much transparent in PSU. I would like to discuss the pros and cons of the third, which I think is the most controversial.

Automatically assigning parent labels

Pros:
(1) Allows easy filtering by parent label for any collection (using the label filter or the new text filter).
(2) Allows easy searching by parent label (using the search bar), optionally in conjunction with other criteria.
(3) May lead to useful label suggestions inside LAP. (N.B.: this is just my hypothesis; could anyone comment on that?)
(4) It may be used in conjunction with other label settings (such as field mappings or applied profiles) to implement a powerful workflow. (N.B.: this is a pro only for advanced users who know what they are doing; it could easily turn into a cons.)

Cons:
(1) Increases the number of assigned labels, making them harder to manage in a number of ways. (Two specific examples bellow.)
(2) Increases the number of labels in LAP, and that could make it harder to spot which labels ought to be added and which labels ought to be removed (for a given image selection).
(3) Increases the list of labels available in the label filter dropdown, possibly to the point where the list becomes overloaded and requires scrolling.
(4) Conflates the information provided by hierarchical and non-hierarchical label views inside Catalog Explorer (i.e., clicking on the image counter vs. to the left of it). Sometimes it can be useful to discriminate between the content provided by those two view modes (e.g., see the next point).
(5) It is (obviously) incompatible with a (arguably useful) convention that requires only leaf labels to be assigned to images.
(6) The current handling of automatic parent assignment is very fragile with respect to structural catalog changes (label merges + relocations).
(7) The setting may (unintentionally) interact with other label settings (such as metadata mappings or applied profiles) and lead to subtle, unpredictable and/or undesired side effects.
(8) May have a small performance impact.

My comments:

The list of cons against the automatic assignment of parent labels is quite long, but I find the first two pros to be quite significant. It is great to be able to quickly filter on a label and know you get all the images under that hierarchy. (Yep, the hierarchical search is available also in the catalog explorer + dynamic searches + favorites - it's just that the filter bar is very convenient and I use it a lot.)


Conclusions

Well, despite undertaking this analysis (mainly for my own decisions and benefits), the bad news is that I haven't actually reached a firm conclusion yet. It seems to me that the case for or against writing parent keywords - and how to implement this decision, once determined - is not clear cut and hence it is still fair game for debate. (Actually, a fair conclusion might turn out to be: it is a matter of user's priorities. But, if one clearly favors simplicity, he should better not worry about parent keywords and labels.) As far as I'm concerned, I'm not sure if I should proceed forward using automatic parent asignment or not. (The bulk label editing in V3 has made the auto-assignment option tempting and apparently easy to change and experiment with, but that facility does not actually simplify the implications for label changes and for already cataloged images - see cons 6 above.)


Am I overthinking this? (I bet I am.) Any comments, corrections or conclusions are more than welcome. (Please keep in mind, though, that a worthy goal for most users is to end up with a shorter overview, not a longer one. )

Have a great weekend,
Vlad

[tstoddard]

vlad,

I have a couple of questions that are not answered by your analysis.

1. If I set my child label to "process its parent's mappings"(not sure if that is the exact wording of that setting), and the parent label is set to write a keyword, will the parent label be written as a keyword even if I do not assign the parent label? I believe that it will but I'm not able to test that right now. My point in mentioning this is that, if I'm correct, it allows users to write parent labels as keywords without assigning those parent labels. I personally find this much more desirable than having to assign a parent label in order to get a flat keyword written for that label.

2. I've never used the global setting to "include all parent level labels as keywords" so I don't know how it works. My main question about it is: Will a keyword be written for parent labels that are set not to write keywords?

2) Enabling the global setting: "Include all parent level labels as keywords" (can be overriden only via private labels)

If your analysis is correct, then the local setting to "not write a keyword" will be overridden by the global setting. This is counter intuitive to me since I'm accustomed to working with other structured programming environments where local settings almost always take precedent over global settings. (Style sheets for example)

Perhaps we are both overthinking this issue but it is a good example of just how complex the logic behind a DAM application is.

[Mike Buckley]

It's clear that you gave everything a tremendous amount of thought. Such thought surely leads you to an informed opinion, which is really the only thing that matters. You have laid out everything so clearly that anyone who has gotten far enough into Supreme to understand the details that you explain can make their own decision. I strongly believe that once someone fully appreciates all of the consequences of a particular decision, which unfortunately requires considerable use of Supreme, each of us will make our own decision based on two primary factors: how our brain works and how we tend to use Supreme.

How is writing to the IDimager ICS scheme a duplication or a redundancy regarding keywords?

Two ways to look at the issue of writing parent keywords: If the two "pro" items aren't important to the user, the four "con" items are the reasons not to write them. The corollary is that if the two "pro" items are important, you better make sure they're really important; otherwise, you have to put up with all of the "con" items.

Even so, I'm not sure your second "pro" item pertaining to writing parent keywords is actually a benefit. I would need to see responses from people very familiar with the best practice of tagging images for professional use to be sure that it is a benefit. I've read that if a particular keyword brings up far too many images to wade through, people conducting the search will move onto another photographer. As an example, if the professional searcher wants to see your photos displaying forks, the ideal keyword is "fork," not "flatware" (because that one also will display photos of the spoons and knives).

[vlad]

Tom and Mike: thank you very much for your very good feedback. Some answers and comments bellow:

1. If I set my child label to "process its parent's mappings"(not sure if that is the exact wording of that setting)

To be pedantic, the exact wording is "process parent mapping" (singular), but this is double misleading, because:
1) It will apply all custom mappings defined across the entire parent chain, even if no other parent label has that setting enabled. (This is consistent with the automatic assignment of all parent labels.)
2) The same label may have multiple mappings (that is, it could be mapped to multiple fields).

I suggested in Mantis the change of wording to plural form: "process parent mappings". (Second thought: "process all custom parent mappings" would be even more clear - see bellow.)

Ok, take 2 on your question:

1. If I set my child label to "process its parent's mappings"(not sure if that is the exact wording of that setting), and the parent label is set to write a keyword, will the parent label be written as a keyword even if I do not assign the parent label? I believe that it will but I'm not able to test that right now.

I investigated a bit earlier and discovered that is not the case! I guess the intention is to be able to cascade only the custom mappings (specified via the 'Mapped to' setting, e.g. for writing up location info), without necessarily writing the labels as keywords too. There is a catch: you could define the keyword mapping as an explicit mapping (to 'dc:subject') and then the parent label will indeed be written as a keyword. However, this approach/workaround should be avoided, as I discovered a very dangerous side effect (reported as bug #2719)!

My point in mentioning this is that, if I'm correct, it allows users to write parent labels as keywords without assigning those parent labels. I personally find this much more desirable than having to assign a parent label in order to get a flat keyword written for that label.

I understand, but you can't achieve this the way you thought - you have to use the global setting (see bellow).

2. I've never used the global setting to "include all parent level labels as keywords" so I don't know how it works. My main question about it is: Will a keyword be written for parent labels that are set not to write keywords?

Fortunately, no.

2) Enabling the global setting: "Include all parent level labels as keywords" (can be overriden only via private labels)

If your analysis is correct, then the local setting to "not write a keyword" will be overridden by the global setting.

Nope, it's the other way around (exactly like I had written just above).
(EDIT: By private labels I actually meant in this context also the "semi-private" labels (those with "do not write a keyword"). I'm sorry for the misunderstanding.)

This is counter intuitive to me since I'm accustomed to working with other structured programming environments where local settings almost always take precedent over global settings.

Yep, that's the case in PSU too: the local (label) setting takes precedence. It works as expected.

Perhaps we are both overthinking this issue but it is a good example of just how complex the logic behind a DAM application is.

Exactly my thoughts!

I strongly believe that once someone fully appreciates all of the consequences of a particular decision, which unfortunately requires considerable use of Supreme, each of us will make our own decision based on two primary factors: how our brain works and how we tend to use Supreme.

Yes, I completely agree!

How is writing to the IDimager ICS scheme a duplication or a redundancy regarding keywords?

I perhaps used the wrong words - or expressed the wrong idea. What I had in mind is that the hierarchical labels (keywords) are written inside ics:TagStructure, so all the keyword information is there! (It's just that the ics:TagStructure field is of no use inside any tool other than PSU - but that's precisely the case of certain tools with respect to lr:hierarchicalSubject: they don't even read it; that may change in the future - meanwhile, dc:subject is pretty much universally recognized, AFAIK.)

Two ways to look at the issue of writing parent keywords: If the two "pro" items aren't important to the user, the four "con" items are the reasons not to write them.

You are absolutely right.

The corollary is that if the two "pro" items are important, you better make sure they're really important; otherwise, you have to put up with all of the "con" items.

Thanks for making this explicit and crystal clear, that's very useful! (So far I have pretty much resisted the temptation to automatically assign parent labels, so I may stick with "Include all parent level labels as keywords". I do have that setting enabled at the moment.)

Even so, I'm not sure your second "pro" item pertaining to writing parent keywords is actually a benefit. I would need to see responses from people very familiar with the best practice of tagging images for professional use to be sure that it is a benefit. I've read that if a particular keyword brings up far too many images to wade through, people conducting the search will move onto another photographer. As an example, if the professional searcher wants to see your photos displaying forks, the ideal keyword is "fork," not "flatware" (because that one also will display photos of the spoons and knives).

Mike, you are right, but what about the reverse: if a professional searcher wants to see various flatware, shouldn't he also find your fork photos? (Well, I guess not...) In any case, I do admit about this possible "pro" being just my own uninformed speculation and I am ready to qualify it or completely withdraw it.

One thing is for sure: these days the emphasys in any knowledge based field (with DAM and keywording being just particular instances) should be on relevance and quality rather than pure quantity. As a matter of fact, that's where I expect some of the most exciting technological advances, especially in the medium to long term. (And, as Mike rightly remarked, in the end it's all about how our brains work, with all their universal traits + individual differences. I therefore predict cognitive sciences are going to play an increasing (though possibly covert) role in shaping the truly smart technologies of the future.)

(I guess my last was paragraph was slightly off-topic but, what the heck, it's the weekend )

Regards,
Vlad

[Mike Buckley]

the case of certain tools with respect to lr:hierarchicalSubject: they don't even read it

That's a perfect example of each of us having potentially very different needs. I couldn't care less that other tools don't read that metadata field, yet I understand that that might be really important to others.

Even if it was important to me to upload photos to a web site that doesn't search that metadata field, I would probably write the parent labels only to the image files being uploaded. I would do that by changing the pertinent Preferences setting, writing the catalog information to the files being uploaded, and then reverting the Preferences setting to the setting I normally use. This would work for me because I upload only 1% of my images to a web site.

That leads to perhaps an important idea: Preferences settings don't have to remain constant; they can be temporarily changed to suit particular needs.

[Mike Buckley]

By the way, considering the mass adoption of Lightroom, I'm amazed to learn that there are still so many web sites and tools that don't read that metadata. I first came upon IDimager V4 in 2008 and it was reading it way back then.

[vlad]

Frankly, I don't know how many they are (among the established ones) - but I do know there are some. And it's not clear (to me) what is the trend: IIRC, Google Photos does not even have flat keywords (but perhaps they are still read upon uploading?), although the old Picasa platform certainly read, exposed and made use of (non-hierarchical) keywords.

[tstoddard]

Ok, take 2 on your question:

1. If I set my child label to "process its parent's mappings"(not sure if that is the exact wording of that setting), and the parent label is set to write a keyword, will the parent label be written as a keyword even if I do not assign the parent label? I believe that it will but I'm not able to test that right now.

I investigated a bit earlier and discovered that is not the case! I guess the intention is to be able to cascade only the custom mappings (specified via the 'Mapped to' setting, e.g. for writing up location info), without necessarily writing the labels as keywords too. There is a catch: you could define the keyword mapping as an explicit mapping (to 'dc:subject') and then the parent label will indeed be written as a keyword. However, this approach/workaround should be avoided, as I discovered a very dangerous side effect (reported as bug #2719)!

vlad, it works for me. Perhaps you are not understanding me or the settings you have tested are different than mine but I just tested this on my machine and it does work as I originally stated. I will give you an example.

I have a label named "Butterfly" that has a child label "Swallowtail" that has a child label "Eastern Tiger". All three labels are set to "Create keyword for this label" in their metadata settings. "Swallowtail" and "Eastern Tiger" also have the "Process parent mapping" enabled and "Also assign its parents" is set to "No". I do not have the global setting to "Include all parent level labels as keywords" enabled. When I assign the "Eastern Tiger" label to a file, the detail panel shows that three keywords are added, "Butterfly", "Swallowtail", and "Eastern Tiger". The "Butterfly" and "Swallowtail" labels are not assigned to the file.

This is the behavior I was referring to in my original post. Is this not what you understood? It is also possible that something has changed in PSU. I have not tried creating new labels and testing this behavior. The three labels I am using for this example were all created long ago in PSU.

[vlad]

That leads to perhaps an important idea: Preferences settings don't have to remain constant; they can be temporarily changed to suit particular needs.

That's a good point - and it may be worth a seperate discussion. For now, I would only note the following caveats:
1) Certain setting changes affect already cataloged images (even if they are in sync), while others do not (they apply only moving forward).
2) Reversing certain setting changes may not revert the catalog and metadata state to exactly the previous state.

Setting changes can indeed suit particular needs on a temporary basis, but one ought to be cautios about which settings to change and which effects (including side effects) to expect.

By the way, considering the mass adoption of Lightroom, I'm amazed to learn that there are still so many web sites and tools that don't read that metadata. I first came upon IDimager V4 in 2008 and it was reading it way back then.

Geting back to this, here is my take 2:

1) IDImager has always been at the forefront regarding compatibility with the adopted and de facto standards. (At least that's the impression I've got since 2008, when I first came upon IDimager too.)
2) I've heard it repeatedly here that there are still tools (some in widespread use, like GeoSetter) that still write incomplete or incorrect data to XMP. Is this less surprising than not universally reading the hierarchical keywords? (For all its fast paced reputation, the software and IT world is sometimes surprisingly slow to adapt or correct mistakes.)
3) It may be important to distinguish between professional photo requirements, apps, tools, websites vs. those targetted to the larger photo market. Are the Lightroom keywords universally interpreted at least within the former category of software?

I have a label named "Butterfly" that has a child label "Swallowtail" that has a child label "Eastern Tiger". All three labels are set to "Create keyword for this label" in their metadata settings. "Swallowtail" and "Eastern Tiger" also have the "Process parent mapping" enabled and "Also assign its parents" is set to "No". I do not have the global setting to "Include all parent level labels as keywords" enabled. When I assign the "Eastern Tiger" label to a file, the detail panel shows that three keywords are added, "Butterfly", "Swallowtail", and "Eastern Tiger". The "Butterfly" and "Swallowtail" labels are not assigned to the file.

This is the behavior I was referring to in my original post. Is this not what you understood? It is also possible that something has changed in PSU. I have not tried creating new labels and testing this behavior. The three labels I am using for this example were all created long ago in PSU.

Tom, I understood what you suggested but that does not work for me - I've just tried to replicate it again using three new labels, named and set up exactly as you mentioned. (Note that I had also disabled "Include all parent level labels as keywords" before this.) For me, only Eastern Tiger is added to the keywords. Could you please try it again with three brand new labels? (I'm using the latest build: 2060.)

[Mike Buckley]

1) Certain setting changes affect already cataloged images (even if they are in sync)
2) Reversing certain setting changes may not revert the catalog and metadata state to exactly the previous state.

Such as? I ask because I reviewed all of the Preference settings and I didn't notice any that seemed to be a concern.

[vlad]

1) Certain setting changes affect already cataloged images (even if they are in sync)
2) Reversing certain setting changes may not revert the catalog and metadata state to exactly the previous state.

Such as? I ask because I reviewed all of the Preference settings and I didn't notice any that seemed to be a concern.

Sorry for any confusion:

You specifically mention(ed) the Preference (global) settings and I don't think any change there affects images which are already in sync. (They can still affect OOS images - but this should concern only users like me, who have auto-write syncing turned off.) Also, regarding my 2nd warning: for example, if you enable "Include all parent level labels as keywords", then write metada to file (Ctrl+S) for some image, then disable the option and write-resync the same image yet again, don't expect the parent level keywords to magically disappear in *all* cases! (Specifically: if you set the write preference for keyword processing to "Replace keywords with Catalog labels", the parent keywords will be erased, but otherwise they will stick. So, the global setting interactions do matter and some changes are not easily reversed by simply reverting the settings.)

However, my overriding concern has been with the local (label) settings. (Again, I had overlooked your specific mention of Preference settings.) For example, specifying a custom mapping in a label triggers an out-of-sync signal, while enabling or disabling the auto-assignment of parent labels does not.

[Mike Buckley]

So, the global setting interactions do matter and some changes are not easily reversed by simply reverting the settings.

Agreed.

[tstoddard]

Tom, I understood what you suggested but that does not work for me - I've just tried to replicate it again using three new labels, named and set up exactly as you mentioned. (Note that I had also disabled "Include all parent level labels as keywords" before this.) For me, only Eastern Tiger is added to the keywords. Could you please try it again with three brand new labels? (I'm using the latest build: 2060.)

vlad, I created new labels and they behaved the way you describe. This leads me to believe that PSU has changed the way in which it implements these actions. I find this very disconcerting. Having two labels that show the exact same details but behave differently based on when they were created is not good form. Also, I prefer the way that the old labels behave so I hope the difference turns out to be a bug in the way that new labels are acting. I guess I need to go to mantis with this one.

I have submitted an issue (#2721) in mantis to report this behavior.

[chuckhebert40]

A timely discussion, since for various reasons I have been checking my use of catalog labels, and the various PSU switches which affect what is written to image files. Thanks for the very useful posts. (I’m a sporadic user of PSU, and my knowledge is distinctly sketchy).

vlad, I created new labels and they behaved the way you describe. This leads me to believe that PSU has changed the way in which it implements these actions. I find this very disconcerting. Having two labels that show the exact same details but behave differently based on when they were created is not good form. Also, I prefer the way that the old labels behave so I hope the difference turns out to be a bug in the way that new labels are acting. I guess I need to go to mantis with this one.

I agree that only the assigned catalog label (the lowest in the hierarchy) is written to the image. However, I question whether this has changed. I have gone back to a clean (empty) installation of PSU v2, and in build v2.0.0.1016 (the one I was recently using until recently) the behaviour was exactly the same. I have also checked in v1 (1.8.1.129), and the behaviour there too appears to be the same, although the metadata switch which in v2 & v3 is “Create keyword for this label” in v1 was the reverse: “Do not create keyword for this label”. Prompted by the metadata on lots of my photos, I wonder, Tom, whether your apparently inconsistent results hark back to using IDImager. Whatever the situation, I would agree that if I have selected “Process Parent Mapping” in the Metadata settings for a catalog label, then I would expect the parent to be written to the image. [One change I have noticed between v2.0.0.1016 and v3.0.2.2060 is that if you have chosen “Also assign its parent” for a label, then if you remove that label PSU now removes the parent also, which it didn’t previously – it’s now more consistent. This is not mentioned in the “What’s new” document for v3, but maybe it was introduced in one of the later v2 releases which I haven’t used].

Question: what is the best tool for reading the metadata written to jpg image files. I have been using EXIFTool, but it isn’t exactly friendly. I have tried several other programs, but most of them don’t cope (adequately, or at all) with XMP data. XnView (mentioned by gaikokujinkyofush in the syncing issues thread) does, but that too is a bit of a pain to read.

For image management (DAM) I am only interested in using PSU, and as long as it works I clearly do not need to use the “Also assign its parent” facility. Using that facility, then if hierarchies are written to image files considerable redundancy is the result – e.g. in addition to Places|Europe|France|Paris|Eiffel Tower, you’ll also end up with Places|Europe|France|Paris and Places|Europe|France and Places|Europe on the image file. Given these two points, and the fact that hierarchies can be written to images by other means, I don’t see the value of this facility, unless you only want selected hierarchies to be written to image files.

When reading images in other programs, or searching a load of them, the main attraction of storing keywords, as you identified in your original post, vlad, is that many programs don’t recognise hierarchies (I guess many amateurs like me don’t use Lightroom). I personally like to see all the keywords when modifying photos because it can make me realise where I have not properly labelled a photo.

I have catalog labels that are duplicated. Thus, “Daphne” could be my mother-in-law or a plant in the garden. In such a situation, searching (outside PSU) for images with a specific label could produce many unwanted images. Not so much an issue where the hierarchy is available (in particular, in PSU), but is there a recognised view on this issue? Qualifying every repeated label to reflect the hierarchy it belongs to seems rather perverse, and clearly not required within PSU.

Of more concern to me (having experienced problems), is the question of robustness. The basic requirement must be to have the label hierarchy stored on the images in a form that can be used by PSU to re-create the catalog in the event of a disaster. I presume that choosing "Write hierarchical keywords" in the general preferences is sufficient. (I have “Automatically write out Catalog changes to the image file” and “Only update out-of-sync images” checked). I take the point you’ve made, Mike, about the extra data available if you choose “Write catalog data to IDimager ICS scheme”, and I’ve now set this. One question this does raise in my mind is, what happens if images are read into PSU with conflicting hierarchy information? I haven’t checked this, and it shouldn't be an issue, but my concern reflects questions over whether what is written to images is always 100% reliable and consistent, especially if the catalog has at some stage been re-arranged.

Writing out hierarchical keywords and the IDimager ICS scheme obviously involves some redundancy, but in terms of storage / performance the impact is presumably trivial. Hierarchical keywords are obviously needed in case you should ever want to use a DAM tool other than PSU, the IDimager ICS scheme being of no value except when using IDimager Inc software.

One final thought, about changing preferences:

Preferences settings don't have to remain constant; they can be temporarily changed to suit particular needs.

Indeed – but I do find it quite difficult to ensure, after I’ve been making changes, that I’ve set things back to my default settings, especially if I’ve made changes on specific labels!

[tstoddard]

I wonder, Tom, whether your apparently inconsistent results hark back to using IDImager.

Charles,
I never actually owned a licensed version of IDimager. I had installed the trial version less than 30-days before it was discontinued and I was unable to purchase a license. I don't think that I imported my trial IDimager database into Photo Supreme but even if I did, the labels that I was testing were definitely created in Photo Supreme not IDimager.

I think I will test a few more labels when I get a chance to make sure that I'm not missing something but I was very careful to check all of the details on the labels I did test and I assigned them to brand new images that had been freshly imported.

Thanks for your input and the time you spent testing this.