OS: Gentoo amd64 Version digiKam: 2.0.0_rc Reproducible: Always Steps to reproduce: A1) Add two face tags to an photo A2) Switch to another photo and back B1) Add one face tag to a photo B2) Add a second one but click "cancel" instead of confirm B3) Switch to another photo and back Expected result: A) Two face tags/tag regions B) One face tag/tag region (the first one) Actual result: A) One face tag/tag regions (the one created at last) B) No face tag/tag region While testing the face tag functionality (as well as detection/recognition) i recognized that pictures which got two (maybe also more) face tags, lost all face tags but the last [time] one. All "normal" tags in the /People/NAME hierarchy where still available. After some investigation in the database i found the tag regions stored in the "ImageTagProperties" table, e.g. imageid tagid property value 11504 24 tagRegion <rect x="1292" y="1039" width="222" height="297"/> The name is stored in the "TagProperties" AFAIK. If i add a new face tag first a temporary line in "ImageTagProperties" is created: imageid tagid property value 11504 24 tagRegion <rect x="1292" y="1039" width="222" height="297"/> 11504 -1 autodetectedFace <rect x="1429" y="1163" width="188" height="240"/> The temporary tag region is persistent as long as i don't enter a name and confirm the tag (region). If i confirm the tag (region) in digiKam only the new tag (region) is persistent in the database, the old one is deleted. imageid tagid property value 11504 25 tagRegion <rect x="1429" y="1163" width="188" height="240"/> If i hit "cancel" at the current temporary tag in digiKam, both lines are deleted, the temporary as well as the old tag region. If i hit two face tags at last with the same name, both are saved, but not the face tags i added before. I guess this is not the intended behavior, would expect two tag regions. Tag regions are both visible in digiKam as long as i switch to another photo and back. The behavior is reproducible. Does somebody can confirm this? Or maybe knows the responsible code snippet? (Tag regions/face tags are also not embedded in the metadata of files like normal tags, only mentioned here, that is another bug/missing feature)
I tried to faithfully replay this bug, including watching the database. I could not reproduce the behavior as described, for me the old entries stayed as they should. The FaceGroup will instruct its FacePipeline to execute the action in a thread; from there (facepipeline.cpp:581) the relevant code is called, FaceIface::confirmName (faceiface.cpp:811). The "autodetected" entry with the Unknown Person tag is removed (831), then the new one added (835).
I can confirm the behavior - only last tag is saved. Have a photo with 3 people, tagging them all, then moving to the next photo in the album. Then going back and see that only last tag is saved. That's annoying. Let me know if additional info is required.
In the simplest test case, I manually add three new faces by clicking on the icon and then drawing the rectangle. Then I confirm a name for all three of them. Go to the next photo, back, all is well. I cannot reproduce any problem.
I believe it can be not reproducible on your setup. But it happens on mine one(at least). Can I provide any logs, db or any other debug information to clarify the issue?
Are you compiling from source? Then I would prepare a patch four you to apply to collect debug info
Created attachment 62804 [details] Debug statements This is a patch on current git (wont work with 2.0) Ensure 50003 is enabled in kdebugdialog and start the patched digikam on a console The idea is to prepare a scenario where the problem can be reproduced each time, like a certain photo with three manually added regions. (->) Confirm them, go to the next photo, and back. If the problem has shown, please give me the console messages since "->".
Hi, i have time again to look at this issue. I cloned digikam-software-compilation from anongit today, patched and compiled it. I did not use a clean environment (database etc.), but the one i used also in the first post. Issue is still alive, following are the logs. Three face tags added manual, switched to next image and back. The last tag survives. digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FaceGroup::slotAssigned: Clicked Assign, accepting true true false false true Digikam::RegionFrameItem(0x7fb1927ce040, parent = 0x7fb1900a6a10, pos = QPointF(156.046, 34) , z = 0 , flags = ( ) ) DatabaseFace(2, image 14925, tag -1, regionQRect(1407,306 1046x1143) digikam(21532)/digikam (core) Digikam::FacePipeline::confirm: Called confirm 14925 DatabaseFace(2, image 14925, tag -1, regionQRect(1407,306 1046x1143) 24 QRect(1407,306 1046x1143) digikam(21532)/digikam (core) Digikam::DatabaseWriter::process: Confirming entry DatabaseFace(2, image 14925, tag -1, regionQRect(1407,306 1046x1143) 24 QRect(1407,306 1046x1143) digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FaceGroup::slotAssigned: Clicked Assign, accepting true true false false true Digikam::RegionFrameItem(0x7fb1927d26d0, parent = 0x7fb1900a6a10, pos = QPointF(145.953, 101) , z = 0 , flags = ( ) ) DatabaseFace(2, image 14925, tag -1, regionQRect(1316,909 793x837) digikam(21532)/digikam (core) Digikam::FacePipeline::confirm: Called confirm 14925 DatabaseFace(2, image 14925, tag -1, regionQRect(1316,909 793x837) 25 QRect(1316,909 793x837) digikam(21532)/digikam (core) Digikam::DatabaseWriter::process: Confirming entry DatabaseFace(2, image 14925, tag -1, regionQRect(1316,909 793x837) 25 QRect(1316,909 793x837) digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FaceGroup::slotAssigned: Clicked Assign, accepting true true false false true Digikam::RegionFrameItem(0x7fb19101f710, parent = 0x7fb1900a6a10, pos = QPointF(28.9467, 28) , z = 0 , flags = ( ) ) DatabaseFace(2, image 14925, tag -1, regionQRect(261,252 595x612) digikam(21532)/digikam (core) Digikam::FacePipeline::confirm: Called confirm 14925 DatabaseFace(2, image 14925, tag -1, regionQRect(261,252 595x612) 26 QRect(261,252 595x612) digikam(21532)/digikam (core) Digikam::DatabaseWriter::process: Confirming entry DatabaseFace(2, image 14925, tag -1, regionQRect(261,252 595x612) 26 QRect(261,252 595x612) digikam(21532)/digikam (core) Digikam::FacePipeline::FacePipelinePriv::checkFinished: Check for finish: 0 packages, 0 infos to filter, hasFinished() true digikam(21532)/digikam (core) Digikam::FaceTagsEditor::databaseFaces: rect found as QRect(261,252 595x612) for attribute "tagRegion" tag 26
Created attachment 62845 [details] Digikam debug log with patch 201108131221 Inline looks not so nice, thus an attachment with the log.
Created attachment 63163 [details] Debug patch 2 Thanks a lot. Looks all fine though, the methods that should be called are called. But in the end, I can see that only one face is found. Here comes the next iteration...
Created attachment 63172 [details] Debug patch 2 log Hey, cloned the repository today, patched and compiled it with both patches and did the same procedure: add three face tags to an image without face tag, switch to next image and back. Last face tag survives. Attached the log. Should i also do the same with a clean environment? In my case fresh config, just one image/collection but with MySQL database configuration.
Apparently the first part of your problem is that the Unknown Person tag is not detected and the tag id -1 is used. Later on, this is taken unchecked as a wildcard value to remove entries from any tags within an image. Do you have a tag People/Unknown?
Git commit 4a7af86fb0a65fedd31ac2b5ac004d04907d740c by Marcel Wiesweg. Committed on 28/08/2011 at 11:20. Pushed by mwiesweg into branch 'master'. Fail early if an ImageTagPair is created with either invalid image id or invalid tag id CCBUG: 277169 M +22 -2 libs/database/imagetagpair.cpp http://commits.kde.org/digikam/4a7af86fb0a65fedd31ac2b5ac004d04907d740c
In that database i have only three tags with three names i started with and use now for testing. No People/Unknown or so. The "normal" tags are set correct: if i set three face tags also the "normal" tags are set (People\NAME), but does not disappear as the face tags (but the last one) do. In the "Tags" table also only the three with names i used appear (after some Digikam tags like colors). Will clone the repository with the commit now and test again.
Created attachment 63188 [details] Debug patch 2 + commit log Still not working, the three normal tags are created + the last face tag.
Git commit ad149fa7b323b1e46c835dd91cd7c180c3ca3c45 by Marcel Wiesweg. Committed on 28/08/2011 at 16:18. Pushed by mwiesweg into branch 'master'. Improve null-object handling in ImageTagPair and TagProperties. When attempt is made to create an object with in invalid id, now a null object is created and methods detect this properly, refusing to edit the db with invalid parameters. (shows that the SharedNull paradigm is not always so much more elegant than d = 0) CCBUG: 277169 M +39 -6 libs/database/tagproperties.cpp M +20 -13 libs/database/imagetagpair.cpp http://commits.kde.org/digikam/ad149fa7b323b1e46c835dd91cd7c180c3ca3c45
Can you try again current git? I could reproduce some problems only with a fresh database.
Created attachment 63216 [details] Log for debug patch 1 + 2 + commits Digikam compiled from todays git clone, still the same:) I will maybe backup the Digikam configs/database and test with a fresh initialized Digikam later.
Created attachment 63241 [details] Debug patch 3 Some more statements. It seems that the method which finds or creates the unknown person tag still fails, which is strange as you say you have a People/Unknown tag (if not, it should be created once you manually add a face).
Created attachment 63566 [details] Debug patch 3 log Hi again. Attached the log for debug patch 3 (+2 +1) with Git clone from 20110911 ~1900. I have no "People/Unknown" tag! It also gets not created. In the "Tags" table i see the "People" entry with id 4 and pid 0 (no parent tag), but no "Unkown" tag (with pid 4 for parent tag "People"). What i have are are some entries in the "TagProperties" table: tagid property value -1 internalTag NULL -1 person NULL -1 unknownPerson NULL will post the SQL table dumps if needed
Created attachment 63567 [details] Tag tables SQL dumps The tag tables as SQL dumps.
The "-1" entries seem to be your problem now. Their are invalid and were introduced by bugs fixed with my commits above. Nonetheless, I dont know how many users are affected, so we need a workaround.
Git commit 03d3b2766d56e1d9e86cabeea64fe2c7715f7b5a by Marcel Wiesweg. Committed on 14/09/2011 at 21:57. Pushed by mwiesweg into branch 'master'. Ignore "-1" tag ids when retrieving tags by property Works around earlier bugs which introduced these invalid entries into the db table. CCBUG: 277169 M +6 -0 libs/database/tagscache.cpp http://commits.kde.org/digikam/03d3b2766d56e1d9e86cabeea64fe2c7715f7b5a
Still any problem left here with current git?
Compiled 2.2.0 on gentoo today, face tags work! But i have now 2x "Unknown" tag. Don't know if it is related to this issue.
Felix, > «But i have now 2x "Unknown"tag."» ==> Do you mean this issue : https://bugs.kde.org/show_bug.cgi?id=283323 Gilles Caulier
Felix, This file still valid using digiKam 2.4 ? Do you see my comment #25 ? Gilles Caulier
Hi Gilles, i recently used the functionality in combination with face detection, seems to work in 2.6. I will reopen the bug if i find a similar issue or make a new bug. Next step is the integration in XMP metadata. Thanks Felix Leif