https://bugs.kde.org/show_bug.cgi?id=320666
Bug ID: 320666 Summary: Fuzzy search for any image Classification: Unclassified Product: digikam Version: 3.1.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Fuzzy Searches Assignee: [hidden email] Reporter: [hidden email] Currently I can only dragdrop images from my collections, ie. from inside Digikam. It would be very convenient to be able to search for images from external folders (via Dolphin) or even online from a browser. A common use case for me is: Do I have this image in my collection? Dropping it in Digikam to get the answer would be great! Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
https://bugs.kde.org/show_bug.cgi?id=320666
[hidden email] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #1 from [hidden email] --- This would indeed improve fuzzy searches (by image) a lot! Consider also the following user scenario: I want to search in my collection for a specific kind of images (for example bridges, sunsets, etc), but I have no clue where to look for. I could make a simple web search for the subject, temporarily download a similar image to the one I'm looking for, and drag and drop it into digikam fuzzy search. This way I have all the bridges in my collection in no time :) Anyway, thanks for the hard work! -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
Gilles Caulier <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fuzzy search for any image |Add search of similar | |images outside digiKam | |collections CC| |[hidden email] -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
Mario Frank <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #2 from Mario Frank <[hidden email]> --- (In reply to parejaobregon from comment #1) > This would indeed improve fuzzy searches (by image) a lot! > > Consider also the following user scenario: I want to search in my collection > for a specific kind of images (for example bridges, sunsets, etc), but I > have no clue where to look for. I could make a simple web search for the > subject, temporarily download a similar image to the one I'm looking for, > and drag and drop it into digikam fuzzy search. This way I have all the > bridges in my collection in no time :) > > Anyway, thanks for the hard work! Hey, I think this is a quite nice feature though there is a workaround: 1) create a "staging"-album for those pictures 2) drag the pictures into the album 3) Trigger fuzzy search via context menu. But as noted out, the shorter was may be more nice. Thus, I made some research and some tests concerning this feature request. I have a working solution but I am not satisfied. In DK, the fuzzy and duplicates searches are based on the images as defined by the database structure. It is possible to implement such feature without using the internal data structure. But I assume this is no clean solution. I think the most clean way would be to create a temporary image data structure from the provided URI. I just did not find something appropriate in the API. Perhaps, this does not even exist. But even if I create temporary image data structures, they should not have the normal image ids since I do not want to waste ids. Some comments from the established devs concerning the technical details? Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #3 from [hidden email] --- The possible way to query the database externaly was dropped definitively with 5.0 release : KIO support. All digiKam KIO slaves have been replaced by a multi-threaded/core interface. KIO is bably portable and make digiKam very difficult to stabilize. There is no plan to restore KIO. Another approach can be to export database content with a standardized protocol as Upnp. An old KIPI tool exist by the core library which implement Upnp was never port to Qt5. My tip : delay all searches about this topic for the moment, until we found a portable, stable, standardized solution. Gilles Caulier -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #4 from Mario Frank <[hidden email]> --- (In reply to caulier.gilles from comment #3) > The possible way to query the database externaly was dropped definitively > with 5.0 release : KIO support. > > All digiKam KIO slaves have been replaced by a multi-threaded/core > interface. KIO is bably portable and make digiKam very difficult to > stabilize. > > There is no plan to restore KIO. > > Another approach can be to export database content with a standardized > protocol as Upnp. An old KIPI tool exist by the core library which implement > Upnp was never port to Qt5. > > My tip : delay all searches about this topic for the moment, until we found > a portable, stable, standardized solution. > > Gilles Caulier Hey, I do have a working solution. To make a short description. I allow dragging objects over the image label iff the mime type of the event data is a URL list. In this case, it is no DIMG. If the first URL (there is only one in the list) is a local file and can be loaded as QImage, dropping is allowed. There is a function in HaarIface for loading paths as QImages if thy are images. I could reuse it. The only thing I had to do was to introduce a temporary ImageInfo with id -1 and save the image url in the fuzzy search view. This way, refreshing images due to modification of thresholds does work, too. This should all be independent from KIO, is it? For details, look at https://bugs.kde.org/show_bug.cgi?id=302923 . I was working on both bugs at the same time and the sorting of fuzzy drop search results depends on bug id 302923. Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #5 from [hidden email] --- yes, i agree. This kind of solution can work and will be independent of KIO mechanism. In fact, D&D is a way to query an application from outside. KIO is another way which permit to implement more complex solution. D&D is more universal and is standardized for each OS. Look at end of this page for details : http://doc.qt.io/qt-5/dnd.html -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #6 from Mario Frank <[hidden email]> --- (In reply to caulier.gilles from comment #5) > yes, i agree. This kind of solution can work and will be independent of KIO > mechanism. > > In fact, D&D is a way to query an application from outside. KIO is another > way which permit to implement more complex solution. > > D&D is more universal and is standardized for each OS. Look at end of this > page for details : > > http://doc.qt.io/qt-5/dnd.html Okay, I finished the Drag&Drop-solution two weaks ago or so. The patch is the same as for https://bugs.kde.org/show_bug.cgi?id=302923 . In order to have the patch located correctly here, I will upload it here, too. Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #7 from Mario Frank <[hidden email]> --- Created attachment 102905 --> https://bugs.kde.org/attachment.cgi?id=102905&action=edit Patch for sorting by similarity and dropping images not yet included in the DK database. -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
[hidden email] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add search of similar |Add search of similar |images outside digiKam |images outside digiKam |collections |collections [patch] -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #8 from [hidden email] --- Mario, I postponed digiKam 5.4.0 to 1 January. This will let's time to you to patch git/master and test to stabilize implementation for production while holidays. Please don't waste time. Gilles -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #9 from Mario Frank <[hidden email]> --- (In reply to caulier.gilles from comment #8) > Mario, > > I postponed digiKam 5.4.0 to 1 January. This will let's time to you to patch > git/master and test to stabilize implementation for production while > holidays. > > Please don't waste time. > > Gilles Hey, postponing the deadline was not what I aimed at but since I am in Holidays now, there will be enough time to test. I will patch the master branch after doing some standard tests with valgrind and some more functionality tests. The similarity sort patch introduces some i18n-related topics. How are the maintainers informed about necessary changes for localisation and/or documentation? Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #10 from [hidden email] --- I discovered a serious problem to Slideshow and Presentation with some video file to handle. So postponed is the best way. The doc is not a problem. For i18n, if patch over GUI is applied quickly and not touched later, it's acceptable. Patching code not relevant of i18n is not a problem of course. Gilles -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
Mario Frank <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- Latest Commit| |https://commits.kde.org/dig | |ikam/e12dd0980f4371f1a7511a | |817fc7e17d7dccd2e6 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Version Fixed In| |5.4.0 --- Comment #11 from Mario Frank <[hidden email]> --- Git commit e12dd0980f4371f1a7511a817fc7e17d7dccd2e6 by Mario Frank. Committed on 23/12/2016 at 20:45. Pushed by mfrank into branch 'master'. This patch aims to improve the usability of fuzzy/duplicates/sketch search. A sorting option (by similarity) is introduced which can be helpful in fuzzy/sketch search where similar images are searched for a given one. Sorting the resulting images by similarity to the given image is an obviously helpful feature. It is now possible to drop local files that are images and not present in the Digikam database into the fuzzy search image label and trigger a fuzzy search for this image. Details: Sort by similarity: For sorting by similarity, a new option Sort by similarity with default order descending was introduced. This option is only active if the fuzzy search sidebar is active, i.e. fuzzy/duplicates/sketch search. To compare two pictures, it is necessary to get their similarity to the original picture. Since this information was only printed to console but not saved in the image info, SAlbum query or the properties, I do that myself. For every similar picture, a property similarityTo_X with X being the id of the original image and the similarity are stored as image property. When the image with id X is deleted, the property is removed to keep the DB small. Also, the property is removed from images if the fuzzy/duplicates search is done for image X such that old similarity values are removed. Though the similarity of image X to image Y is symmetric, I do not want to store both. This would bloat the DB. Only the detected similarities are explicitly stored. Drag and drop images not yet present in DB for fuzzy searches: I allow dragging objects over the image label iff the mime type of the event data is a URL list. In this case, it is no DIMG. If the first URL (there is only one in the list) is a local file and can be loaded as QImage, dropping is allowed. The function loadImage in HaarIface is used since it was already present and has optimisations for specific image formats. In order to not import the image but to be able to find similar pictures, and sort by the similarity, a temporary image id is needed. I use -1 for this case since this image id cannot be present in DB. Also, everytime a new external image is dropped for fuzzy search, the similarities for the previous dropped image are removed from database to keep the entries up to date. Moreover, I save the image url of the dropped image in the fuzzy search view. This way, refreshing the similar images due to modification of thresholds does work, too. Made small tests with valgrind - did not find memory leaks, yet. Made functionality tests for fuzzy drop. Trying to drag local files that are no images (e.g. pdf, odt, plain text) is not successful as wished. Made functionality tests for similarity search. Did not find defects. More tests will be applied in the next days. Related: bug 302923 FIXED-IN: 5.4.0 M +3 -1 NEWS M +7 -0 app/main/digikamapp.cpp M +46 -0 app/utils/searchmodificationhelper.cpp M +29 -0 app/utils/searchmodificationhelper.h M +27 -0 app/views/digikamview.cpp M +4 -0 app/views/digikamview.h M +9 -0 app/views/leftsidebarwidgets.cpp M +8 -0 app/views/leftsidebarwidgets.h M +6 -0 libs/album/albummanager.cpp M +6 -0 libs/database/coredb/coredb.cpp M +1 -0 libs/database/coredb/coredb.h M +28 -1 libs/database/haar/haariface.cpp M +14 -2 libs/database/haar/haariface.h M +25 -0 libs/database/item/imageextendedproperties.cpp M +7 -0 libs/database/item/imageextendedproperties.h M +5 -0 libs/database/item/imageinfo.cpp M +2 -0 libs/database/item/imageinfo.h M +13 -0 libs/database/item/imagelister.cpp M +6 -0 libs/models/imagefiltermodel.cpp M +1 -0 libs/models/imagefiltermodel.h M +26 -1 libs/models/imagesortsettings.cpp M +4 -1 libs/models/imagesortsettings.h M +2 -0 libs/settings/applicationsettings.cpp M +3 -0 libs/settings/applicationsettings.h M +9 -0 libs/settings/applicationsettings_miscs.cpp M +4 -0 libs/settings/applicationsettings_p.cpp M +2 -0 libs/settings/applicationsettings_p.h M +11 -0 utilities/fuzzysearch/findduplicatesview.cpp M +73 -0 utilities/fuzzysearch/fuzzysearchview.cpp M +3 -0 utilities/fuzzysearch/fuzzysearchview.h https://commits.kde.org/digikam/e12dd0980f4371f1a7511a817fc7e17d7dccd2e6 -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #12 from Mario Frank <[hidden email]> --- (In reply to caulier.gilles from comment #10) > I discovered a serious problem to Slideshow and Presentation with some video > file to handle. So postponed is the best way. > > The doc is not a problem. > > For i18n, if patch over GUI is applied quickly and not touched later, it's > acceptable. Patching code not relevant of i18n is not a problem of course. > > Gilles Hey, after making some more tests, I patched the master branch. There is only one change which has to be localised, i.e. the sort role "By Similarity". I will make more tests in the next days and see if I can generate automated tests for the test suite. -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #13 from [hidden email] --- Great. it will be perfect. Gilles -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
Wolfgang Scheffner <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #14 from Wolfgang Scheffner <[hidden email]> --- Hey Mario, I'm just checking out if and how I can update the handbook regarding this patch. I found that there is a column "Avg. similarity" in the left sidebar if you are in the "Duplicates" tab. Average is nice for an overview of the results but I imagine that it could be useful to have individual simlarity values in the Image Area. The way would be probably to add "Show similarity" in the Views/Icons settings. An alternative would be to show the values in Table mode of the Image Area where View/Sort Images/By Similarity doesn't work right now because the sorting criterium here is determined by the title bar of the table. To the Sketch tab applies the same since here we don't even have the averages. Cheers Wolfgang -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #15 from Mario Frank <[hidden email]> --- (In reply to Wolfgang Scheffner from comment #14) > Hey Mario, > I'm just checking out if and how I can update the handbook regarding this > patch. I found that there is a column "Avg. similarity" in the left sidebar > if you are in the "Duplicates" tab. Average is nice for an overview of the > results but I imagine that it could be useful to have individual simlarity > values in the Image Area. The way would be probably to add "Show similarity" > in the Views/Icons settings. An alternative would be to show the values in > Table mode of the Image Area where View/Sort Images/By Similarity doesn't > work right now because the sorting criterium here is determined by the title > bar of the table. > To the Sketch tab applies the same since here we don't even have the > averages. > > Cheers > Wolfgang Hey Wolfgang, I will sleep over that. In fact, the similarity could be a relevant information in all related views (image/duplicates/sketch search). I will think about how to do this the best way. Then, I will open a new bug report. Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #16 from Mario Frank <[hidden email]> --- Hey Wolfgang, I think the best spot to give the similarity is in the table view. This way, the similarity can be shown in fuzzy, duplicates and also sketch search. I have a working implementation, where the similarity can be shown and thus sorting by similarity is possible. I will test and harden the implementation tomorrow. -- You are receiving this mail because: You are the assignee for the bug. |
In reply to this post by Niels
https://bugs.kde.org/show_bug.cgi?id=320666
--- Comment #17 from Mario Frank <[hidden email]> --- Hey Guys and Ladies, I implemented the possibility to show the similarity of the pictures in table view, when the fuzzy search sidebar is active. But I had to refactor my similarity sort patch. It was not optimal and I would have had to communicate the reference image id to which the specific image is similar everywhere via signal/slot communication or application settings. I already had that and learned that switching between the tabs in the fuzzy search sidebar leads to instable similarity results. Thus I took another approach. The current similarity value is stored in the ImageInfo. Getting the correct similarity in the image info was not really complex. The image search, sketch search and extern image drop search are all HAAR searches. Thus, the albums are rebuilt automatically when i get to the specific tab and the similarities can be extracted from the search results. This way, I only have to store the similarities for duplicates search since one image can be present in different duplicates albums with different similarities. The new solution is much more robust. Also, sorting by similarity is now also possible in table view and also in the sketch search which was not possible before. But currently, when when the fuzzy search sidebar is not active, the similarity column in the table view is still shown. But the similarity of the images is 0.0 since no reference image is present. Also, I polished the code a lot and polished the patch for bug https://bugs.kde.org/show_bug.cgi?id=374191 . So, concerning the handbook, there would be the following changes: In Table view, the context menu for activating colums contains the the option similarity in the item section. The find duplicates option in the context menu in faces sidebar uses the selected face tags as ordinary tags in duplicates search. I will upload the patch for review. Cheers, Mario -- You are receiving this mail because: You are the assignee for the bug. |
Free forum by Nabble | Edit this page |