P: Keyword options no longer available in LR4

[Califdan]

When one has a keyword hierarchy:

In LR3, one could skip a level in selecting which keywords are exported. For example in the hierarchy A, B, C (where A is top parent) one could set A=Include on export, B=Do not include on Export + Export Containing, and C=Include on Export + Export Containing. In this way, on a photo with only keyword "C", on export we'd have A and C but not B.

In LR4 all my LR3 keywords that had this pattern were changed during catalog conversion and I can no longer set this pattern. Turning off "Include on Export" now turns off "Export Containing" and "Export Synonyms" rather than leaving them alone as in LR3.

This is a HUGE problem for me as I have my entire keyword hierarchy (over 3,000 KW's) designed to allow skipping levels. In addition, I have cases where the actual Keyword is for my workflow and convience but but the synonym is what I want exported (not the actual KW) which I can also no longer seem to do.

See screen shots below

[FeedbackCommunityMember]

It s not a god policy to change something that works well. In this case a lot of peopel use keywords lists, and when they earlier could choose what to be exported ore not, in L4 they cant do it anymore. Today in L4, the old keyword list has to be rewritten! A lot of work for many peopel! this can not be the goal for Adobe...

[John R Ellis]

I made a proposal for a small change to the SDK that would allow plugin authors to provide keywording functionality for those users of large hiearchies whose needs aren't being met by LR:

http://feedback.photoshop.com/photosh...

[FeedbackCommunityMember]

@ John

More open SDK for keyword plugins is a very good idea John!

[notnow117]

I just noticed this issue as well, and I'll be rolling back to LR3 until it's addressed somehow.

For tagging people, all of my keywords are set up as the full name of the person in the photo, but I obviously don't want to export that. I have just first names in the synonym list, and I'd like those to export, but that no longer works in LR4.

I think having a catalog setting, or some way to explicitly enable that functionality, would be a great way to protect people's privacy as the default behavior without completely breaking existing workflows.

[FeedbackCommunityMember]

Can't export synonym without keyword tag. This works in LR 3 but not in LR 4.

[Califdan]

Terry D --

Yes, There are several take away's in LR4 that this thread is complaining about. Unfortunatly the only response we've gotten from Adobe was around March 21 from Benjamine Warde who declared this as "Not a Problem" along with an explaination that so far most people have considered as unacceptable.

Since then Adobe has been silent on the subject. I don't know if they're just ignoring a growing number of angry customers, are busy with other things and will get to us shortly, or are debating the issue internally.

Benjamine Warde: ARE YOU LISTENING?

Dan

[J453]

Hi Dan,

The team hasn't been silent on the subject. Ben's explained why the change was made and John Beardsworth has also provided some explanation.

Yes. The team is looking to see if both the old behavior and the new behavior can be supported - and we appreciate folks who have chimed in with how they used the old behavior, and suggestions to enable both workflows/concerns. The team is currently readying some other higher priority fixes so I can't give out any ETAs or venture to guess any outcomes at this point.

[Califdan]

Hi Jeffrey,

Thank you for your update. I appreciate your supplying input. Yes, I saw Ben's posting, but there were many responses ("rebuttals" if you will) contradicting - or at least arguing against - the position he stated and we did not get an Adobe responses after that.

I was not aware that John Beardsworth was an Adobe representivite as his posting did not indicate an Adobe affiliation as yours and Ben's did and he spoke of Adobe in the 3rd person ("I feel that Adobe....."). Thank you for clearing that up.

I am pleased that Adobe is continuing to look for a solution to this obviously sensitive and important topic and am optimistic that a win/win solution can be found. Perhaps even one of those suggested in this thread like making the choice of behaviour a catalog preference, or providing a warning pop-up. Both of which would mitigate the privacy concern yet retain the required functionality for those who choose to change the preference one case or override the warning in the other.

Please keep us posted on progress and feel free to contact me if you desire further input. I live not too far from Adobe HQ in San Jose so could even come in for a meeting on this subject if desired. You can contact me privatly through my web site www.danhartfordphoto.com

Thanks -- Dan (Ex-Adobe employee)

[J453]

Thanks. Yeah. I'm hopeful a win/win solution can be found, too. John isn't an Adobe employee, but is very active in the Lightroom comment, so he's aware of why the change was made - and what he stated was correct.

Ben's also in SJ, but a fair amount of the team is here in Minnesota where I work.

[AlunFoto]

I have had a second look at the output from Lightroom in various settings, and have noticed a very interesting issue. It appears that the setting for whether or not to include the exported file in the LR catalog is the most important influence on how keywords are written.

In LR3.6, the export settings for the individual keywords are obeyed consistently in all situations except one:
"Add to this catalog" is turned on
"Write KWs as LR hierarchy" is turned off
In this situation, the full compliment of hierarchical keywords is written to the file regardless of reservations specified for the individual keywords.

In all other combinations of catalog/KW options, clever use of the parameters as described in this thread can tailor exactly which keywords are exported.

Synonyms are, in all cases, written to both and in a flat structure, as well as to the legacy IPTC-IMM section. It is only synonyms marked with "include on export" that propagate.

In LR4, the main difference lies in what propagates to the exported file in the above mentioned situation.

If a high-level keyword is marked as "do not export", the underlying terms are not included in the hierarchical list in the tag. However, the underlying terms still propagate as a non-hierarchical keyword to the tag, the section, and to IPTC-IMM, which explains why people did not notice the change from LR3.6 until the tick boxes were changed in the production version.

Synonyms are also omitted from the block, but do propagate to and to the IPTC-IMM section. Just as for v3.6, it's only the synonyms indicated for export that are included.

LR4, in my opinion, made a step forward with the handling of synonyms. It's no point in listing them non-hierarchically in the block when the other two does the job. If synonyms were to be included here, I would like to see them associated with it's correct place in the hierarchy, but that would be a hard nut to crack I guess.

What remains an issue is the hierarchy in the exported tag as described before in this thread, though.

Could it be a solution to replace keywords marked "do not export" with a UID or some other form of machine-readable token? This would of course wreak havoc for people who wants to look at the exported keyword hierarchy with other software, but the information would remain private. In addition, it would be possible for LR to reconstruct the entire keyword hierarchy from file as long as the catalog is the same.

And maybe LR could suppress assimilation of all the keywords duplicated in the IPTC-IMM and blocks if the tag is populated with a hierarchy? This would be also of great help to us who try to keep our controlled vocabularies from flooding with orphaned keywords. 🙂

[FeedbackCommunityMember]

I've jumped head first into the same problem with people's full name as keyword, and exporting a synonym with only their first name. Among other issues.

Have anyone thought of adding the chekboxes _after_ the input fields? Something like this:

Keyword name: [__________________] [x] Don't export
Synonyms: [__________________] [x] Don't export

[x] Export containing keywords

The "Export containing keywords" would only apply if either keyword or synonyms are exported.

Whatever the outcome is, I would really appreciate a solution that re-enables the keywords behaviour from all previous versions of Lightroom into Lightroom 4.

[Califdan]

Were any of these issues addressed in the 4.1 release candidate that is now available?

[Benjamin Warde]

No, no changes to keywording were made in the 4.1 release candidate.

-Ben

[Califdan]

How dissappointing

[Guest]

Has anyone found a serviceable workaround to this problem?

[Califdan]

No solutions have come forth from Adobe and I really don't understand why they don't seem to taking this problem all that seriously. Perhaps they are, but I have not seen any updates from them on this thread in quite some time. Maybe now that PS CS6 is released they can free up someone to implement one of the solutions proposed - or at least let us know they're working on it and intend to provide a solution.

As for a work around, there are really none that are satisfactory that I know of.

There are really two problems caused by Adobe's change.

1) Can't export synonyms without also exporting the actual keyword (which many times is not desired). The only workaround I know of is to take one or your synonyms and make it the actual KW instead, which, of course totally screws up your hierarchy sort order.

2) Can't skip a level in the string of parents that get exported. This one too does not really have an acceptable work around, however it does have a complicated, prone to error and difficult to maintain work around. Let's say you have a hierarchy of A > B > C > D > E, and if a photo is tagged with E, you want E, D, and B exported, but not A or C. To do this you would have to:
1) Set A and C to "do not export"
2) Set E (and optionally B & D) to "Export Containing"
3) Tag each photo that used to have juste E, with B as well (E brings along D).
Of course remembering where the breaks are in each hierarchy is a real pain. To aid with this, I renamed "A" to "A (NO EXP)" and "C" to "C (NO EXP)" so that when I add a KW to a photo using the Keyword List pane, I can visually scan up the tree and also click the check box on parent KW's that are above any that have the "(NO EXP) phrase.

Yeah I know it's a real pain and is a giant move in the wrong direction in terms of stream lining workflow (which of course is what LR is supposed to be all about), but untill Adobe steps up to this problem it's the best I can come up with.

PS - if this thread goes quiet, Adobe may think it's no longer an issue. So if you're reading this and feel that Adobe should address it, it would be good to hear from you.

Dan

[FeedbackCommunityMember]

I don't see the issue with privacy. Even though it is grayed out, it is very obvious the boxes are checked. I was actually happy when I first discovered it would do that. Needs to come back.

[Guest]

I think I have found a possible work around to this problem. For all the keywords you don't want to export you can recheck the include on export box and instead identify them with a proceeding or trailing character. I surrounded keywords in the middle of a hierarchy with "~"s (ex. ~birds~). This symbol results in the keywords being sorted to the end of keyword lists as ~ comes after most letters and symbols in an alphabetic sort. For stem keywords I used a single trailing ~ so as not to interfere with keyword entry or search.

This process can be done quickly with empty keyword hierarchies by exporting the keyword list and using search and replace as keywords that will not be exported are surrounded with []. This method will not work with an existing hierarchy as reimporting the keyword list will create numerous duplicate keywords without photo assignments. You could try Keyword Consolidator but this may be more work then simply altering the keywords manually. Even for a manual sort the keyword list can be used to more easily identify the keywords that you have selected not to export.

With these identifying characters, you can then use Jeffrey’s “Metadata Wrangler” plugin to strip keywords during export. In the export window under the optional metadata wrangler tab added by the plugin there is an option to strip keywords during export. This blank allows the use of wildcards which can then be used to strip the keywords that you don't want to export (ex. ~*~ or *~ to strip the keyword with the identifiers I use above).

Hope this helps,
Adam

[notnow117]

This doesn't help with tagging when exporting to Flickr. Metadata Wrangler does affect the keywords written in the Exif data, so my private keyword is stripped out of there, but it still shows up as a tag in Flickr.

Note that I'm publishing to Flickr using Jeffrey's Export to Flickr Plugin with a Publish Service. The tags are controlled by the "Flickr: Metadata Export" section in the service settings, and don't obey the Metadata Wrangler filtering. So all I can do is enable or disable creating tags from all of the keywords.

[Guest]

I have also run into some issues using this work around to export to Flickr. I have not been able to strip the keyword when exporting with the default plugin but I have had success with stripping keywords when exporting new photos with Jeffrey's Export to Flickr Plugin. No luck with modified photos though. Not sure how our settings are different though.

[Guest]

With Jeffrey's Export to Flickr Plugin if you uncheck the explicitly send keywords from lightroom's database box in the metadata management section of the service settings this seems to result in metadata wrangler stripping keywords from newly uploaded photos.

[notnow117]

i was uploading a modified photo, not a new photo. I tried unchecking the explicitly send keywords option and then it didn't send any new keywords with the photo. I added a new keyword that was set to include on export and it showed up in the exif data but not as a tag.

[Guest]

Yes that is my experience as well. This method does seem to work with new photos though. If you go to Flickr extras in plugin extras to resend metadata you can send new keywords as tags but metadata wrangler won't work with this tool.

[Califdan]

Jeffery, Benjamin,

Can you please provide an update from Adobe on this serious problem? Just marking it "Not A Problem" is quite annoying as it is certainly a serious problem that is cuasing a lot of people a great deal of time, effort, frustration, and major degradation to the efficiencies of our workflow. Every time I look at this thread and see "Not a Problem" in bright yellow on the header it makes my blood boil.

I know that Adobe feels making this change improved "privacy" protection. However, at some point Adobe must weigh the cost of any change against the percieved benefit. After all, if you REALLY want to to eliminate privacy concerns, then remove the ability to export photos from LR altogether. That would certainly quell all possibility of privacy breaches, but it would also render the product totally useless.

Each "improvement" of any sort must be weighed against the cost of that improvement in terns of usability and functionality. Is the percieved benefit worth the cost in those terms? I think it's obvoius that in the case of these Keywords the cost to your customers is much greater than the percieved benefit of improved privacy.

What makes this so frustrating is that there are several approaches proposed in this thread which would address the privacy concern, would not be all that costly to implement and would still allow your customers to make full use of LR's keywording without time consuming manual work arounds or the purchasing of 3rd party software that may or may not solve the problems.

Can you please remove the "not a problem" tag on this thread and let us know what Adobe is doing to address the issue?

Thanks -- Dan

[John R Ellis]

It's unfortunate the moderator marked this a "Not a problem", since it clearly is a problem for many people, and it understandably and needlessly annoys them.

Topics in this forum can be marked with a number of statuses; here's my understanding of the relevant ones:

Not a problem -- the user has reported a problem but in fact there is an adequate solution or product feature that the user wasn't aware of.

Under consideration -- Adobe is considering the idea or problem solution but hasn't made a decision yet.

Not planned -- Adobe understands what the user's issue is but has decided not to address it in the foreseeable future.

Based on Jeffrey Tranberry's response last month, "The team is looking to see if both the old behavior and the new behavior can be supported", it would seem that "Under consideration" would be a more appropriate status.