Bug 376359 - Sort by Image Quality (assign quality tags) ignores many images
Summary: Sort by Image Quality (assign quality tags) ignores many images
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Maintenance-Quality (show other bugs)
Version: 5.5.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-11 16:12 UTC by Jens
Modified: 2019-06-19 19:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens 2017-02-11 16:12:20 UTC
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!
Comment 1 Mario Frank 2017-02-22 11:54:30 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
Comment 2 Jens 2017-02-22 13:18:50 UTC
great, thank you!
Comment 3 Mario Frank 2017-02-24 08:42:08 UTC
(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.
Comment 4 caulier.gilles 2017-02-24 10:00:08 UTC
Yes, i come back at home this week end. I will start AppImage computation while the night. They will be available next Monday.

Gilles
Comment 5 Mario Frank 2017-02-28 16:00:20 UTC
So, here are the AppImages:

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM
Comment 6 bugskdeorg.20.dimon3000 2018-11-13 13:30:52 UTC
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.
Comment 7 caulier.gilles 2018-11-13 14:02:36 UTC
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
Comment 8 bugskdeorg.20.dimon3000 2018-11-24 23:12:34 UTC
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.
Comment 9 bugskdeorg.20.dimon3000 2018-11-24 23:13:29 UTC
(In reply to bugskdeorg.20.dimon3000 from comment #8)

Forgot to mention. I am running digikam-6.0.0-beta3-20181124T130027
Comment 10 Maik Qualmann 2019-06-19 19:19:37 UTC
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