| Summary: | Sort by Image Quality (assign quality tags) ignores many images | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jens <jens-bugs.kde.org> |
| Component: | Maintenance-Quality | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugskdeorg.20.dimon3000, caulier.gilles, mario.frank, metzpinguin |
| Priority: | NOR | ||
| Version: | 5.5.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 6.2.0 | |
| Sentry Crash Report: | |||
|
Description
Jens
2017-02-11 16:12:20 UTC
(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 great, thank you! (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. Yes, i come back at home this week end. I will start AppImage computation while the night. They will be available next Monday. Gilles So, here are the AppImages: https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Hello. This does not seem to be fixed. I have the same problem on Digikam 5.9.0 and the latest digikam-6.0.0-beta3-20181111T182317-x86-64. Hi, The image quality algorithm, mostly based on OpenCV, are broken, and need to be written. All this code have been written using OpenCV 1/2, and never tested under OpenCV 3 Now all algorithm are branched with unit-tests, and all fail (there are disabled actually). Only one Quality tool work fine as i rewritten the code without OpenCV : over and under exposure checks. Best Gilles Caulier Hello. I found an interesting behaviour. I added some new albums to the collection. Then started categorizing the images. The algorithm seems to have scanned all the new albums, but the results were applied to a single image! During the maintenance process, the quality label on the first image of the last album was changing all the time. This might be the cause. (In reply to bugskdeorg.20.dimon3000 from comment #8) Forgot to mention. I am running digikam-6.0.0-beta3-20181124T130027 This bug is now fixed in digiKam-6.2.0. Images without a pick label were not processed. I close the bug now. https://invent.kde.org/kde/digikam/commit/55ba2b110d82adc60b98a0a911d4b70d57685766 Maik |