{"action":"created","issue":{"url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/1","repository_url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging","labels_url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/1/comments","events_url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/1/events","html_url":"https://github.com/mcrosson/lr_plugin_computer_vision_tagging/issues/1","id":183032674,"number":1,"title":"Add functionality for hierarchical keyword sets","user":{"login":"LowellMontgomery","id":9017652,"avatar_url":"https://avatars.githubusercontent.com/u/9017652?v=3","gravatar_id":"","url":"https://api.github.com/users/LowellMontgomery","html_url":"https://github.com/LowellMontgomery","followers_url":"https://api.github.com/users/LowellMontgomery/followers","following_url":"https://api.github.com/users/LowellMontgomery/following{/other_user}","gists_url":"https://api.github.com/users/LowellMontgomery/gists{/gist_id}","starred_url":"https://api.github.com/users/LowellMontgomery/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LowellMontgomery/subscriptions","organizations_url":"https://api.github.com/users/LowellMontgomery/orgs","repos_url":"https://api.github.com/users/LowellMontgomery/repos","events_url":"https://api.github.com/users/LowellMontgomery/events{/privacy}","received_events_url":"https://api.github.com/users/LowellMontgomery/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-10-14T12:00:18Z","updated_at":"2016-11-23T19:33:10Z","closed_at":null,"body":"This is where we will address/brainstorm the extension of this plugin in the same manner I did the safx implementation, as discussed in the issue queue there:\nhttps://github.com/safx/LightroomPlugin-ClarifaiTagger/issues/1\n\nSome of the feature improvements I’ve added to the original safx implementation include:\n1) Support for finding “already existing terms” in a hierarchical list instead of just a flat list. Without this, it created more work than it saved since adding terms meant creating duplicate terms that I then had to manually merge with existing terms, a tedious process.\n\n2) Related to the above, I can also skip sections of the tree to look for existing keywords if I wouldn’t want to use those terms, e.g. “downtown” is a sub-location keyword for some region-specific keywords (created using John Beardsworths Search/Replace/Transfer plugin to copy geolocation metadata into a keyword hierarchy). So I skip the LOCATIONS section of my term tree. I also skip my people, and some long lists of plant and animal species since Clarifai isn’t yet smart enough to send those terms, anyway (so ignoring these very long sections of my term tree makes the plugin’s processes more efficient).\n\n3) If two or more keywords have the same name, I provide checkboxes for both. Keywords with parents (all of mine), display a tooltip with the full “ancestry” if you hover over the checkbox or keyword.\n\n4) I auto-select terms that are existing in my keyword list (as the safx version originally supported), but I now also support modifying that behavior to only select terms where Clarifai has set a high probability (the level of probability required is configurable in the settings panel).\n\n@mcrosson Responded there (summarized):\nTo speak to each point directly:\n1) I saw this in your pull request and it would definitely be something I'd want to see implemented. I currently don't have this functionality built.\n2) This sounds like a very useful addition to point 1. I currently don't have this functionality built.\n3) This sounds like a really good addition to 1 and 2. I'm not sure how I'd put it together but if 1 and 2 end up added, I think this functionality would be a huge gain.\n4) My plugin will auto-select existing terms and has an option to auto-apply tags with a minimum p value. However, auto-selecting tags with a minimum p value should be a pretty straight forward change and I'd be willing to add it as additional functionality.\n\nOne more thing that I think the plugin should automatically support when dealing with a hierarchical keyword list is that, for each photo and keyword, we explicitly (and automatically) select any parent/grandparent keywords. Those terms would be exported, anyway (if not set to be suppressed on export), but they otherwise can end up \"not adding up\" when looking at the library keyword numbers. And you wouldn't find results when searching for the parent term (if it was not also directly added).\n"},"comment":{"url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/comments/262610488","html_url":"https://github.com/mcrosson/lr_plugin_computer_vision_tagging/issues/1#issuecomment-262610488","issue_url":"https://api.github.com/repos/mcrosson/lr_plugin_computer_vision_tagging/issues/1","id":262610488,"user":{"login":"LowellMontgomery","id":9017652,"avatar_url":"https://avatars.githubusercontent.com/u/9017652?v=3","gravatar_id":"","url":"https://api.github.com/users/LowellMontgomery","html_url":"https://github.com/LowellMontgomery","followers_url":"https://api.github.com/users/LowellMontgomery/followers","following_url":"https://api.github.com/users/LowellMontgomery/following{/other_user}","gists_url":"https://api.github.com/users/LowellMontgomery/gists{/gist_id}","starred_url":"https://api.github.com/users/LowellMontgomery/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/LowellMontgomery/subscriptions","organizations_url":"https://api.github.com/users/LowellMontgomery/orgs","repos_url":"https://api.github.com/users/LowellMontgomery/repos","events_url":"https://api.github.com/users/LowellMontgomery/events{/privacy}","received_events_url":"https://api.github.com/users/LowellMontgomery/received_events","type":"User","site_admin":false},"created_at":"2016-11-23T19:33:10Z","updated_at":"2016-11-23T19:33:10Z","body":"@mcrosson Hi Mike... I'm sorting out the logic now. I noticed that what safx meant by \"existing keywords\" (in context of preference to display them in bold) and the use in your code logic, are different things.\r\n\r\n1. safx meaning: Keyword exists in the catalog (selecting it will not create a new keyword at the base of the hierarchy). The preference for making these keywords bold is only to indicate that.\r\n2. LRCVT meaning: photo already has a keyword with the tag-name associated with it.\r\n\r\nIMHO, we *should* indicate already-associated keywords somehow, e.g., by adding an asterisk beside each such keyword to indicate that deselection of those checkboxes would remove existing tags for the image. I personally don't think it is necessary to provide a *preference* for whether/not to display such an indicator for the already-associated keywords.\r\n\r\nFurther notes: I see that, **for each suggested tag**, if \"bold existing tags\" (or asterisk already associated tags)... whatever... you are calling a helper function that gets the raw keyword objects for the photo and iterates over them all, checking for the name by calling the getName() function for each keyword object. A few issues here:\r\n\r\n1. This is inefficient. We can get the names of all pre-existing keywords in one request, store it in an array (of names), then for each suggested tag, check whether the tag is already in that array of names.\r\n2. We should do that in such a way that \"Dog\" and \"dog\" are seen as the same, so conversion via string.lower(), or equivalent, for both suggested tags and existing keyword names. The current approach does not seem to ignore case. Clarifai returns keywords in the proper dictionary case (upper case only for proper names, not words like \"dog\" or \"tree\" or \"walking\"). But a lot of Lightroom users seem to have their keywords in title case. Clearly such users would want to select their \"Animal | Mammal | Dog\" keyword, not add a new \"dog\" at the base of their keyword tree and then later have to deal with the duplicate terms.\r\n3. Assuming we use the definition of \"bold_existing_…\" to mean the original \"in the catalog\" meaning, we don't need to do much processing during this step (explained below).\r\n\r\n\"My logic\" from the safx fork, in order to properly deal with a hierarchical tree, iterates over all terms in the keyword tree (skipping branches or sub-branches that we don't care about for auto-tagging). It collects the keyword objects in one table by keyword name and uses a second table (also indexed by keyword name), to store the \"ancestor paths\" for those keywords. Since a name may have multiple keywords, each address in the table is a subtable. (Where a name *does* have multiple keywords, and the term is among those already associated with the photo, my logic does call to get raw keywords for the photo to check *which* keyword(s) is/are actually selected for the photo.) Anyway, if `catalogKeywords[string.lower(tag)] == nil`, it doesn't \"exist\" (in the Lightroom catalog). According to my approach, I iterate over the keyword library to populate those tables right after we send the request to Clarifai (i.e. when we are otherwise \"waiting\"). This allows us to avoid iterating over the whole tree or all the keywords for a photo and making lots of extra function calls at the time we build the dialog.\r\n \r\nBack to the \"bold existing\" preference, I do find it useful. I mostly try to avoid adding new terms to my keyword list (if I already have a similar term and/or a term with synonyms that are the same as the suggested term). When I run this (on the safx branch), almost all terms are bold and pre-selected."}}
{"actor":{"display_login":"LowellMontgomery"}}