[Digikam-devel] libkface

Gilles Caulier caulier.gilles at gmail.com
Sun Jun 29 15:20:08 BST 2014


2014-06-29 12:17 GMT+02:00 Tobias Leupold <tobias.leupold at web.de>:
>> > The detection and recognition code resides in
>> >
>> >         AnnotationDialog/ImagePreview.cpp
>>
>> Do you use multithreading here ?
> No, it's just a procedural approach. At the moment, all scanning is done when
> clicking a button on the image that is currently open and the widget is simply
> disabled until it's done.

You can try the very simple way to fork facedetection or
facerecognition method in a separated thread using :

http://qt-project.org/doc/qt-4.8/qtconcurrentrun.html#run

It's simple to use. Look my code to compute for ex :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/dimg/filters/sharp/sharpenfilter.cpp#L238

here there is a loop to sharpen an image decomposed as egual parts
(depending of number of CPU)

We create QFuture task using QtConcurrent::run(), which call a dedicated method.

We wait that task are complete to process new one, until image is
fully processed.

You can do the same with facedetection from ex, to process a group of images.

You have a list of items, to process to call facedetection method. you
decompose list by number of CPU and fork each item to process with
Qt::Concurent::run, which will run facedetection on each processor.
Image will be analyzed in parallel. Marcel has already lock database
calls, so it safe to play with multithreading with libkface. As
computation with OpenCV take a while, it's not negligible.

digiKam run like this (but it do not use QtConcurrent)

>
>> Do you check kphotoalbum into valgrind to see if memory is leak with
>> libkface ?
> I'll try to do that, but -- to be honest -- I don't really know what the
> valgrind output means ... I still have to learn about this.

valgrind is a run-time memory analyzer. It run program as well in a VM
like and check all memory calls, memory allocations, memory free, and
look if something is bad somewhere. Code must be compiled with debug
symbols.

There are other tools, but runing as static : cppcheck for ex, but
Coverity is the most powerfull, and very used in OpenSource :

https://scan.coverity.com/projects

>
>> All help about API doc can improve usability of libkface in other projects.
> Yeah, that's probably one thing I actually _can_ contribute to libkface.

sure. No need to give a patch, commit directly. We are CC
automatically by mail...

>
>> In KFaceGUI, there are some visual glitches with face rectangle, when
>> you move it for ex. I polished code a lots but not yet found the GUI
>> dysfunction. It's not very important but at least, if we can have a
>> clean implementation here, it will be cool.
> I just started coding C++/Qt/KDE back in April, so I think you're a bit
> smarter than me, but I'll have a look at it and do my very best. If I find
> something, I'll send a patch.

No problem

>
>> Don't forget that you must use current implementation of libkface for
>> your tests, where code is the most hacked/tested for the moment.
> At the moment, I use the libkface version shipped with Digikam 4.0.0, but I'll
> try to write an ebuild (I'm on Gentoo) installing the CVS version so that I
> can check it against the latest code.

No. use git/master code where i spare a lots if time (a least 3 weeks
of work to review code again and again, and again), to talk with
MArcel about all technical details, to check all bugzilla entries and
fix, consolidate and verify.

Gilles Caulier



More information about the Digikam-devel mailing list