[digiKam-users] either face recognition screen is buggy or I still don't understand it - at least I can say that more convenient bulk change of face tags (no auto refresh / set faces via context menu) is neccessary #V5.9.0 Windows Feb 27 2018

[Gilles Caulier]

Le sam. 2 févr. 2019 à 12:47, Stefan Müller <stefan.mueller.83 at gmail.com> a
écrit :

> Hello Woenx, Bonjour Gilles
>
> thanks for those quick answer, at least we agree than some refurbishment
> is necessary ;-)
>
>
>
> One piece of code which can be open as plugin is the recognition modules.
> API is already designed to be modular, but not exported.
>
> This can be done through this GSoC 2019 project :
>
>
> https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module
>
> that would mean, when it will get done during GSoC 2019, we can write your
> own face recognition plug-in, what fulfils all these requirements, we
> desire?
>

yes, but i'm talking about a customized face recognition engine as 4
existing yet here :

https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition

We won't need to understand the face recognition process in detail, don't
> we? All what would happen to create an customize interface/GUI, wouldn't it?
>

The engine and the GUI are separated, as expected of course. The GUI to tag
face is mostly implemented here :

* https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement =>
assignnamewidget.cpp/.h
Note : the rest of classes in this directory are relevant of the workflow :
communication with the face engines (detection/recognition) and the face
database to store face histogram.

* https://cgit.kde.org/digikam.git/tree/core/app/items/delegate =>
faceitemdelegate.cpp/.h

* https://cgit.kde.org/digikam.git/tree/core/app/items/overlays =>
assignnameoverlay.cpp/.h and facerejectionoverlay.cpp/.h


> the only option to make some changes now, to work on the digiKam source
> code and send a pull request, isn't it?
>

Not al all. It's a possible way, but, i'm always in favor to only use
bugzilla as the main Agile project management tool. You have a file to
create or already created, you build a patch against current
implementation, and you attach file. It's simple, archived, and follow all
QA requirement.

A pull request is a feature add by KDE team to try to recrut more
contributors. But there is no link with bugzilla. If you have a bugzilla
file to close with a PR, you need to manage both tools entries at the same
time. This is a waste of time, and as i already said more than one time in
the past, the time is precious.

PR can help visually to review and comment patch, but all can be done also
with bugzilla.

So for me PR is so far not necessary and don't improve the project
management workflow.

Bugzilla has the project story since the beginning (2001). And there i
would not change this in the future...

Any chance that anything will done before the GSoC 2019?
>
>
No. Personalty, i must for 6.1.0

1/ Finalize the internal plugins API for Genric, Editor, and BQM.
2/ Document the API
3/ Export the API for external contribution. Currently all plugins are
inside digiKam project.
4/ Prepare the rooms for the new students.

Later 6.1.0 :

1/ Prepare new plugins interface as :

 * BQM export tools : this is the prior step to do. We will have a student
working on this topic (i hope). We have plenty of bugzilla entries relevant
of this feature.
Typically, the hard-coded Batch Queue setting view to store processed files
will be extended with many target as Collection (one already implemented),
Local drive, FTP, SFTP, and or course the remote web-services through the
unified API which have been already available since summer 2018 but not yet
fully finalized. Typically, you prepare a list of files, you assign a piece
of tools (resize, border, NR, sharp, ex), and at end, files will be
automatically exported somewhere (as Flickr for ex).

 * Raw engine : the internal one based on libraw, one with RawTherapee (for
ex), one with DarkTable (for ex). This will be a big step and require to
separate well all implementation to be versatile. The code is already
separated for libraw engine, but nothing was done to manage this feature
with plugins.

 * Maintenance : All tools are hardcoded, and started in a specific order.
It can be managed as modules, but code is not yet designed in this way.

 * Database : We have already a tool named migration which can be a good
candidate, but plenty of new ones can be written : backup, export, etc. Do
not ask me to make the database engine as module yet, it's a tedious
project.

Voilà

Gilles Caulier

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20190202/960adeb6/attachment.html>