[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

[J Albrecht]

Have you no shame?

I cringe every time that I read about Facial Recognition software. You developers are like a bunch of giddy Manhattan Project nerds, gleefully and obliviously participating in the acceleration of our collective doom. You people are contributing to the development of scary, scary stuff. You’re not alone; Consider yourself members of a club which includes Custer Bomb Designers and Genome Modifiers. Like you, they see absolutely nothing wrong with what they’re doing because after all, they’re only building and promoting innocuous technology which will benefit “us”. Yeah, right. Tell that to the Uyghers…   …and to your children.


> On 2 Feb 2019, at 08:31, Gilles Caulier <caulier.gilles at gmail.com> wrote:
> 
> 
> 
> Le sam. 2 févr. 2019 à 12:47, Stefan Müller <stefan.mueller.83 at gmail.com <mailto: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 <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 <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 <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 <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 <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/46f87105/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20190202/46f87105/attachment.sig>