[digikam] [Bug 416462] fuzzy search doesn't find photo which is rotated
https://bugs.kde.org/show_bug.cgi?id=416462 --- Comment #10 from Mario Frank --- (In reply to Daniel from comment #8) > Hi all, > > so I think they are 2 different cases here (both could theoretically be > solved by the same solution, but probably shouldn't), and I don't think the > solution (at least for similar pictures, as written at the end) needs to be > complicated (maybe I'm naive). > > > A) The image is already correctly oriented before importing, using a set > exif orientation flag. > > If the image is imported (and autorotate is enabled), this flag gets removed > and the images is fully rotated (that's my understanding). > > The solution to this would be to read the orientation flag when doing the > fuzzy search. Before running the hash algorith on it, the pictures need to > be rotated according the flag. This should be almost trivial. > > B) The image is rotated after it has been imported, different to the > original orientation. > > The solution to this could be to search the hashes for all 4 (let's ignore > mirrors for now) orientations of the search query picture. I don't think > this would be difficult or slow (as to my experience the search algorithm is > very fast/instant). This could be extended to only search for additional > orientations, if no result is found. If it is technically not possible, > maybe someone can explain to me why :) > > > Ok, this would have one major drawback: It could only find similar pictures, > not duplicate entries. But if you assume all images are correctly rotated in > the digikam collection, finding duplicates wouldn't be a problem anymore… > > > Daniel Hi Daniel, first of all, the similarity search is only quite fast since the fingerprints are computed before searching and excessive caching is used. The computation of the fingerprints is quite slow. Especially for users with >100k images which is not much. We should never forget that. But I think you have a point. The orientation flag could help. I see two possible ways: 1) For every image, two fingerprints are generated - one with current orientation and one with original orientation. And the user can select for the search whether he wants to search by original or current orientation. This has drawbacks, although in most cases not grave ones. First, in many cases, both fingerprints of the image will be identical which is a waste of memory (but this could be optimised). And second, the database scheme needs to be adopted (not really a problem). And not to forget, the fingerprint generation will be slower - it is hard to estimate how much, since the degree of rotated images differs from user to user. But the user can decide depending on the situation, which is good. This could be a solution. 2) The user decides in the fingerprint generation configuration whether fingerprints shall be generated for the current orientation or the original one. In this case, there is no additional memory consumption and rotated images should be recognised as similars. One drawback is that if the user changes the configuration, the fingerprints partially need to be regenerated. But this drawback can be reduced. Here, we also have a possible solution. If the fingerprint entry in the DB gets an additional orientation flag, we can compare the orientation flag with the current configuration when refreshing fingerprints. So only the fingerprints of the changed and rotated images would be updated. But I must admit that I do not know what information the orientation flag provides. Does it state whether or not the image was rotated or does it give the angle (90/19/270°)? Regards, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416462] fuzzy search doesn't find photo which is rotated
https://bugs.kde.org/show_bug.cgi?id=416462 --- Comment #9 from Mario Frank --- (In reply to caulier.gilles from comment #7) > Hi Mario and happy new year, > > Well, i don't have a best idea, excepted the fact to use a deep learning > method. Typically, We have a bug entry to detect and recognize monuments, > places, animals, flower, tree, and more. This can be certainly extended to > detect similar image based on shape. > > I don't want mean to use DNN for similarity, but to check how rotation > problem is treated with the DNN method, and to see if the algorithm is > applicable to the current similarity code. > > For me the DNN performance is poor, especially if video cards acceleration > is not used. Similarity algorithm has acceptable performances as well. > > So yes, a GoSC 2022 project can be proposed around this topic. > > Gilles Hi Gilles, and I wish you a happy year, too. I already had the same idea concerning DNN some time ago. And I agree that DNN may not be our friend concerning performance in this case. There seem to be concepts for detecting rotated objects. But an image may have a huge amount of objects. And I did not find a description of recognising whether the complete image is rotated. In principle, this should be possible. But again, the performance could be a big problem. Nevertheless, it could be worth a try. Regards, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 416462] fuzzy search doesn't find photo which is rotated
https://bugs.kde.org/show_bug.cgi?id=416462 Mario Frank changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #6 from Mario Frank --- (In reply to Daniel from comment #5) > (In reply to caulier.gilles from comment #4) > Hi Gilles, > > a happy new year too :) > > Can you check if problem remain with digiKam 7.5.0 pre-release bundle > > I just checked and the problem still persists. > > To be a more verbose: > > If a image A.jpeg is imported which has exif orientation set (for example > Orientation : Rotate 90 CW), digikam will rotate it and adapt the file (and > lets say save it to B.jpeg). > > If you search with the original image A.jpeg (not touched by digikam) in the > fuzzy search, the imported image (B.jpeg) is not found. So I think the main > issue is that the orientation flag isn't adhered to when searching using > fuzzy search. (Supported by the fact that the orientation of the image > preview in the fuzzy search box of A.jpeg is wrong (just horizontal)) Hi Daniel, I am experiencing this flaw for a long time. Solving this is technically difficult. For every image, a HAAR fingerprint is calculated. This is comparable to a heatmap concerning brightness. So every brightness point gets a coordinate which is calculated on the "current" orientation of the image. If the image was rotated in digiKam, the rotation flag is set. In this case, it could with some effort be possible to compute the heatmap "unoriented". But in some cases the information about rotation is missing as the image was imported in this orientation but without orientation info. The HAAR concept is not orientation-agnostic. In order to support rotated images, every image would need at least 4 heatmaps (for rotation) and even much more as the image cold have been mirrored. And even then, it would be necessary to compare every heatmap of the one image with every respective one of the other image for similarity. It is possible to implement this. But the similarity search would have an unacceptable performance - I already tried that. So I conclude that I do not think that this issue can be solved with the current similarity comparison concept without grave effect on the performance - at least not with combinatorial comparison. At least, I think this is a bigger project, e.g. something for GSoC. There are concepts that may be more appropriate (point distance comparison or even machine learning based) and the digiKam database and fuzzy/similarity search module in principle support using multiple comparison concepts since after GSoC2017. Perhaps Gilles has another idea. Regards, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 426116] Compact database (unique block instead of loose files)
https://bugs.kde.org/show_bug.cgi?id=426116 Mario Frank changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #5 from Mario Frank --- Hi Jo, Depending on the OS, the default location of databases may be different. So there is no easy catch for all OSs. Usually, the location is defined in the digikamrc. The digikamrc contains the following settings: Database Name=/path/to/core/db/ Database Name Face=/path/to/core/db/ Database Name Similarity=/path/to/core/db/ Database Name Thumbnails=/path/to/core/db/ In your case, you could move the files to /home/library/application support/digikam/sqlite_db/ and set the values to Database Name=/home/library/application support/digikam/sqlite_db/ Database Name Face=/home/library/application support/digikam/sqlite_db/ Database Name Similarity=/home/library/application support/digikam/sqlite_db/ Database Name Thumbnails=/home/library/application support/digikam/sqlite_db/ When starting digiKam again, this should work without any problems. Also, there is a command line option for digiKam: --database-directory this one will search for the db files in the specified directory. Does this solve your problem? Cheers, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 402659] Find Similar context menu action shows no result if used on an image without a fingerprint.
https://bugs.kde.org/show_bug.cgi?id=402659 Mario Frank changed: What|Removed |Added Version Fixed In||6.0.0 Resolution|--- |FIXED Status|REPORTED|RESOLVED Latest Commit||https://commits.kde.org/dig ||ikam/b7908fc9894be318e2353a ||7bc1c4fdab28ded4ef --- Comment #1 from Mario Frank --- Git commit b7908fc9894be318e2353a7bc1c4fdab28ded4ef by Mario Frank. Committed on 09/01/2019 at 10:23. Pushed by mfrank into branch 'master'. If fuzzy image search is triggered for an image that currently has no or only dirty fingerprint, generate the fingerprint first. FIXED-IN: 6.0.0 M +2-1NEWS M +51 -0core/libs/database/similaritydb/similaritydb.cpp M +19 -0core/libs/database/similaritydb/similaritydb.h M +16 -0core/utilities/searchwindow/searchmodificationhelper.cpp https://commits.kde.org/digikam/b7908fc9894be318e2353a7bc1c4fdab28ded4ef -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377523] Automated option to delete duplicated pictures
https://bugs.kde.org/show_bug.cgi?id=377523 Mario Frank changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||mario.fr...@uni-potsdam.de --- Comment #2 from Mario Frank --- *** This bug has been marked as a duplicate of bug 261831 *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 261831] Auto-Process results from duplicates search
https://bugs.kde.org/show_bug.cgi?id=261831 Mario Frank changed: What|Removed |Added CC||sven.schicked...@gmail.com --- Comment #6 from Mario Frank --- *** Bug 377523 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 392025] Wishlist: ability to separate images by similarity (instead of album or format)
https://bugs.kde.org/show_bug.cgi?id=392025 Mario Frank changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #2 from Mario Frank --- Hi Jens, currently, only few similarity values are really stored in database. This was not possible before 6.0.0 beta, as the database structure did not allow this without really nasty constructions. Especially the similarities used by the duplicates search are not stored easily extractible. To implement your wish, some (not minor) work has to be done on the HaarIface. Sadly, I did not have much time lately. I'll try to get some time free to prepare a better use of the new similarity database. But this will probably not be part of the final 6.0.0 release. Regards, Mario -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 394489] Graphical glitches on panel
https://bugs.kde.org/show_bug.cgi?id=394489 Mario Frank changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 394489] Graphical glitches on panel
https://bugs.kde.org/show_bug.cgi?id=394489 Mario Frank changed: What|Removed |Added CC||skala.vacla...@seznam.cz --- Comment #19 from Mario Frank --- *** Bug 395086 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395086] Icons in UI is black or from firefox
https://bugs.kde.org/show_bug.cgi?id=395086 Mario Frank changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mario.fr...@uni-potsdam.de Resolution|--- |DUPLICATE --- Comment #6 from Mario Frank --- *** This bug has been marked as a duplicate of bug 394489 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 394489] Graphical glitches on panel
https://bugs.kde.org/show_bug.cgi?id=394489 Mario Frank changed: What|Removed |Added CC||davidlev...@yahoo.com --- Comment #20 from Mario Frank --- *** Bug 395125 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 395125] Icons drawn improperly on the desktop and in the task bar
https://bugs.kde.org/show_bug.cgi?id=395125 Mario Frank changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank --- *** This bug has been marked as a duplicate of bug 394489 *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 390136] digiKam crashes when launching scan and recognize faces
https://bugs.kde.org/show_bug.cgi?id=390136 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #5 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Žygimantas Bruzgys from comment #4) > Unfortunately, when it crashed I was not able to get the BT. And it seems > that it was a transient crash, since after a restart it worked fine. I think > that in order to reproduce this crash I would need to clear my faces DB, > which I would not want to do right now. > > As this seems to be dependent on an external dependency, which seems to be > configured correctly in a release image, I'll mark the bug as resolved. Hey Žygimantas, if you have a SQLite DB, you can just copy your current faces DB file to some safe place so you have a backup. Then you can delete the original face DB file and digiKam will automatically generate the empty faces DB. Then you could probably get a stack trace. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 388981] Ability to set "Reference Album" for Find Duplicates
https://bugs.kde.org/show_bug.cgi?id=388981 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hey, this is indeed currently not supported. And I agree with you that this is a nice feature. I have now more free time - So I can do some digiKam development again. I will try to implement the feature for 5.9. There already are some topics in the similarity subsystem that need to be covered. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 381625] Copying/Moving photograph files between albums does not give Overwrite/Rename/Cancel options if file with same name exists in the destination album.
https://bugs.kde.org/show_bug.cgi?id=381625 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Maik Qualmann from comment #5) > I also do not know whether I would like this dialog window. Personally I had > never desire to decide by the small thumbnail and the file size, whether it > is the same file. I would suggest that we rename an existing file with a > counter and always copy it. Gilles, Simon and Mario how do you see that? > > Maik Hi Maik, I think you are right - the thumbnail and file size are not always sufficient to decide whether the files are identical. The solution using a counter would be a valid solution. But in this case, the user should be informed that there were clashes so he can review the files. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 385368] DigiKam causes my machine to blue screen (crash) during installation on Windows 10
https://bugs.kde.org/show_bug.cgi?id=385368 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Platform|Other |MS Windows OS|Linux |MS Windows -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 383326] Moving a tag does not update the parent tag correctly
https://bugs.kde.org/show_bug.cgi?id=383326 --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hey meku, yes, I saw these errors yesterday, too. Getting rid of the errors is easy but does not solve the main problem that lft and rgt are not updated properly. If noone does solve the problem before I do, I will try again to solve it tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 383326] Moving a tag does not update the parent tag correctly
https://bugs.kde.org/show_bug.cgi?id=383326 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 383326] Moving a tag does not update the parent tag correctly
https://bugs.kde.org/show_bug.cgi?id=383326 --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- I got a small MySQL database to work right now and was able to reproduce the corruption. I even got an error message in the trace: " digikam.dbengine: Prepare failed! digikam.dbengine: Failure executing query: "LOCK TABLE Tags WRITE;" Error messages: "QMYSQL3: Der Befehl konnte nicht initialisiert werden" "This command is not supported in the prepared statement protocol yet" 1295 2 " So there definitely is a problem and as I see it, this will have not worked for a longer time. Looks like an incomplete migration from dbconfig to source code. I will try to fix it. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 383326] New: Moving a tag does not update the parent tag correctly
https://bugs.kde.org/show_bug.cgi?id=383326 Bug ID: 383326 Summary: Moving a tag does not update the parent tag correctly Product: digikam Version: 5.7.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Database-Mysql Assignee: digikam-bugs-n...@kde.org Reporter: mario.fr...@uni-potsdam.de Target Milestone: --- >From Nabble: http://digikam.1695700.n4.nabble.com/Browsing-by-tag-sometimes-shows-items-with-alternative-tag-td4703595.html The user experienced a tag in tag view containing an image that has neither this tag nor a child tag assigned. The image was only shown if images from the subtags are configured to be shown, too. After analysing the database values for the tags that were assigned to the image, he found out, that the lft and rgt values were in the range of the tag in which he was seeing the image. He assumes that he has moved the really assigned tag some time ago. After looking at the code, I assume there is a bug in the case of MySQL databases. In TagDragDropHandler::dropEvent, the call CoreDbAccess().db()->moveTag(newParentTag) is emitted if a MySQL database is configured. This is done in order to update the lft and rgt values as this is not done by triggers, opposed to QSLite. But in CoreDB::moveTag the parameter is never used, as it is commented out. I can not test it as I do not have a MySQL database. Also, I am not sure how to fix it without the possibility for testing. I rated the severity as major as the database is corrupted. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 218312] Make search results to exclude children's tags
https://bugs.kde.org/show_bug.cgi?id=218312 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version Fixed In||5.7.0 Resolution|--- |FIXED Latest Commit||https://commits.kde.org/dig ||ikam/7306b537f67156bbc77522 ||861522a7e17531a9b5 --- Comment #5 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 7306b537f67156bbc77522861522a7e17531a9b5 by Mario Frank. Committed on 12/07/2017 at 10:17. Pushed by mfrank into branch 'master'. Marked bug 218312 - "Make search results to exclude children's tags" as fixed as this bug was in fact already fixed in 5.5.0. Confirmed the resolution in current 5.7.0 AppImage. As the new tag selection supports selecting single tags, the subtags are searched only if they are marked themselves. FIXED-IN: 5.7.0 M +2-2NEWS https://commits.kde.org/digikam/7306b537f67156bbc77522861522a7e17531a9b5 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377719] Cannot rename file with overwrite [patch]
https://bugs.kde.org/show_bug.cgi?id=377719 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #20 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to caulier.gilles from comment #18) > Simon, Maik, Mario, > > The next 5.6.0 is planed this Sunday. I propose to delay by 2 weeks this > release to permit to generate a test AppImage including this patch (and also > other recent commits from Simon), at least to see if nothing is broken > through users feedback. > > Gilles Hey, I agree. I am currently quite busy with preparations for a publication. And I would like to test some scenarios and fixe some more bugs. You already pointed me to some problems. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377197] Customize grouping behaviour [patch]
https://bugs.kde.org/show_bug.cgi?id=377197 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #31 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Maik Qualmann from comment #30) > I have not found any problems with the V8 patch. But I think we do not need > to distinguish between BQM, light table, renaming, etc. An option for all > cases (yes, no, ask) should be enough. Gilles, Mario what is your point of > view? > > Maik I agree. Keep it simple if there is no really good reason. And I currently see none. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 183425] Advanced search by tags : "any tags" option does not work
https://bugs.kde.org/show_bug.cgi?id=183425 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/660782be8137d8448ef10e ||5e944a2dd213d781cc Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #21 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 660782be8137d8448ef10e5e944a2dd213d781cc by Mario Frank. Committed on 11/04/2017 at 17:27. Pushed by mfrank into branch 'master'. Added an overall improvement of fuzzy, duplicates and extended search. 1) Users can now restrict the results of fuzzy image/drop/sketch search to be in specific albums. 2) Users can now select both tags and albums in duplicates search and restrict the set of images in which duplicates are searched with logical operations (in selected albums or/and tags, in selected albums but not tags and vice versa and only in selected objects of current tab) 3) In extended search, the tags selection can also be restricted such that images must be either tagged with at least one of or with all selected tags. Related: bug 353331, bug 300565 M +7-1NEWS M +31 -3app/utils/searchmodificationhelper.cpp M +11 -0app/utils/searchmodificationhelper.h A +307 -0libs/album/albumselectioncomponent.cpp [License: UNKNOWN] * A +121 -0libs/album/albumselectioncomponent.h [License: GPL (v2+)] M +248 -173 libs/album/albumselectors.cpp M +34 -19 libs/album/albumselectors.h M +7-0libs/database/coredb/coredbsearchxml.cpp M +1-0libs/database/coredb/coredbsearchxml.h M +1-0libs/database/dbjobs/dbjob.cpp M +11 -0libs/database/dbjobs/dbjobinfo.cpp M +4-0libs/database/dbjobs/dbjobinfo.h M +119 -30 libs/database/haar/haariface.cpp M +30 -8libs/database/haar/haariface.h M +32 -10 libs/database/item/imagelister.cpp M +44 -0libs/database/item/imagequerybuilder.cpp M +6-4libs/settings/applicationsettings.cpp M +3-0libs/settings/applicationsettings.h M +11 -0libs/settings/applicationsettings_miscs.cpp M +1-0libs/settings/applicationsettings_p.cpp M +2-0libs/settings/applicationsettings_p.h M +1-1utilities/facemanagement/facescandialog.cpp M +69 -22 utilities/fuzzysearch/findduplicatesview.cpp M +83 -21 utilities/fuzzysearch/fuzzysearchview.cpp M +1-0utilities/fuzzysearch/fuzzysearchview.h M +6-1utilities/maintenance/duplicatesfinder.cpp M +1-1utilities/maintenance/duplicatesfinder.h M +4-4utilities/maintenance/maintenancedlg.cpp M +2-1utilities/maintenance/maintenancemngr.cpp M +72 -27 utilities/searchwindow/searchfields.cpp M +18 -4utilities/searchwindow/searchfields.h The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://commits.kde.org/digikam/660782be8137d8448ef10e5e944a2dd213d781cc -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums [patch]
https://bugs.kde.org/show_bug.cgi?id=353331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/660782be8137d8448ef10e ||5e944a2dd213d781cc Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #27 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 660782be8137d8448ef10e5e944a2dd213d781cc by Mario Frank. Committed on 11/04/2017 at 17:27. Pushed by mfrank into branch 'master'. Added an overall improvement of fuzzy, duplicates and extended search. 1) Users can now restrict the results of fuzzy image/drop/sketch search to be in specific albums. 2) Users can now select both tags and albums in duplicates search and restrict the set of images in which duplicates are searched with logical operations (in selected albums or/and tags, in selected albums but not tags and vice versa and only in selected objects of current tab) 3) In extended search, the tags selection can also be restricted such that images must be either tagged with at least one of or with all selected tags. Related: bug 300565, bug 183425 M +7-1NEWS M +31 -3app/utils/searchmodificationhelper.cpp M +11 -0app/utils/searchmodificationhelper.h A +307 -0libs/album/albumselectioncomponent.cpp [License: UNKNOWN] * A +121 -0libs/album/albumselectioncomponent.h [License: GPL (v2+)] M +248 -173 libs/album/albumselectors.cpp M +34 -19 libs/album/albumselectors.h M +7-0libs/database/coredb/coredbsearchxml.cpp M +1-0libs/database/coredb/coredbsearchxml.h M +1-0libs/database/dbjobs/dbjob.cpp M +11 -0libs/database/dbjobs/dbjobinfo.cpp M +4-0libs/database/dbjobs/dbjobinfo.h M +119 -30 libs/database/haar/haariface.cpp M +30 -8libs/database/haar/haariface.h M +32 -10 libs/database/item/imagelister.cpp M +44 -0libs/database/item/imagequerybuilder.cpp M +6-4libs/settings/applicationsettings.cpp M +3-0libs/settings/applicationsettings.h M +11 -0libs/settings/applicationsettings_miscs.cpp M +1-0libs/settings/applicationsettings_p.cpp M +2-0libs/settings/applicationsettings_p.h M +1-1utilities/facemanagement/facescandialog.cpp M +69 -22 utilities/fuzzysearch/findduplicatesview.cpp M +83 -21 utilities/fuzzysearch/fuzzysearchview.cpp M +1-0utilities/fuzzysearch/fuzzysearchview.h M +6-1utilities/maintenance/duplicatesfinder.cpp M +1-1utilities/maintenance/duplicatesfinder.h M +4-4utilities/maintenance/maintenancedlg.cpp M +2-1utilities/maintenance/maintenancemngr.cpp M +72 -27 utilities/searchwindow/searchfields.cpp M +18 -4utilities/searchwindow/searchfields.h The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://commits.kde.org/digikam/660782be8137d8448ef10e5e944a2dd213d781cc -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 300565] When selecting folders, subfolders are not selected
https://bugs.kde.org/show_bug.cgi?id=300565 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/dig ||ikam/660782be8137d8448ef10e ||5e944a2dd213d781cc Resolution|--- |FIXED --- Comment #7 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 660782be8137d8448ef10e5e944a2dd213d781cc by Mario Frank. Committed on 11/04/2017 at 17:27. Pushed by mfrank into branch 'master'. Added an overall improvement of fuzzy, duplicates and extended search. 1) Users can now restrict the results of fuzzy image/drop/sketch search to be in specific albums. 2) Users can now select both tags and albums in duplicates search and restrict the set of images in which duplicates are searched with logical operations (in selected albums or/and tags, in selected albums but not tags and vice versa and only in selected objects of current tab) 3) In extended search, the tags selection can also be restricted such that images must be either tagged with at least one of or with all selected tags. Related: bug 353331, bug 183425 M +7-1NEWS M +31 -3app/utils/searchmodificationhelper.cpp M +11 -0app/utils/searchmodificationhelper.h A +307 -0libs/album/albumselectioncomponent.cpp [License: UNKNOWN] * A +121 -0libs/album/albumselectioncomponent.h [License: GPL (v2+)] M +248 -173 libs/album/albumselectors.cpp M +34 -19 libs/album/albumselectors.h M +7-0libs/database/coredb/coredbsearchxml.cpp M +1-0libs/database/coredb/coredbsearchxml.h M +1-0libs/database/dbjobs/dbjob.cpp M +11 -0libs/database/dbjobs/dbjobinfo.cpp M +4-0libs/database/dbjobs/dbjobinfo.h M +119 -30 libs/database/haar/haariface.cpp M +30 -8libs/database/haar/haariface.h M +32 -10 libs/database/item/imagelister.cpp M +44 -0libs/database/item/imagequerybuilder.cpp M +6-4libs/settings/applicationsettings.cpp M +3-0libs/settings/applicationsettings.h M +11 -0libs/settings/applicationsettings_miscs.cpp M +1-0libs/settings/applicationsettings_p.cpp M +2-0libs/settings/applicationsettings_p.h M +1-1utilities/facemanagement/facescandialog.cpp M +69 -22 utilities/fuzzysearch/findduplicatesview.cpp M +83 -21 utilities/fuzzysearch/fuzzysearchview.cpp M +1-0utilities/fuzzysearch/fuzzysearchview.h M +6-1utilities/maintenance/duplicatesfinder.cpp M +1-1utilities/maintenance/duplicatesfinder.h M +4-4utilities/maintenance/maintenancedlg.cpp M +2-1utilities/maintenance/maintenancemngr.cpp M +72 -27 utilities/searchwindow/searchfields.cpp M +18 -4utilities/searchwindow/searchfields.h The files marked with a * at the end have a non valid license. Please read: http://techbase.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page. https://commits.kde.org/digikam/660782be8137d8448ef10e5e944a2dd213d781cc -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums [patch]
https://bugs.kde.org/show_bug.cgi?id=353331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Attachment #104963|0 |1 is obsolete|| --- Comment #24 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104965 --> https://bugs.kde.org/attachment.cgi?id=104965=edit Updated patch for improvements Updated the patch to the current state of the master branch and added some comments concerning target albums. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums [patch]
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #23 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to caulier.gilles from comment #22) > Not better terminology for the moment. Just put some comment to clarify it... > > Gilles Okay, I would commit the changes with additional comments. Is that okay for you? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 378625] Very slow start
https://bugs.kde.org/show_bug.cgi?id=378625 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #4 from Mario Frank <mario.fr...@uni-potsdam.de> --- I hope that my adoptions solve the problem. Sadly, I cannot reproduce it - neither with 5.5, nor with 5.6 or current master branch. The next AppImage will contain the adoptions. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 378625] Very slow start
https://bugs.kde.org/show_bug.cgi?id=378625 --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 29ee560d14ffb22d37b85a55f9d666a116097652 by Mario Frank. Committed on 11/04/2017 at 12:16. Pushed by mfrank into branch 'master'. Ignore the signal that a search album was added until the find duplicates view is active. This is already done in fuzzy search view. Otherwise, the automated sorting of entries is triggered which is not necessary. Hopefully, this solves bug id 378625. M +17 -1utilities/fuzzysearch/findduplicatesview.cpp M +1-0utilities/fuzzysearch/findduplicatesview.h M +1-0utilities/fuzzysearch/fuzzysearchview.cpp https://commits.kde.org/digikam/29ee560d14ffb22d37b85a55f9d666a116097652 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums [patch]
https://bugs.kde.org/show_bug.cgi?id=353331
--- Comment #21 from Mario Frank <mario.fr...@uni-potsdam.de> ---
(In reply to caulier.gilles from comment #20)
> writer.writeField(QLatin1String("noeffect_targetAlbums"), SearchXml::OneOf);
> writer.writeValue(targetAlbums);
>
> ... why to call "noeffect_targetAlbums" a property which define the target
> album to process ? It's ambiguous... Or i miss understand something in your
> code ?
>
> Gilles
Hey Gilles,
The field is only set for HAAR search, i.e. fuzzy image and sketch search.
The search can be restricted to only return images if they are in one of the
target folders.
Do you have a better terminus in mind?
Cheers,
Mario
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Attachment #104892|0 |1 is obsolete|| --- Comment #19 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104963 --> https://bugs.kde.org/attachment.cgi?id=104963=edit Updated patch for improvements The AlbumSelectors class is also used in face scan. Updated calls to this class in order to prevent regression bugs in face scan. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Attachment #104874|0 |1 is obsolete|| --- Comment #18 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104892 --> https://bugs.kde.org/attachment.cgi?id=104892=edit Updated patch for improvements The new patch adds patches for https://bugs.kde.org/show_bug.cgi?id=183425 and https://bugs.kde.org/show_bug.cgi?id=300565 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 300565] When selecting folders, subfolders are not selected
https://bugs.kde.org/show_bug.cgi?id=300565 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- In https://bugs.kde.org/show_bug.cgi?id=353331 , a patch will be submitted that introduces context menus for album and tag selection where subtrees can be marked explicitly. With the patch, subtrees are not used automatically. The user can decide himself. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 183425] Advanced search by tags : "any tags" option does not work
https://bugs.kde.org/show_bug.cgi?id=183425 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #20 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104891 --> https://bugs.kde.org/attachment.cgi?id=104891=edit Draft for applicable operations on chosen tags in extended search For tags, the user can select if the images to find must be in all the chosen tags or at least in one. The patch will be uploaded here: https://bugs.kde.org/show_bug.cgi?id=353331 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #15 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104874 --> https://bugs.kde.org/attachment.cgi?id=104874=edit Proposed patch for the improvements This patch adds the following improvements to the fuzzy sidebar: Duplicates search: The user can select both tags and albums and apply one of 5 operations to the selected objects: - "One of" aka union - Search in the set of images that are either in the selected tags or albums - "Both" aka intersection - Search in the set of images that are both in the selected tags and albums - "Albums but not tags" aka difference - Search in the set of images that are in the selected albums but not in the selected tags - "Tags but not albums" aka difference - Search in the set of images that are in the selected tags but not in the selected albums - "Only selected tab" aka obvious - Search in the selected albums, if albums tab is active and in the selected tags if tags tab is active Fuzzy image (drop) search: The user can now restrict the results to be in the specified albums. Restricting to tags is technically possible but would impose complexity problems potentially leading to a slower search - depending on the tagging activities of the user. Fuzzy sketch search: The user can now restrict the results to be in the specified albums. Restricting to tags is technically possible but would impose complexity problems potentially leading to a slower search - depending on the tagging activities of the user. As I work on the current master branch, some texts are not localised. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #14 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104873 --> https://bugs.kde.org/attachment.cgi?id=104873=edit New fuzzy sidebar : fuzzy sketch search -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #13 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104872 --> https://bugs.kde.org/attachment.cgi?id=104872=edit New fuzzy sidebar : fuzzy image search -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #12 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 104871 --> https://bugs.kde.org/attachment.cgi?id=104871=edit New fuzzy sidebar : duplicates search -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372972] Find duplicates "search in drop down" only shows 1 item
https://bugs.kde.org/show_bug.cgi?id=372972 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||https://commits.kde.org/dig ||ikam/5bb8e75151f1a2ca5ade6a ||8ea7b3c1e349996f54 --- Comment #4 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 5bb8e75151f1a2ca5ade6a8ea7b3c1e349996f54 by Mario Frank. Committed on 03/04/2017 at 09:16. Pushed by mfrank into branch 'master'. Fix some minor glitches in fuzzy search sidebar: 1) In a fresh installation, the root albums in the album selection box in duplicates search are not automatically expanded. Though this is no bug (expanding is possible via double-click), we now automatically expand the root albums to not confuse users. if nothing was expanded, yet. 2) In duplicates search, the last similarity thresholds are saved. But after restart, one the range of the max similarity threshold is 90-100 until the min similarity is changed. This is an ugly glitch. Fixed that. 3) The computation of the similar images had a glitch when max similarity = min similarity (e.g. 50%) The results were only the ones with exactly 50.00 % but not also results with 50.xy as it should be. Fixed that. 4) The xml structure of the haar search queries for fuzzy and sketch search were not wellformed (the closing "search" tag was missing) Related: bug 353331 M +2-1NEWS M +3-0app/utils/searchmodificationhelper.cpp M +24 -7libs/album/albumtreeview.cpp M +7-1libs/database/haar/haariface.cpp M +1-1utilities/fuzzysearch/findduplicatesview.cpp https://commits.kde.org/digikam/5bb8e75151f1a2ca5ade6a8ea7b3c1e349996f54 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 --- Comment #11 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 5bb8e75151f1a2ca5ade6a8ea7b3c1e349996f54 by Mario Frank. Committed on 03/04/2017 at 09:16. Pushed by mfrank into branch 'master'. Fix some minor glitches in fuzzy search sidebar: 1) In a fresh installation, the root albums in the album selection box in duplicates search are not automatically expanded. Though this is no bug (expanding is possible via double-click), we now automatically expand the root albums to not confuse users. if nothing was expanded, yet. 2) In duplicates search, the last similarity thresholds are saved. But after restart, one the range of the max similarity threshold is 90-100 until the min similarity is changed. This is an ugly glitch. Fixed that. 3) The computation of the similar images had a glitch when max similarity = min similarity (e.g. 50%) The results were only the ones with exactly 50.00 % but not also results with 50.xy as it should be. Fixed that. 4) The xml structure of the haar search queries for fuzzy and sketch search were not wellformed (the closing "search" tag was missing) Related: bug 372972 M +2-1NEWS M +3-0app/utils/searchmodificationhelper.cpp M +24 -7libs/album/albumtreeview.cpp M +7-1libs/database/haar/haariface.cpp M +1-1utilities/fuzzysearch/findduplicatesview.cpp https://commits.kde.org/digikam/5bb8e75151f1a2ca5ade6a8ea7b3c1e349996f54 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 378219] Optimize includes and polish [patch]
https://bugs.kde.org/show_bug.cgi?id=378219 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- Did not have any problems compiling with your patch. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375651] Update 5.4.0 on Windows : no sound with all my videos
https://bugs.kde.org/show_bug.cgi?id=375651 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #32 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to caulier.gilles from comment #31) > Restore ? Why you delete all previous customization ? Gilles, the way I understand Op, the installation of the new version has overridden his configuration. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 208713] Quicker deletion of multiple duplicate images
https://bugs.kde.org/show_bug.cgi?id=208713 --- Comment #7 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Adam Pigg from comment #6) > And only 8+ years later ;) Well, sometimes wishes take a long time to fulfill. And some of the parts of the wish were available at least in 5.0.0. It was just not identified as fixed ;) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 377039] Network Collections cause hang on "Reading Database"
https://bugs.kde.org/show_bug.cgi?id=377039 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hey Andrew, I think I'think would help if you provide us the log written during start of digiKam. If you run digiKam from console, the log is written to stdout. There are many possible reasons. So we need some log. Cheers, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 351658] Prevent to fill whole memory when all CPU cores are used to process Maintenance tools
https://bugs.kde.org/show_bug.cgi?id=351658 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #32 from Mario Frank <mario.fr...@uni-potsdam.de> --- Potentially, your problems could be solved in the current AppImage as I restricted the count of threads that are opened in maintenance. Can you test that? The AppImages are stored here by Gilles: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376359] Sort by Image Quality (assign quality tags) ignores many images
https://bugs.kde.org/show_bug.cgi?id=376359 --- Comment #5 from Mario Frank <mario.fr...@uni-potsdam.de> --- So, here are the AppImages: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375035] Out of memory during face tagging
https://bugs.kde.org/show_bug.cgi?id=375035 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #7 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to lesf from comment #6) > After activating swap digikam doesn't crash anymore -- it eats up most of > the RAM, though. > I guess it doesn't allocate any more memory because OpenCV is miffed and > throws exceptions for every face-tagged picture: > digikam.facesengine: Default exception from OpenCV Can you test with the current AppImage again? I have done some changes in 5.5.0 which reduce the count of created threads. This may also have lead to out of memory problems. It is possible that your problem does not occur any more. The most current AppImages are always stored here by Gilles: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 373638] Digikam doesn't show any files.
https://bugs.kde.org/show_bug.cgi?id=373638 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #2 from Mario Frank <mario.fr...@uni-potsdam.de> --- Anything new here? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372680] Cannot delete files from NAS
https://bugs.kde.org/show_bug.cgi?id=372680 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #9 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to dajomu from comment #8) > Hi, > > I could not figure out why digikam could not get access to trash and I am > not even quite sure which trash it wants access to. Is it trash on my NAS or > laptop? If it is trash on my laptop, I am wondering if digikam knows where > Ubuntus' trash is located in the file system. digiKam does not access the trash of your OS. It creates its own trash - according to your log in folder /media/photos/.dtrash . When you "delete" an image and go to the trash in digiKam, are the "deleted" images listed there? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 365331] digikam not loading because rpath information missing from libQt5Qml, libQt5Script and libQt5Quick
https://bugs.kde.org/show_bug.cgi?id=365331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to RJVB from comment #5) > Edit: it would *seem* that the issue has resolved itself in 5.3.0 . > > I agree something was wrong, but digiKam is the only application where I've > seen this happen with my build settings, and only for a few Qt libraries. > I don't know how the AppImage stuff is finagled together, but I'm not using > that. I'm just using unpatched CMake files and everything KF5 is built with > the settings required to apply full rpaths to all binaries. Qt5 itself is > built that way too. > > I'd agree the problem was fully on my end if I saw this happening to all Qt > libraries (in DK or in other applications too), but that isn't the case. > > The simplest explanation would be that somehow the rpath information is > dropped for the affected Qt libraries Is the problem resolved now? Can you test this with current master branch (version 5.5.0)? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 202030] Search duplicate images filtered by file type mime
https://bugs.kde.org/show_bug.cgi?id=202030 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Version Fixed In||5.5.0 Latest Commit||https://commits.kde.org/dig ||ikam/c900075b8d938d81c2cf8d ||9e6b2d2ce83439fde5 --- Comment #8 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit c900075b8d938d81c2cf8d9e6b2d2ce83439fde5 by Mario Frank. Committed on 28/02/2017 at 15:44. Pushed by mfrank into branch 'master'. Update the news. 1 bug is fixed by multiple changes in digikam in history. FIXED-IN: 5.5.0 M +2-1NEWS https://commits.kde.org/digikam/c900075b8d938d81c2cf8d9e6b2d2ce83439fde5 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 202030] Search duplicate images filtered by file type mime
https://bugs.kde.org/show_bug.cgi?id=202030 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- Currently (5.4.0), it is possible to filter by album and tags. In 5.5.0, it will be possible to restrict the result set even more. For example, if you have an image I in Album A, you can exclude all other images in Album A as potential duplicates of image I. So, if you have your raw images together with the jpeg pictures in one album, they are filtered out. By the way, 5.5.0 will also come with database cleanup. But this was not the problem for your start-up. Should this file stay open? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 261831] Auto-Process results from duplicates search
https://bugs.kde.org/show_bug.cgi?id=261831 --- Comment #4 from Mario Frank <mario.fr...@uni-potsdam.de> --- >From https://bugs.kde.org/show_bug.cgi?id=372378 : piotergmo...@hotmail.com 2016-11-12 09:24:38 UTC Digikam has powerfull search funtcion, which finds duplicates in albums. Nice feature to have would be to *do* something after the search with the images. The most obvious action could be: delete the duplicates, but the list could go on to different scenarios. This is the real example which occured after I have imported from the mobile camera 1000 photos which could be imported previously, a years ago. They have different file names of course, so from filesystem point of view they are different. I would like to clean my albums, but in automated way and wonder what is possible. P. Wolfgang Scheffner 2016-11-12 18:14:05 UTC Seems a bit difficult to me. How can an automated process decide which one of two identical images to process (delete or whatever)? Of course you could set the threshold to 100% and then say it doesn't matter, just process one of them. But 1. your search result gets very small with 100% and 2. the process would still need a rule to decide and that will most likely not match everybody's needs. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372378] Action after the search of the duplicated images
https://bugs.kde.org/show_bug.cgi?id=372378 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||mario.fr...@uni-potsdam.de --- Comment #2 from Mario Frank <mario.fr...@uni-potsdam.de> --- *** This bug has been marked as a duplicate of bug 261831 *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 261831] Auto-Process results from duplicates search
https://bugs.kde.org/show_bug.cgi?id=261831 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version|1.2.0 |5.4.0 CC||mario.fr...@uni-potsdam.de Summary|Delete Duplicate photos by |Auto-Process results from |image size |duplicates search --- Comment #2 from Mario Frank <mario.fr...@uni-potsdam.de> --- I use this bug as container for bugs with equivalent wishlist -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 261831] Auto-Process results from duplicates search
https://bugs.kde.org/show_bug.cgi?id=261831 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||piotergmo...@hotmail.com --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- *** Bug 372378 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 208713] Quicker deletion of multiple duplicate images
https://bugs.kde.org/show_bug.cgi?id=208713 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Version Fixed In||5.5.0 --- Comment #5 from Mario Frank <mario.fr...@uni-potsdam.de> --- Choosing multiple duplicates entries from the left sidebar is available since digiKam 5.4.0 (see https://bugs.kde.org/show_bug.cgi?id=366567 ). The reference images are not shown as in the mockup (as mostleft images). But this is not really easy to do. But in upcoming release 5.5.0, the reference images have the mark "Reference image" in their image info and are thus easily recognised. Selection by a selection box is also already available, as is grouping by albums (not vertically but horizontally). So, I close this file now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375421] Same name under "Albums" for different collections with same underlying name
https://bugs.kde.org/show_bug.cgi?id=375421 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In||5.5.0 Latest Commit||https://commits.kde.org/dig ||ikam/c000a498d1776a52422069 ||15773c41497786fafe Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- Fixed by https://bugs.kde.org/show_bug.cgi?id=376020#c4 . Next version (5.5.0) or next pre-release AppImage will contain this fix. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376020] Moving of photos within the fuzzy search corrupts database
https://bugs.kde.org/show_bug.cgi?id=376020 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit|https://commits.kde.org/dig |https://commits.kde.org/dig |ikam/f58fc11f651c84cae37a75 |ikam/c000a498d1776a52422069 |8a40ec18be1229b8b1 |15773c41497786fafe --- Comment #4 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit c000a498d1776a5242206915773c41497786fafe by Mario Frank. Committed on 28/02/2017 at 14:44. Pushed by mfrank into branch 'master'. If two root albums have the same name in file system, they are not distinguishable as for both albums the header states Albums/albumnane. But since all albums have a label, this one is better suited as albumname as the user specifies the album himself. FIXED-IN: 5.5.0 M +2-1NEWS M +6-1libs/album/album.cpp M +13 -12 libs/album/album.h M +13 -0libs/database/collection/collectionmanager.cpp M +6-0libs/database/collection/collectionmanager.h https://commits.kde.org/digikam/c000a498d1776a5242206915773c41497786fafe -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 372972] Find duplicates "search in drop down" only shows 1 item
https://bugs.kde.org/show_bug.cgi?id=372972 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Here is the link where the current AppImages and Windows versions of the 5.5.0 pre-release are distributed by Gilles: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Can you test the following: If your drop-down-menu shows only one entry, double-click it. It should expand into the album tree. I had the same problem and it worked. Cheers, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376020] Moving of photos within the fuzzy search corrupts database
https://bugs.kde.org/show_bug.cgi?id=376020 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/f58fc11f651c84cae37a75 ||8a40ec18be1229b8b1 Version Fixed In||5.5.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit f58fc11f651c84cae37a758a40ec18be1229b8b1 by Mario Frank. Committed on 28/02/2017 at 13:02. Pushed by mfrank into branch 'master'. Added an option in context menu to group an image with another one and move it to the album of the target image at the same time. Though the problem described in 376020 is no bug, I think this use-case can save users some work. FIXED-IN: 5.5.0 M +2-1NEWS M +26 -2app/dragdrop/imagedragdrop.cpp https://commits.kde.org/digikam/f58fc11f651c84cae37a758a40ec18be1229b8b1 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376359] Sort by Image Quality (assign quality tags) ignores many images
https://bugs.kde.org/show_bug.cgi?id=376359 --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Jens from comment #2) > great, thank you! Jens, I merged the branch into master. But we will have to wait for the AppImage. I remember Gilles writing somewhere that this will probably not be done before next week. So, you will have to wait for the AppImage or, if you can, compile the current master branch state on your system. Just to warn you, the exiv version used in most linux distros is 0.25 which has many bugs. 0.26 resolves over 200 bugs but is sadly not yet released. Some of the bugs in 0.25 lead to crashes. Thats one reason why we use AppImages. There we have a stable basis. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376661] When importing ~200,000 video files Digikam crashes in about 2-5 seconds of starting.
https://bugs.kde.org/show_bug.cgi?id=376661 --- Comment #15 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hi again, This will be a quite long text - sorry. But I want to make the problems as clear as possible. I thought about the fuzzy search for videos a bit more during my train travel. In fact, even the first non-plain frame is worthless. If a user really wants to use digiKam as catalog for videos (which is not the scope of digiKam in first place IMHO), he will potentially have videos that have the same beginning, i.e. intro but are different videos. Thus, also the first non-plain frame will potentially lead to rubbish. I remember that I found some tools to find video duplicates. The process they applied was to take the first n images of a video and compare it to all others. A quite bad process IMO as with m videos you generate n*m images and then have to make a comparison. This is awfully bad from the view of complexity theory. And in practice, this process is, as can be expected, awfully slow. Nevertheless, the process is the probably best way to really recognise duplicate videos. So, a way could be to generate a fingerprint over the first or last n images (slows down fingerprint generation extremely). This still is not robust as many videos may have the same intro (at least the first m seconds, e.g. about m*25 frames. Usual intros take many seconds. So a *rather* stable approach would be to take 1000 frames. As you can imagine, this is a big amount of data to compute fingerprints for. Just imagine your 200,000 videos. Fingerprinting them would mean to generate 200,000,000 images. Every image must be generated which is no const-time process but at least linear time. So, even with 1000 videos, i would expect computation time to be in measure of hours, not minutes. Let's take a look from the other side, outros are far more distinct than intros. So, a lower number n can be taken, e.g. 100. This reduces the time quite a lot. But is probably still not satisfying. If no or only short intros/outros are there, only few images should be sufficient and the process could work quite good. But we cannot estimate, how the videos are structured. The FPS count may/will differ from video to video. So, woking on frames explicitly may again lead to low-quality results. So, the best way would be to take the n first/last seconds and then the complexity cannot really be estimated here. Also, I think, users should decide themselves, how many seconds are taken (configuration) and if beginning or ending should be taken (configuration again). So, *if* this feature should be implemented, I see the following options for users: 1) Take the first non-plain frame for fingerprinting (fast, probable not suitable for e.g. cinema movies) 2) Take the n first seconds for fingerprinting (probably awfully slow, may be suitable for e.g. cinema movies, overkill for self-produced movies) 3) Take the n last seconds for fingerprinting (probably slow, probably suitable for e.g. cinema movies, less overkill for self-produced movies) In a more precise algorithmic way, we would need an adoption of the fingerprints maintenance stage: Option 1: take the first non-plain frame for video fingerprints Option 2: take the Option(number n) Option(first,last) seconds for video fingerprinting. Changing the current options *must* trigger delete the current fingerprints of videos as otherwise, different fingerprintings would coexist which leads to wrong results - except rebuild all fingerprints is chosen. Then, the fuzzy search could probably work without adoptions - but I am not completely sure if it would work out of the box. Best, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376661] When importing ~200,000 video files Digikam crashes in about 2-5 seconds of starting.
https://bugs.kde.org/show_bug.cgi?id=376661 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #14 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Poz from comment #13) > Are the thumbnails not readily available to do the fuzzy search on? I know > they are not the biggest but I think they are big enough, or if there is a > setting to render them a slightly higher resolution... That is how I > imagined it would work anyways, since the thumbnails would already be > generated, half the work is already done to fuzzy search videos... Hey Poz, Sadly, it is not this easy. The fuzzy search creates a signature from images. This does not hold for videos. Videos are quite more complex as the signature creation must be uniformly done for all videos. But if videos have black frames in the beginning, the search would lead to results which are, let's say, rubbish. The most stable way I see is to take the first frame from every video that is not plain, i.e. single-coloured. But this means we would have to generate images until we find the first appropriate frame. This would slow down the fingerprints generation significantly. A stable implementation is not trivial here. I will think about a way more closely over the weekend. Best, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376815] Restore from Trash works incorrectly
https://bugs.kde.org/show_bug.cgi?id=376815 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In|5.5 |5.5.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376815] Restore from Trash works incorrectly
https://bugs.kde.org/show_bug.cgi?id=376815 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In||5.5 CC||mario.fr...@uni-potsdam.de Latest Commit||https://commits.kde.org/dig ||ikam/f528f24b54894b271a4bee ||44a850b1ac46c10cc9 Resolution|--- |FIXED Status|REOPENED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 362023] Extremely slow metadata writing via maintenance
https://bugs.kde.org/show_bug.cgi?id=362023 --- Comment #18 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 283062, bug 216895, bug 374225, bug 351658, bug 329353 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 351658] Prevent to fill whole memory when all CPU cores are used to process Maintenance tools
https://bugs.kde.org/show_bug.cgi?id=351658 --- Comment #31 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 283062, bug 216895, bug 374225, bug 362023, bug 329353 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374225] Add possibility to remove face identities by removing tag and remove person tags but preserving the tags themselves [patch]
https://bugs.kde.org/show_bug.cgi?id=374225 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In||5.5.0 Resolution|--- |FIXED Latest Commit||https://commits.kde.org/dig ||ikam/2f8ddd42ef62d7aea9e490 ||cdb05ffcc644810c81 Status|UNCONFIRMED |RESOLVED --- Comment #24 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 283062, bug 216895, bug 351658, bug 362023, bug 329353 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 216895] SQLITE : improve performance and reduce space with some pragma's
https://bugs.kde.org/show_bug.cgi?id=216895 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In||5.5.0 Latest Commit||https://commits.kde.org/dig ||ikam/2f8ddd42ef62d7aea9e490 ||cdb05ffcc644810c81 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 283062, bug 374225, bug 351658, bug 362023, bug 329353 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 283062] THUMBDB : limit the size of thumbnail database
https://bugs.kde.org/show_bug.cgi?id=283062 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/2f8ddd42ef62d7aea9e490 ||cdb05ffcc644810c81 Status|UNCONFIRMED |RESOLVED Version Fixed In||5.5.0 Resolution|--- |FIXED --- Comment #9 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 216895, bug 374225, bug 351658, bug 362023, bug 329353 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 329353] Make slow processing better
https://bugs.kde.org/show_bug.cgi?id=329353 --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 by Mario Frank. Committed on 22/02/2017 at 15:05. Pushed by mfrank into branch 'master'. Merged the current state of the garbage collection branch which improves the database cleanup stage of the maintenance and improves the reactiveness of the maintenance overall. We ported the way items are processed to a queue based method that can use the CPUs more effectively and does not create thousands of threads. Related: bug 283062, bug 216895, bug 374225, bug 351658, bug 362023 FIXED-IN: 5.5.0 M +17 -12 NEWS https://commits.kde.org/digikam/2f8ddd42ef62d7aea9e490cdb05ffcc644810c81 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376359] Sort by Image Quality (assign quality tags) ignores many images
https://bugs.kde.org/show_bug.cgi?id=376359 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Jens from comment #0) > When I choose to let my images be tagged according to image quality using > Digikam's default settings, only very few images are actually tagged. > > I wonder if this is an expected behaviour? I would expect all images of all > albums that I chose in the respective maintenance dialog to be tagged (with > the colored flag, meaning "accepted", "pending" or "declined"). But most > (>50%) images are not tagged at all. > > Thanks! Hey Jens, I just tested myself. I have 3454 images in my database and ran the maintenance. In fact, all my images are tagged now. I am working on a branch currently. It is possible that it works for me as a side effect due to changes I introduced in the branch. I will signal you when I have merged the branch in our master. Then, you can test again after we have new AppImage bundles or compile it yourself. Cheers, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 353331] can’t limit fuzzy-search to albums
https://bugs.kde.org/show_bug.cgi?id=353331 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #10 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to sylvain.l.sauvage from comment #8) > (In reply to caulier.gilles from comment #7) > > Can we considerate this file fixed for last digiKam 5.0.0 ? > > You do whatever want but if you’re asking me if it now works then the answer > is a big no! > > Two local collections. > The combobox still presents them (and only them, not their sub-albums) as > two “albums.” > If I select one, only the root album is selected. And then the search is > only made in the root album. > If I use the context menu, I can add all the children of the selected > collections but I still can’t chose among my albums. > If the children are selected (“453 albums selected” shown), I can’t deselect > them easily: deselecting one collection only deselects the root album of > that collection (“452 albums selected” instead of the expected “255…”). > > IOW, that UI is still a mess, nothing changed. > If the only way to search in a selected set of albums is to go through the > maintenance tool, then simply suppress that useless combobox. > > To be frank, I’m disappointed with 5.0.0. > The entire UI has not improved. > Half the menus are not translated. > Dialogs are always too small, half the elements are hidden (I don’t have > that problem with my other Qt/KDE apps). > Hiding the menu bar (Ctrl+M or via the menu) doesn’t work: it’s the status > bar that disappear! > > I had just compiled digikam 5 to test that bug, I’ll stay with Sid’s 4.14 > for now. Sylvain, I had the same problem as you had. But I only had one collection. I first thought it was a bug in my database. But my database was new. After some time of useless debugging, I found out, that I first have to double-click on the collection. After doing that, all sub albums of this collection were shown. So far, so good. I added another collection. In fuzzy search, the first collection (and its sub-albums were shown). Additionally, I now had the second collection (but no sub-albums for it). After double-klicking on it, the sub-albums showed up. Can you please test this with the current state of digiKam (Gilles wrote the location)? I tested this with the current state from git. Perhaps the missing functionality was just not shown prominently. Cheers, Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 317210] THUMBDB : delete image removes file, but does not remove thumbnails
https://bugs.kde.org/show_bug.cgi?id=317210 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Version Fixed In||5.5.0 Latest Commit||https://commits.kde.org/dig ||ikam/834221c8d1300bbdd4ae78 ||e345cdc0fce3e92be8 --- Comment #39 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 834221c8d1300bbdd4ae78e345cdc0fce3e92be8 by Mario Frank. Committed on 09/02/2017 at 20:51. Pushed by mfrank into branch 'master'. Updated the news. The newly introduced garbage collection gets rid of thumbnails in DB that are not referenced by any image any more. FIXED-IN: 5.5.0 M +2-1NEWS https://commits.kde.org/digikam/834221c8d1300bbdd4ae78e345cdc0fce3e92be8 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/a1f67531b3269941df5ff5 ||31baa3e487cf58f1fc Resolution|--- |FIXED Version Fixed In||5.5.0 Status|UNCONFIRMED |RESOLVED --- Comment #17 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit a1f67531b3269941df5ff531baa3e487cf58f1fc by Mario Frank. Committed on 08/02/2017 at 14:09. Pushed by mfrank into branch 'master'. Merged the garbage collection into master. The garbage collector is a maintenance stage that runs before the rebuild of thumbnails and must be triggered explicitely. It removes stale image entries in core db and if enabled also stale thumbnails and face identities from thumbnails and recognition DB. If configured so, the core DB part of the garbage collector removes stale image entries in core db during the start of digiKam. Note that cleaning the databases does not necessarily make them smaller as no auto-vacuum is done on the databases. The vacuuming proces differs highly between the three supported database variants (SQLite, internal MySQL and external MySQL). Thus, currently there is no automatism. Related: bug 323718 FIXED-IN: 5.5.0 M +3-1NEWS https://commits.kde.org/digikam/a1f67531b3269941df5ff531baa3e487cf58f1fc -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 323718] THUMBDB : rebuild all thumbnails does not get rid of all thumbnails first
https://bugs.kde.org/show_bug.cgi?id=323718 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version Fixed In||5.5.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/dig ||ikam/a1f67531b3269941df5ff5 ||31baa3e487cf58f1fc --- Comment #16 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit a1f67531b3269941df5ff531baa3e487cf58f1fc by Mario Frank. Committed on 08/02/2017 at 14:09. Pushed by mfrank into branch 'master'. Merged the garbage collection into master. The garbage collector is a maintenance stage that runs before the rebuild of thumbnails and must be triggered explicitely. It removes stale image entries in core db and if enabled also stale thumbnails and face identities from thumbnails and recognition DB. If configured so, the core DB part of the garbage collector removes stale image entries in core db during the start of digiKam. Note that cleaning the databases does not necessarily make them smaller as no auto-vacuum is done on the databases. The vacuuming proces differs highly between the three supported database variants (SQLite, internal MySQL and external MySQL). Thus, currently there is no automatism. Related: bug 374591 FIXED-IN: 5.5.0 M +3-1NEWS https://commits.kde.org/digikam/a1f67531b3269941df5ff531baa3e487cf58f1fc -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #16 from Mario Frank <mario.fr...@uni-potsdam.de> --- Merge is done. I will close this file now -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #15 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to caulier.gilles from comment #14) > Hi Mario, > > Well, merge back will be done when you decide. If more time is necessary to > hack, we can postbone release date for 5.5.0. > > In other word, we don't have any restriction here (:=)))... > > Gilles Hey Gilles, the stale data (in ImageTags) seems to be the result of some queries I made in the DB with my DB browser. I did not find more stale data in core DB that can be cleaned. I just resolved the last thing I disliked. Before 5.5, items were marked as Removed (now Trashed) and deleted after a retention period. So users may have items with that status. But the garbage collection only removes Obsolete items. I adopted the CollectionsScanner to marke trashed items as obsolete after a retention period. This way, users will also get rid of old trashed items. Also, there are no more tables in thumbs and recognition db that are not handled by the garbage collection. To conclude: in functionality, we are finished for now. I am in fact working with the garbage collection since we have the branch and did not encounter problems. I would merge the branch into the master today. Then, more people can test. No need to postpone 5.5 - except users raid us with bug requests. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #13 from Mario Frank <mario.fr...@uni-potsdam.de> --- What about the garbage collection branch. When will we merge it to master? I identified some potential stale data, i.e. table entries that reference a non-existent image id, in core DB that can also be collected. I will implement that when I have the time. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #15 from Mario Frank <mario.fr...@uni-potsdam.de> --- Okay, I thought about the problems for some time. I try to resume the expected behaviour: 1) Moving a group of items should preserve the grouping relation on the moved items (Bug description by Jens) - This works in garbage collection branch without workaround. 2) Moving an item that is grouped should preserve its grouping relation - This also works in garbage collection branch without the workaround. 3) Copying a group within digiKam should also copy the grouping relation for the newly generated items - This is not done. 4) Copying an item of a group within digiKam - This is not clear. Should the new item belong to the group? 5) Importing images into digiKam that are identical to grouped items - Should the imported images be grouped automatically? 6) What do you mean with > Also externally copied grouped images with the file manager makes problems. I assume that you mean that some user copies grouped images that are imported in digiKam with a file manager. But this then also makes problems when grouped images are moved with a file manager. I give here my opinion to 3-6 and I am open for discussion. I will try to make my arguments as precise and founded as possible. I would state the following for 3 and 4: Copy means copy and we should give the user what can be expected by the terms we use. Since we copy all image properties, the grouping relation should be copied in principle, too. But the problem here is: What does the user expect? Should the copies have a grouping relation with the source group leader or should the copied group be a new group with the copy of the old group leader being the new group leader? I cannot answer this question. Only the users can. So the default would be for me to not set group relations for copied items and (potentially) give the user an option to decide about the relations to established. I would state the following for 5: If a user imports some images into digiKam, we cannot know whether he wants to establish a group or add the images to a group. Also, the grouping relation is existent in digiKam but not in file managers - at least not that I know. Thus, the imported images should not be grouped automatically. We could ask the user or give an option as import. But I would not take the decision from the user. I would state the following for 6: I like good user experience. But this case is a clear misuse for me. One cannot expect some complex software to work properly when tampering with the resources managed by the software. If you just copy an image tag relation in our database, you will also have unexpected behaviour if our constraints do prohibit that. And this also holds for other software projects. If you copy some bundles from a OSGI container, he will probably yell at you to stop tampering with his internal resources. Probably with a crash. But we cannot prohibit changes in the file system level. We cannot even detect them if digiKam is not started. This is - at least for me - something that should be stated in the documentation. To conclude: cases 3 to 5 are no bugs for me. I think they are usability issues and we could try to give the user the control about what is done with the group 1) establish a new group with copy of group leader being new group leader 2) link to existent group leader 3) do nothing (default) case 6 is misuse and should be documented. Opinions? All the best Mario -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #11 from Mario Frank <mario.fr...@uni-potsdam.de> --- I have to correct myself. Moving the group back suddenly destroyed the group relation... That's odd. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 --- Comment #10 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Maik Qualmann from comment #8) > I have for a test the workaround code removed. > > https://cgit.kde.org/digikam.git/tree/libs/database/item/imagescanner. > cpp#n393 > > But the problem with the wrongly linked grouped image IDs is also not fixed > with the garbagecollection branch. > > Maik Maik, I just compiled the current state of the garbage collection branch and did the following: 1) Define 3 images as grouped 2) move the group to a different directory Result: The images are now located in the target directory and are still grouped. My garbage avoidance for moved items works like follows: If items are moved, I set the album to the target album. Thus, the ImageScanner should not detect the moved image files as new and thus also should not detect the images as identical. Moreover, the images entries stay intact and the image relation grouped should not be touched. I can not reproduce the problem in the current state of the garbage collection branch. Can you both test against this branch? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376020] Moving of photos within the fuzzy search corrupts database
https://bugs.kde.org/show_bug.cgi?id=376020 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #2 from Mario Frank <mario.fr...@uni-potsdam.de> --- Paul, I second Maik. If you would move the image into the other folder, the image would really be moved and vanish from source folder. Grouping is just an image relation that is established. This seems to me as a feature request in the way: Add option to group an image to another image and move it to the same folder. Is this what you expect? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375573] Don't reset/destroy context after deleting one image among a set of duplicates
https://bugs.kde.org/show_bug.cgi?id=375573 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/7ceca1f172828e48b47c50 ||88b61b2452b7820e52 Version Fixed In||5.5.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 7ceca1f172828e48b47c5088b61b2452b7820e52 by Mario Frank. Committed on 04/02/2017 at 15:47. Pushed by mfrank into branch 'master'. We do not rescan for duplicates if an image is deleted any more. Instead, all duplicates albums in left pane are updated, i.e. the items count, and average similarity are recalculated. If only one duplicate is left, the duplicates album is hidden. This solves the problem of losing context due to the rebuild of the SAlbums. I see no other good technical possibility of preserving the context since the SAlbums are deleted automatically. Also, the similarities to images are not deleted any more. Otherwise the calculation of the average similarity would be wrong. We will take care of the similarity values in garbage collection branch. FIXED-IN: 5.5.0 M +2-1NEWS M +9-20 libs/album/albummanager.cpp M +1-1libs/album/albummanager.h M +17 -0libs/database/item/imageinfo.cpp M +5-0libs/database/item/imageinfo.h M +18 -0utilities/fuzzysearch/findduplicatesalbum.cpp M +4-0utilities/fuzzysearch/findduplicatesalbum.h M +65 -16 utilities/fuzzysearch/findduplicatesalbumitem.cpp M +10 -0utilities/fuzzysearch/findduplicatesalbumitem.h M +4-13 utilities/fuzzysearch/findduplicatesview.cpp M +1-1utilities/fuzzysearch/findduplicatesview.h https://commits.kde.org/digikam/7ceca1f172828e48b47c5088b61b2452b7820e52 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #12 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Kusi from comment #9) > do you have by any chance a branch on a git repo to check out from? I use an > external mysql server and could test it with that configuration > > When you delete a tagged photo and restart digikam, the tags are gone > forever, right? It wouldn't be possible to restore the photo including tags > from the trash. What about a retention period (e.g 30 days), or if the > deletion date is not saved, just clean up once every month instead of every > launch of digikam(just as an idea) Kusi, I never would automatically delete items from trash. I think this is bad usability. I only delete the items that were either removed directly (not moved to trash) or removed from trash. So, as long as you do not delete the items from trash, I will not do this either. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375945] Face detection not scanning my images
https://bugs.kde.org/show_bug.cgi?id=375945 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- (In reply to Struan Lownie from comment #2) > Created attachment 103793 [details] > Debug as requested. > > Debug log starts when DigiKam had finished loading, and saved once the > Facedetection reported itself to be finished (5 seconds after start) > > I was running Facedetection against a folder containing 8.48GB of NEF files, > 609 images Acording to your log, it seems that you chose detect and recognise as option. I'm concluding this from: "... 001013.10399723 [9788] digikam.facesengine: Face database ready for use 001113.12266350 [9788] digikam.general: Face PipeLine: add preview thread >0012 13.12278080 [9788] digikam.general: Face PipeLine: add >single thread detector >0013 13.12292194 [9788] digikam.general: Face PipeLine: add >recognition worker 001413.12304497 [9788] digikam.general: Face PipeLine: add database writer ..." This problem was already solved in this bug: https://bugs.kde.org/show_bug.cgi?id=375375 So, this is a known bug in 5.4 which is fixed for the upcoming release 5.5, I woud say. Seems to me like a duplicate, Gilles. Struan, can you test with the current 5.5 pre-release for Windows which is located here: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Should be fixed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375700] Digikam freezes for a long time (I/O wait) if similarity range is set too low
https://bugs.kde.org/show_bug.cgi?id=375700 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Latest Commit||https://commits.kde.org/dig ||ikam/574a76623105b08dc4f1f6 ||2ccb8cc6bd822bae0d Version Fixed In||5.5.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mario Frank <mario.fr...@uni-potsdam.de> --- Git commit 574a76623105b08dc4f1f62ccb8cc6bd822bae0d by Mario Frank. Committed on 03/02/2017 at 13:44. Pushed by mfrank into branch 'master'. Introduced a configurable lower bound for the minimum similarity in fuzzy and duplicates search. This reduces the probability of unresponsiveness due too many images being scanned for similarity. The bound can be configured in setup->misc and takes effect immediately in fuzzy search view and duplicates view. Thus, no restart of digiKam is necessary. FIXED-IN: 5.5.0 M +3-1NEWS M +2-0libs/settings/applicationsettings.cpp M +3-0libs/settings/applicationsettings.h M +10 -0libs/settings/applicationsettings_miscs.cpp M +3-0libs/settings/applicationsettings_p.cpp M +2-0libs/settings/applicationsettings_p.h M +21 -1utilities/fuzzysearch/findduplicatesview.cpp M +1-0utilities/fuzzysearch/findduplicatesview.h M +22 -2utilities/fuzzysearch/fuzzysearchview.cpp M +2-0utilities/fuzzysearch/fuzzysearchview.h M +11 -1utilities/maintenance/maintenancedlg.cpp M +24 -1utilities/setup/setupmisc.cpp https://commits.kde.org/digikam/574a76623105b08dc4f1f62ccb8cc6bd822bae0d -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375700] Digikam freezes for a long time (I/O wait) if similarity range is set too low
https://bugs.kde.org/show_bug.cgi?id=375700 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hi Jens, This is a known problem. If the similarity range is too big or the minimum similarity too low, the process takes much time. And the application becomes unresponsive since the image signatures are located in the core DB currently. Thus, everything that wants to access the core DB is slowed down extremely. We will have to migrate everything concerning fuzzy search and duplicates search into a dedicated database. This would give us the opportunity to make searches in background easier. The search result you see is just a virtual album which is loaded every time you visit it. Thus, we cannot do it in background currently. Limiting the search by time is formally no good approach, I think. If we limit the time, we can only scan a limited amount of images. The result would be that images that would be scanned later and have a higher similarity would not be shown. Just because of timing constraints. I would now re-introduce a lower similarity bound for fuzzy and similarity searches. This bound was 40 %. And frankly said, I would not use fuzzy search with similarities lower than 40 % myself. The probability that images have such a low similarity is quite high. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB [patch]
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #8 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 103773 --> https://bugs.kde.org/attachment.cgi?id=103773=edit Patch including new files. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 317210] THUMBDB : delete image removes file, but does not remove thumbnails
https://bugs.kde.org/show_bug.cgi?id=317210 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #37 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hi, I just uploaded a patch in https://bugs.kde.org/show_bug.cgi?id=374591 that introduces garbage collection as maintenance stage. This cleans the core, thumbs and recognition db from stale entries. But be advised: The patch is still in testing phase. I did some tests on my own databases and had no problems. But just to be sure, backup your databases before you test. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375703] Moving grouped images into another album removes groups
https://bugs.kde.org/show_bug.cgi?id=375703 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hi Jens, I just uploaded a patch in https://bugs.kde.org/show_bug.cgi?id=374591 that, apart from garbage collection also leads to generating less junk. Meaning, if files are moved/renamed, the old images table entries are reused. This way, the image id of the image is preserved. This could solve your problem. This patch does not work for images that were already moved before applying the patch. You can test it if you compile from source and apply the patch. But be advised: The patch is in testing phase. If you do not run the garbage collector in maintenance, nothing bad should happen to your databases. But just to be sure, backup your databases before you test. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 323718] THUMBDB : rebuild all thumbnails does not get rid of all thumbnails first
https://bugs.kde.org/show_bug.cgi?id=323718 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #14 from Mario Frank <mario.fr...@uni-potsdam.de> --- There is a patch that introduces garbage collection as maintenance stage before thumbnail rebuild here: https://bugs.kde.org/show_bug.cgi?id=374591 . This could solve your problem. But be advised: The patch is still in testing phase. So, backup your databases before you test. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #7 from Mario Frank <mario.fr...@uni-potsdam.de> --- To all who test this patch: Please backup your databases before you test. Though I made tests without any problems, your databases differ from mine. And I do not want you to lose data. The core database is only slightly touched, i.e. really removed image entries are deleted. The most work is done in thumbnails db. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB
https://bugs.kde.org/show_bug.cgi?id=374591 --- Comment #6 from Mario Frank <mario.fr...@uni-potsdam.de> --- Created attachment 103766 --> https://bugs.kde.org/attachment.cgi?id=103766=edit This patch introduces garbage collection as maintenance stage and reduces the amount of generated garbage. This patch introduces garbage collection as maintenance stage and reduces the amount of generated garbage. The stage in which the garbage collector is run is before the rebuilding of thumbnails. Description of problems and approach. The garbage that bloated my databases was quite annoying. I want to draw a sketch about where the garbage comes from: 1) Move image to trash. Everytime I delete some image, the Images table entry is set to status Removed (3) and the original album id is removed from the entry. If I restore the image from trash, a new Images entry is generated. 2) Deleting images/albums directly or from trash. The image files are deleted from hard drive but the Images entries are not removed (and also ImageTagProperties and so on. 3) Moving/renaming images creates a new Images entry. The old one is set to status Removed. 4) Deleting images does not remove the thumbnails. (by path/ uniqueHash) 5) Deleting face regions does not remove the region thumbnails (custom identifier) 6) Removing tag does not remove identities from recognition db (every identity should have the same faceEngineUUID as a tag) Here is a description about what the patch does: 1) Creating less junk: I introduced a new item status "Obsolete" and renamed the status "Removed" to "Trashed". Items are set to status Trashed if they are moved to trash. If items are deleted directly/permanently, they get the status "Obsolete". If an image is restored from trash, i search for an item entry that has status Trashed and has the same properties as the new one. If i find such one, I use this entry and set the new/old album and the status to visible. If an image is renamed/moved, I use the moveItem method of the core DB to set the new album/name of the image. This way, the ImageScanner does not think that this is a new image. The old entry is reused. This could solve the grouping problem. I cannot solve points 4 to 6 in the same easy way, explicitely not the thumbnails problem since thumbnails can be referenced by image path, image uniqueHash/file size and image path/face region (custom identifier) Thus, I made some clean-up routine for our databases. 2) Collecting junk: I implemented the DbCleaner Maintenance module. It runs at every start of digikam (if configured so in setup->misc) and removes all stale Images entries (detectable by status Obsolete). This does not take much time. But the DbCleaner can do more. In Maintenance dialog, I added a stage Database Cleanup, which can be triggered. The stage can also clean the thumbs db and recognition db. But this must be explicitely selected in the menu as this can take more time. Also, the thumbs and recognition db are never cleaned at the start of digikam. I do not want our users to wait minutes until they can work. Now to what the DbCleaner does. As already said, it removes the stale images. But let's take a step back. Getting the stale images is just one call to core db. Getting the stale thumbnails is more complicated. Getting the stale face identities is less complicated. In first phase of the DbCleaner I analyse the databases (thumbs and recognition only if enabled). Identities are stale if there is no tag in core db that has the same faceEngineUUID as the identity. Thumbnails are stale if the following holds: 1) There is no image in core DB whose file path leads to that thumbnail (FilePaths table) 2) There is no image in core DB whose uniqueHash and file size leads to that thumbnail (UniqueHashes table) 3) There is no face region of an image whose custom identifier (image file path + region) leads to that thumbnail (CustomIdentifiers table) So I first get all thumbnail ids from thumbs db into a list A and all image ids into another list B. Then I get the thumbnail ids for every image by their file path, uniqueHash/file size and also the thumbnails for the face regions and remove those thumbnail ids from my list A. The remainder in the list is thus neither connected to an image/video nor to face regions. I know that this is no really efficient way. But if, let's say a face region is deleted, I cannot delete the thumbnail since it could still be used from some other image by file path for example. When I am done with that, I first clean the core db (stale images) After that, I clean the thumbs db and after that the recognition db. So far for the main process. The progress is shown to the user and I show, what currently is done (analyse, clean core DB, clean thumbs DB, clean recognition DB). Then I tested my implementation with my database. I have got about 4 images and my thumbnail db contains 96000 File
[digikam] [Bug 374591] Deleting image only removes the file and sets the status to hidden but does not delete the image from DB
https://bugs.kde.org/show_bug.cgi?id=374591 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added Version|5.4.0 |5.5.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 375573] Don't reset/destroy context after deleting one image among a set of duplicates
https://bugs.kde.org/show_bug.cgi?id=375573 --- Comment #3 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hey Dan, I will answer inline since there are some things that came me in mind. (In reply to Dan Dascalescu from comment #2) > Hey Mario, > > Thank you for the explanation. I understand the tradeoff - accuracy in > reporting the number of dupes, vs. speedy processing. The solution I propose > revolved around lazy calculation - does the user care more about a precise > number shown next to the album *when they get to see it*, or to be able to > move on to examine the other duplicates in the cluster? I would expect the latter to be more important than the accuracy. Thus, delaying is an option for me. > > I mentioned "when they get to see it" because after the user deletes one of > the duplicates, the list of duplicate clusters in the left pane always > scrolls to the top (IMO this could be improved to try to keep the scroll > position, but digiKam probably just re-sorts the list), so if they were > working on a duplicate cluster below the fold (i.e. if they have scrolled > down at all), the number of duplicates in that album won't be visible > anyway. In fact, when you deal with many clusters of duplicates, only those > items at the top, according to the sort order (Ref. images filename, # of > items, or Avg. similarity) will be visible. Okay, let's switch to your terminus. With duplicates albums, we refer to what you call duplicates clusters (internally called search albums), i.e. the entries in the left table - one duplicates album is one entry here. Scrolling to the top is really annoying. This could be resolved. But I will come to that later. > > Not sure what you meant by "one duplicates album" (needs to be adjusted) - > did you mean a cluster (in DUFF terminology, http://duff.dreda.org/) of > duplicates (which may be spread across different albums), or an album that > contains duplicates, so the count of items in the album needs to be > adjusted? In the latter case, that count is even farther from the user's > attention, because the user is in the Fuzzy tab, vs. in the Albums tab. > Could the recalculation of counts be done only once, when the user leaves > the Fuzzy tab? > > Also, there are two different scenarios I see when it comes to deleting > duplicates: > > 1) Deleting images in duplicate clusters one by one, while the user looks at > the picture in Preview Mode, to examine it in as large of a size as > possible. In this case, only one image is deleted at a time. Would counts be > easier to decrement in this case? Yes, this was my first approach when I tried to fix the referenced bug. But the fact that the image should also vanish from other duplicates clusters would have forced me to decrement there, too. But the count of images is defined in the internal search albums in the way that the count is the count of image ids. And the cluster list does not know how many of the images are existent. Nevertheless, it is technically possible to get the cluster list to know which images still exist and which do not. But then again, the average similarity is not correct anymore as it is calculated on the complete set of images. This could be also solved by the fact that I introduced the similarities between images in database shortly before release of 5.4. > > 2) Staying in Thumbnails or Table, selecting multiple images, and deleting > them at once. > > Finally, question about "the deleted image may be member of other duplicates > albums" (this relates to the cluster vs. album distinction) - is the > duplicate relationship transitive? I mean, if images A and B are dupes > within the similarity range, and B is part of another cluster of duplicates, > A should be part of that cluster too, which means only two counts need to be > updates: the number of dupes in that cluster, and the number of items in the > album the image belongs to. Theoretically, you are right. If image A is a duplicate of reference images B and C, the images B and C have *some* similarity, too. But as in audio streams - if stream a is part of stream b and c, the latter streams have *some* similarity in *some* position. Perhaps the similar parts are only 2 %. Depending on the given similarity range, this similarity is ignored. We cannot use transitive closures here. So, to roll up. If we have duplicates cluster A and we delete some image that is also part of duplicates cluster B, we need to update both clusters - in some way: rescanning/decrementing counts. If we delete the reference image of cluster A itself, the cluster would currently vanish. As consequence, the internal search album is removed and you lose context. This is a problem which was not addressed in the referenced bug. And this is a real disturbance in the workflow. I
[digikam] [Bug 375573] Don't reset/destroy context after deleting one image among a set of duplicates
https://bugs.kde.org/show_bug.cgi?id=375573 Mario Frank <mario.fr...@uni-potsdam.de> changed: What|Removed |Added CC||mario.fr...@uni-potsdam.de --- Comment #1 from Mario Frank <mario.fr...@uni-potsdam.de> --- Hey Dan, there was a bug before 5.4 with a quite long discussion ( https://bugs.kde.org/show_bug.cgi?id=261417 ). To make it short: When some image from a duplicates album is deleted, the count of duplicates for this album has to be adjusted. Otherwise, we provide wrong information. Also, the deleted image may be member of other duplicates albums. Thus, they have to be adjusted, too. Some of the albums may even vanish if this was the only duplicate to the reference image. Following this, I took the most performant approach: all duplicates albums that contained the image are rescanned for duplicates and followingly refreshed. This may take some time depending on images involved. During this time, the image view loses the connection to the duplicates album since it is not present during rescan but only afterwards. So, what you experience is the lost connection. I agree that the workflow is interrupted in this case. If only one duplicates album needs to be adjusted, trying to just decrement the image count would be feasible. But as soon as another duplicates album becomes dirty by the deletion, a rescan should be definitely done, I think. Delaying the rescan would technically be possible. the problem here is that we cannot estimate the usual time a user should have until a rescan is done. If a duplicates album has 100 items and you delete one image per second, the delay is okay. But 10 seconds delay, for example may again interrupt the workflow of users. Any comments/opinions to this? -- You are receiving this mail because: You are watching all bug changes.
