[digiKam-users] GPU usage (with OpenCL), moving my pictures disk (=albums) structure, and facial recognition

[Gilles Caulier]

Hi Timothy,


Le jeu. 26 janv. 2023 à 16:01, Tim Carr <timothyjcarr at gmail.com> a écrit :
>
> Hi - I'm relatively new to DigiKam, but really enjoying using it (I used to just work in Mac Photos).  I'm working on migrating my 20,000+ photos into the program, running an Intel Mac Ventura 13.1 on an SSD disk, and using DigiKam v. 7.9.  A got a few newbie questions (and I've RTFM'ed most of the documentation! <grin>).  Please let me know if it's preferable that I break these up into seperate email questions or there's a better forum to ask this stuff:
>
> - I've noticed when doing whole-collection activities like facial recognition/detection, I can use all my processor cores (which it does), but very little usage of the GPU.  Is that by design, rather than tapping into the power the GPU can provide?  Or DigiKam just doesn't really use much of that by default regardless of whats available?

It's by design... for the moment. Face management use OpenCV in
background, and enabling GPU is not stable. In fact there is no GPU
calls in digiKam, all is done in OpenCV. So for the moment, when we
package digiKam, OpenCV is compiled with GPU supports. We will see if
this problem remains in time... For the moment we wants this feature
the more stable as possible.

>
> - I've seen the notes about disabling OpenCL on Mac's, but in futzing around with things, leaving that enabled doesn't seem to break anything.  Is leaving that enabled something that might help performance?

Aha, see my previous comment.

>
> - I exported all my pictures out of Mac Photos using OSXPhotos, and created a directory structure that has Year/Month/Day.  I've realized that creates a TON of separate albums.  I'd prefer just using a few albums but incorporating tagging to help segregate things.  Can I just move those physical files through the OS, and then DigiKam will automatically recognize the different layout but retain all the database information?

Yes. Item are identified in database using a sums done on first amount
of bytes. Files will be recognized automatically.

>
> - I've seen some of the documentation saying NoSQL is good for collections up to 100K or so.  Is there any noticeable performance increase if I migrate to either a local MySQL engine on the Mac, or offloading that to a whole separate server (on my LAN) for that DB activity?

In fact the database is not the only parameter in the equation. The
complicity of folders hierarchies in the collections, the media used
to store the collection (use SSD to host the database, one others to
host the collections if possible), the database as local or remote.
All is described in the online documentation. See the Digital Asset
Management section here :

https://docs.digikam.org/en/asset_management.html

The doc is under huge review, rewriting, and translating. So please be
patient and constructive if you found errors in text.
Note : With 8.0.0 release, the sqlite database gains a new WAL option
which improve database performances. See here :

https://docs.digikam.org/en/setup_application/database_settings.html


>
> - What are the conditions you want to use the Tools/Maintenance option to clear and re-build all facial recognition data?  I've gone through the process of approving/ignoring most of my collection.  Is that something that would improve future recognition of what's already been built, or is that really only something if you notice you're not getting very good results from scans?

Typically, if you change the Deep Learning Model to Yolo3, which is
the best but time consuming. In this case, it's better to rebuild all
from scratch for better result in detection and recognition. Again,
read the People View and Maintenance tool sections for details.

https://docs.digikam.org/en/main_window/people_view.html

https://docs.digikam.org/en/maintenance_tools/maintenance_faces.html

Note : For the maintenance tool, i don't yet review all the contents,
and a lots of contents are missing...

Voilà, My best

Gilles Caulier