<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Have you no shame? <div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Feb 2019, at 08:31, Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com" class="">caulier.gilles@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 2 févr. 2019 à 12:47, Stefan Müller <<a href="mailto:stefan.mueller.83@gmail.com" class="">stefan.mueller.83@gmail.com</a>> a écrit :<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" class=""><p class="">Hello Woenx, Bonjour Gilles <br class="">
</p><p class="">thanks for those quick answer, at least we agree than some
refurbishment is necessary <span class="gmail-m_-87264457422855112moz-smiley-s3"><span class="">;-)</span></span>
<br class="">
</p><p class=""><br class="">
</p>
<div class="gmail-m_-87264457422855112moz-cite-prefix"><br class="">
<blockquote type="cite" class="">
<div class="">One piece of code which can be open as plugin is the
recognition modules. API is already designed to be modular,
but not exported.</div>
<div class=""><br class="">
</div>
<div class="">This can be done through this GSoC 2019 project :</div>
<div class=""><br class="">
</div>
<a href="https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module" target="_blank" class="">https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module</a></blockquote>
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? <br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">yes, but i'm talking about a customized face recognition engine as 4 existing yet here :</div><div class=""><br class=""></div><div class=""><a href="https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition" class="">https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition</a><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class=""><div class="gmail-m_-87264457422855112moz-cite-prefix">
</div>
<div class="gmail-m_-87264457422855112moz-cite-prefix">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?</div></div></blockquote><div class=""><br class=""></div><div class="">The engine and the GUI are separated, as expected of course. The GUI to tag face is mostly implemented here :</div><div class=""><br class=""></div><div class="">* <a href="https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement" class="">https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement</a> => assignnamewidget.cpp/.h<br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">* <a href="https://cgit.kde.org/digikam.git/tree/core/app/items/delegate" class="">https://cgit.kde.org/digikam.git/tree/core/app/items/delegate</a> => faceitemdelegate.cpp/.h </div><div class=""><br class=""></div><div class="">* <a href="https://cgit.kde.org/digikam.git/tree/core/app/items/overlays" class="">https://cgit.kde.org/digikam.git/tree/core/app/items/overlays</a> => assignnameoverlay.cpp/.h and facerejectionoverlay.cpp/.h</div><div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class=""><div class="gmail-m_-87264457422855112moz-cite-prefix">
</div>
<div class="gmail-m_-87264457422855112moz-cite-prefix">the only option to make some changes
now, to work on the digiKam source code and send a pull request,
isn't it?</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">PR can help visually to review and comment patch, but all can be done also with bugzilla.</div><div class=""><br class=""></div><div class="">So for me PR is so far not necessary and don't improve the project management workflow.</div><div class=""><br class=""></div><div class="">Bugzilla has the project story since the beginning (2001). And there i would not change this in the future...</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class=""><div class="gmail-m_-87264457422855112moz-cite-prefix">Any chance that anything will done
before the GSoC 2019?</div>
<div class="gmail-m_-87264457422855112moz-cite-prefix"><br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">No. Personalty, i must for 6.1.0</div><div class=""><br class=""></div><div class="">1/ Finalize the internal plugins API for Genric, Editor, and BQM.</div><div class="">2/ Document the API</div><div class="">3/ Export the API for external contribution. Currently all plugins are inside digiKam project.</div><div class="">4/ Prepare the rooms for the new students.</div><div class=""><br class=""></div><div class="">Later 6.1.0 :</div><div class=""><br class=""></div><div class="">1/ Prepare new plugins interface as :</div><div class=""><div class=""><br class=""></div><div class=""> * 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.</div><div class="">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).</div><div class=""><br class=""></div></div><div class=""> * 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.</div><div class=""><br class=""></div><div class=""> * 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.</div><div class=""><br class=""></div><div class=""> * 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.</div><div class=""><br class=""></div><div class="">Voilà</div><div class=""><br class=""></div><div class="">Gilles Caulier<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote">
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div></div></div></div></div>
</div></blockquote></div><br class=""></div></body></html>