[digikam] [Bug 384485] Face Regions are deleted when unconfirmed face suggestion is rejected by user
https://bugs.kde.org/show_bug.cgi?id=384485 --- Comment #12 from Kartik --- Gilles, this bug report may be closed now. I have implemented functionality, to reject Faces if the Red Minus Button is pressed. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384396] Display faces sorted by similarity (pre-grouped) instead of album/time/..
https://bugs.kde.org/show_bug.cgi?id=384396 --- Comment #22 from Kartik --- Gilles, this bug report may be closed now. Here's the new Feature in case anyone's interested to see: https://imgur.com/a/CKVopzi -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392023] Add "Ignored" group of faces
https://bugs.kde.org/show_bug.cgi?id=392023 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #6 from Kartik --- Gilles, this bug report may be closed now. I have added the Ignored Tag Category. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423114] Deleted Faces don't re-appear in Face Scan with "Skip Images already Scanned"
https://bugs.kde.org/show_bug.cgi?id=423114 --- Comment #4 from Kartik --- Gilles, this bug may be closed. This feature is not needed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 415604] Allow changing a face tag from a person to another
https://bugs.kde.org/show_bug.cgi?id=415604 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #10 from Kartik --- Leaving this here for future reference. I have implemented a function FaceTagsEditor::changeTag()(https://invent.kde.org/graphics/digikam/-/blob/gsoc20-facesengine-workflow/core/libs/database/tags/facetagseditor.cpp#L495), that can change the assigned Face Tag of a person. All that's needed is to plug it into the GUI. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 415565] Show face as icon for each person in the People panel.
https://bugs.kde.org/show_bug.cgi?id=415565 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #3 from Kartik --- Gilles, this bug report may now be closed. I have implemented automatic tag Icon assignment. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423387] Add Button to instanlty set face tag as Unknown
https://bugs.kde.org/show_bug.cgi?id=423387 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #5 from Kartik --- (In reply to Pedja from comment #0) Hi, I did include this bug as part of my project, and I fixed it last month. The fix should be present in the post-September release of DigiKam. Have a look at this for a demo of the Feature : https://imgur.com/a/eaFFDG4 The Red Minus button performs the "Unknown" operation you mentioned. Pressing the cross button performs the remove operation as earlier. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384396] Display faces sorted by similarity (pre-grouped) instead of album/time/..
https://bugs.kde.org/show_bug.cgi?id=384396 --- Comment #19 from Kartik --- (In reply to Maik Qualmann from comment #17) > The digiKam Icon View knows categories. I would find it better if the person > name is the category and thus the people are grouped. That would be much > clearer. I do like this idea. However, I don't think this would work for images with multiple faces. When categorizing items (faces in our case) the ItemInfo is passed to the various sorting functions. Different faces (in the same image) share the same ItemInfo. Even if I store face suggestions in each ItemInfo, given an ItemInfo it's tough to know which face called it. I'll have to think of a work-around for this. Maybe I could store a Map of Face Regions to Suggested Faces, and somehow pass Face Regions to the categorizing algorithm as well? Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384396] Display faces sorted by similarity (pre-grouped) instead of album/time/..
https://bugs.kde.org/show_bug.cgi?id=384396 --- Comment #20 from Kartik --- Just to update, storing maps of tag regions to suggested names is definitely feasible. I'll go forward with this approach to implement categorization based on Suggested Names. This will lead to categorization of similar looking faces together. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 --- Comment #5 from Kartik --- Hi Nghia, The Top Level Connections for the Deleting button are done in DigikamItemView. The Delete Button forms part of a FaceRejectionOverlay, and the signal for pressing the delete button is set here: https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/digikamitemview.cpp#L342. The removeFaces(https://invent.kde.org/graphics/digikam/-/blob/master/core/app/items/views/digikamitemview.cpp#L411) method then delegates deletion to a FacePipeline. I think you might be familiar with FacePipeline functionality. DatabaseWriter works with the FacePipeline and picks up the package (when its time for being processed arrives), and then calls the FaceUtils method for actual removal of the Image-Tag association: See this connection for DatabaseWriter with FaceUtils: https://invent.kde.org/graphics/digikam/-/blob/master/core/utilities/facemanagement/workers/databasewriter.cpp#L142. There's multithreaded implementations that lead to DatabaseWriter picking up the package sent via FacePipeline, however it isn't necessary to worry about that in my opinion. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] New: Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 Bug ID: 423113 Summary: Deleted Faces still serve as information to Facial Recognition Product: digikam Version: 7.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kartikx2...@gmail.com Target Milestone: --- SUMMARY If a user accidentally confirms a face, and then to correct it, deletes the face, still Facial Recognition uses information from the confirm operation. STEPS TO REPRODUCE 1. Confirm an Unknown Face to a newly created face. 2. Delete this face, using the Rejection Overlay (cross button) 3. Run Facial Recognition Here's a video showing this in action : https://imgur.com/a/sYX3cgF I assume this is happening because the Face is being deleted without removing the association of the Tag Region and the Face Tag. I personally don't think this is desirable, as it forces the Algorithm to operate on incorrect information. Please try to reproduce this bug, as it may be possible that this is just a problem in my branch. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 --- Comment #1 from Kartik --- (In reply to Kartik from comment #0) > SUMMARY > If a user accidentally confirms a face, and then to correct it, deletes the > face, still Facial Recognition uses information from the confirm operation. > > STEPS TO REPRODUCE > 1. Confirm an Unknown Face to a newly created face. > 2. Delete this face, using the Rejection Overlay (cross button) > 3. Run Facial Recognition > > Here's a video showing this in action : https://imgur.com/a/sYX3cgF > > I assume this is happening because the Face is being deleted without > removing the association of the Tag Region and the Face Tag. I personally > don't think this is desirable, as it forces the Algorithm to operate on > incorrect information. Please try to reproduce this bug, as it may be > possible that this is just a problem in my branch. > > Kartik [Correction] 1. Confirm an Unknown Face to a newly created Face Tag. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423114] New: Deleted Faces don't re-appear in Face Scan with "Skip Images already Scanned"
https://bugs.kde.org/show_bug.cgi?id=423114 Bug ID: 423114 Summary: Deleted Faces don't re-appear in Face Scan with "Skip Images already Scanned" Product: digikam Version: 7.0.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kartikx2...@gmail.com Target Milestone: --- If a User deletes a Face Region (using the Rejection Overlay cross button), then the Face shouldn't remain marked as "Scanned". The user should be easily able to recover the image using the "Face Scan -> Skip Images Already Scanned". Instead to recover it, the User will have to "Scan all and Merge Results", which is time consuming. Here's a video about what I mean : https://imgur.com/a/p0W0yfl When I try to run "Skip Scanned Images", the Algorithm thinks that all images have been scanned already. I feel this is because the deletion of Face Region, is not un-marking the Face as "Scanned". Please check if this bug is reproducible, in case it's just a problem with my branch. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386295] People and Tags Filter sidebars doesn't show the same Unconfirmed Faces
https://bugs.kde.org/show_bug.cgi?id=386295 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #5 from Kartik --- (In reply to Maik Qualmann from comment #2) > What you have on the screenshot is not the left sidebar with the tags but > the people tree view from the facial engine. Here is under "Unknown" a > virtual "folder" of the found faces of the facial engine. On the right side > are the tags that are actually assigned to images. The same for the > "Unconfirmed", the faces engine has detected faces and virtually added the > images, but are not yet tagged, hence the difference. Yes, that's a bit > confusing, but correct. > > Maik If I understand correctly, since Unconfirmed Faces are just ItemTagPair associations and not actually assigned to the image (using a FaceTagsEditor::AddTag() operation for eg.) they don't show up in the Right Sidebar? I think this should be fixed, because many Users request a feature to use the Right Sidebar Unconfirmed Tag Filter to be able to view just the Unconfirmed Faces of a particular tag, as this would allow easy confirm/reject process. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423114] Deleted Faces don't re-appear in Face Scan with "Skip Images already Scanned"
https://bugs.kde.org/show_bug.cgi?id=423114 --- Comment #2 from Kartik --- (In reply to Maik Qualmann from comment #1) > But a face that I delete should never be found again. The fact that we need > a way to get it back is another matter. Again, how users imagine it and how > you should implement it: > > Let's say the automatic face detection finds a car tire as a face. > With a click on the overlay button (x) this car tire is removed. It no > longer appears on the image as a face marker and a re-scan will not suggest > it as a unknown face again. > The face recognition suggests a name for a face, with a click on the (-) > button the suggestion is rejected and the image appears again under unknown. > > Maik Understood. I was considering the (x) button to function as a "Reset this Face", when that is not the intention. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 423113] Deleted Faces still serve as information to Facial Recognition
https://bugs.kde.org/show_bug.cgi?id=423113 --- Comment #3 from Kartik --- Hi Maik, rebuilding the training database is certainly a good idea to avoid this error. I wasn't aware that feature existed. It's certainly desirable for Faces to remain in the database, if an Image is deleted. However, if the User presses (x) on a Face, then he does want to Delete that face (not delete the Image). If the user is implying that this is not a face, then why is it being used as Training Data? Apologies for any inconvenience. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #3 from Kartik --- I would like to work on fixing this bug. I'd be very grateful for any pointers regarding where to look for possible fixes. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #5 from Kartik --- Thanks for the reply Gilles. I've gone through the files that you mentioned. I understand that the TagFolderView in PeopleSidebar, keeps tracks of tags as TAlbums, which are created based on the name that we assign to the tag (like "Jack" etc.) I can't find where the "new" counter is being stored, and how it's being updated. I don't think it's stored as a property of the tag, is it? Could you please direct me to the files associated with this counter? Thanks in advance. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #6 from Kartik --- I'm currently trying to fix the duplicate bug 416180. Confirming/Rejecting a face is dealt by DigikamItemView::confirmFaces() (and rejectFaces()) respectively. Maybe there could be an implementation at the end of these methods to update the new counter of the corresponding tag? I'll need to understand how the new counter is associated with each tag for this matter. Is it something calculated actively for each tag, every time number of unconfirmed results change? Thanks. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #9 from Kartik --- Thanks a lot for the suggestions, Maik. I never checked the libs/database folder, this really improved my understanding. Whenever we confirm/reject face suggestions, the database is written to by CoreDB::addImageTagProperty(). So adding a recordChangeSet() at the end of this function should notify the tag tree view that the count has changed? So, we may do: d->db->recordChangeset(TagChangeset(tagId, TagChangeset::PropertiesChanged)); Is this the correct approach? Thanks Kartik. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #10 from Kartik --- The method I proposed does update the new count, however it always trails behind the actual situation by 1 image. For eg. if I had 7 new unconfirmed faces, and I confirmed one, the count will not decrement immediately. It will do so only on a second confirm (or reject), and will decrement to 6 (when it should actually show 5 new, as two confirms have been made). Similarly when I'm left with only one new suggestion and I confirm it, the counter will be stuck at 1 (unless I click on the left sidebar, which was the main issue to begin with) Any suggestions to resolve this would be appreciated. Thanks Kartik. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #11 from Kartik --- Update: I have resolved the issue. In CoreDB::AddImageTagProperty I added d->db->recordChangeset(TagChangeset(tagId, TagChangeset::Added)); In CoreDB::removeImageTagProperties I added d->db->recordChangeset(TagChangeset(tagId, TagChangeset::Deleted)); It works as desired, please clarify whether this is the appropriate approach. Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 406586] Item count in "People" is not updated until you click or hover a tag
https://bugs.kde.org/show_bug.cgi?id=406586 --- Comment #13 from Kartik --- I have made a merge request. https://invent.kde.org/kde/digikam/-/merge_requests/12 Thanks for all the help Marc , Maik and Gilles :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 349564] Add support of face tags group
https://bugs.kde.org/show_bug.cgi?id=349564 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #2 from Kartik --- Hello Martin, DigiKam 7.0.0 has been released, can you please confirm whether the bug still exists? Can you also please clarify what exactly you mean by tagging a face twice? Does the unconfirmed result after a scan report the same face tag (of the same image) twice under different tags? Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384396] Display faces sorted by similarity (pre-grouped) instead of album/time/..
https://bugs.kde.org/show_bug.cgi?id=384396 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #15 from Kartik --- Hello all, I would like to work on this bug. I noticed that Google Photos resolves this in a very efficient manner, it does not show you the entire "Unknown" Collection, instead only individual collections of people that are currently unknown, but the algorithm has concluded to be the same. Maybe this is something we can incorporate into DigiKam? I was thinking of creating a hierarchy within the Unknown tag, where each sub-tag will display face-tags of people that are similar (or the same). The user could reject if the person is not the same as the rest, in which case the person would move into the misc. unknown tag. There are a few issues to this, firstly I'm not sure whether it's ideal to create a hierarchy within the unknown tag, furthermore, I'm not sure what I'd name these subtags. I'd be grateful for any suggestions regarding this. Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 384485] Face Regions are deleted when unconfirmed face suggestion is rejected by user
https://bugs.kde.org/show_bug.cgi?id=384485 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #10 from Kartik --- On a somewhat related issue, whenever we delete a tag from a confirmed face. For eg. If I had confirmed a suggestion, but later realized it is incorrect. I will do a Remove Tag -> People/Kartik. I think this should return the image back to unknown, however it rejects the image as a face. We will have to scan it again, to get it back to unknown. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 419039] New: [Request] Allow Keyboard Navigation when Identifying Unknown Faces
https://bugs.kde.org/show_bug.cgi?id=419039 Bug ID: 419039 Summary: [Request] Allow Keyboard Navigation when Identifying Unknown Faces Product: digikam Version: 7.0.0 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kartikx2...@gmail.com Target Milestone: --- Personally, I like navigating using the keyboard. However, identifying faces in the Unknown Faces View requires the user to go back and forth between the keyboard and mouse a lot. It would be helpful (I believe), if the user could first click on an detected face, type a name, press Enter to assign it (till this step is currently supported by DigiKam), and then move around with the arrow keys, and whichever other face he wishes to apply the same tag to, he may simply press enter for it. I would like to implement this feature in DigiKam. Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 419040] New: [Request] Provide Option to Select Album to apply Facial Recognition on
https://bugs.kde.org/show_bug.cgi?id=419040 Bug ID: 419040 Summary: [Request] Provide Option to Select Album to apply Facial Recognition on Product: digikam Version: 7.0.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kartikx2...@gmail.com Target Milestone: --- Currently, the user is provided the option to select albums on which Face Detection is done, and then Face Recognition takes place on these identified faces. If the user accidentally scanned some albums during detection, then there isn't a way to remove these albums from the recognition process(If there is, I feel it could be made more intuitive, I wasn't able to find it). It would helpful if the user could select which albums, Recognition could take place on as it can save time if user only wanted to recognize a small album. Even if this can not be done, the Face Views (Under Unknown Tag) could provide an option to perhaps hide albums that the user doesn't want to see. Personally, I find it to be a little cluttered if too many albums are present there. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 419040] [Request] Provide Option to Select Album to apply Facial Recognition on
https://bugs.kde.org/show_bug.cgi?id=419040 --- Comment #3 from Kartik --- Ah, so the Facial Recognition Algorithm does not realise what albums are? It only works on the entire set of unknown faces created by the Detection process? In that case would the latter part of my initial report be helpful? The Thumbnail View page already segregates the Unknown Faces into albums (and displayed under each album header), maybe we could provide a small collapse icon on this? Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 419047] New: Closing Face Tag Delete Dialog Box still ends up deleting face tag
https://bugs.kde.org/show_bug.cgi?id=419047 Bug ID: 419047 Summary: Closing Face Tag Delete Dialog Box still ends up deleting face tag Product: digikam Version: 7.0.0 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Faces-Workflow Assignee: digikam-bugs-n...@kde.org Reporter: kartikx2...@gmail.com Target Milestone: --- When we right click on a Face Tag (in People Sidebar). We are shown 2 Dialog Boxes, consecutively. 1. Confirmation Box, this works as accepted. 2. Dialog Box that asks whether to delete the associated face identity. Pressing the close button of this box, and pressing "No", performs the same function. It deletes the tag, but not the associated Identity. I think, the cancel button should instead not delete the face tag at all. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 419047] Closing Face Tag Delete Dialog Box still ends up deleting face tag
https://bugs.kde.org/show_bug.cgi?id=419047 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #2 from Kartik --- Created attachment 127030 --> https://bugs.kde.org/attachment.cgi?id=127030&action=edit Second Dialog Box when Deleting Face Tags Hello Maik, I don't believe this is a duplicate of bug 384485, as that bug deals with Rejecting Face Suggestions. This bug is about pressing the close button of the Dialog Box when deleting face tags. Even if we press the Cross on the second dialog box (which asks whether tags should be removed from the images also), the tag will end up being deleted. I'm aware that the user had been asked for confirmation whether he wanted to delete the face tag or not. However, I personally associate pressing cross with a "I want to cancel this process". Currently pressing cross is mapped to the No button. Is it desirable to add a cancel button to the second dialog? So that pressing cross could instead not delete anything at all? Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 279372] Show combined file sizes when selection is done into icon-view
https://bugs.kde.org/show_bug.cgi?id=279372 Kartik changed: What|Removed |Added CC||kartikx2...@gmail.com --- Comment #2 from Kartik --- Hello Gilles, I would like to fix the first part of this report. Displaying the sizes of the items selected as (A mB/B mB). I understand that I will need to make changes in the statusBarSelectionText of slotImageSelected in digikamapp.cpp. This method takes in ItemInfoList parameters, however ItemInfoList doesn't provide any convenience methods to return the sum of file sizes in the list. I may provide such a method in ItemInfoList, and subsequently use it in slotImageSelected, would it be appropriate? Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 279372] Show combined file sizes when selection is done into icon-view
https://bugs.kde.org/show_bug.cgi?id=279372 --- Comment #5 from Kartik --- Hello Maik, I've made a merge request to display File Size in status bar. I'm working on implementing the Right Side Bar currently. https://invent.kde.org/kde/digikam/-/merge_requests/18 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 279372] Show combined file sizes when selection is done into icon-view
https://bugs.kde.org/show_bug.cgi?id=279372 --- Comment #7 from Kartik --- Hello Maik, I had some doubts regarding the Stack View implementation. Currently, ItemPropertiesTab is inheriting DExpanderBox. I plan to implement a QStackedLayout within the constructor of ItemPropertiesTab, and instantiate two DExpanderBox for each of the pages of the Stack View, and populate them as in the current implementation. I might still have to inherit DExpanderBox (or some other appropriate Class), to allow readSettings() and writeSettings(). Is this an appropriate implementation? Thanks Kartik. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 279372] Show combined file sizes when selection is done into icon-view
https://bugs.kde.org/show_bug.cgi?id=279372 --- Comment #9 from Kartik --- Hello Gilles, I've submitted a patch for the implementation you suggested. https://invent.kde.org/kde/digikam/-/merge_requests/20 Thanks Kartik -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 361693] Crash when removing breakpoint in Review mode (commit action)
https://bugs.kde.org/show_bug.cgi?id=361693 Kartik C changed: What|Removed |Added CC||kartiksc...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
