<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><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">stefan.mueller.83@gmail.com</a>> a écrit :<br></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">
<p>Hello Woenx, Bonjour Gilles <br>
</p>
<p>thanks for those quick answer, at least we agree than some
refurbishment is necessary <span class="gmail-m_-87264457422855112moz-smiley-s3"><span>;-)</span></span>
<br>
</p>
<p><br>
</p>
<div class="gmail-m_-87264457422855112moz-cite-prefix"><br>
<blockquote type="cite">
<div>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><br>
</div>
<div>This can be done through this GSoC 2019 project :</div>
<div><br>
</div>
<a href="https://community.kde.org/GSoC/2019/Ideas#Project:_AI_Face_Recognition_with_OpenCV_DNN_module" target="_blank">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></div></div></blockquote><div><br></div><div>yes, but i'm talking about a customized face recognition engine as 4 existing yet here :</div><div><br></div><div><a href="https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition">https://cgit.kde.org/digikam.git/tree/core/libs/facesengine/recognition</a><br></div><div><br></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"><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><br></div><div>The engine and the GUI are separated, as expected of course. The GUI to tag face is mostly implemented here :</div><div><br></div><div>* <a href="https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement">https://cgit.kde.org/digikam.git/tree/core/utilities/facemanagement</a> => assignnamewidget.cpp/.h<br></div><div>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><br></div><div>* <a href="https://cgit.kde.org/digikam.git/tree/core/app/items/delegate">https://cgit.kde.org/digikam.git/tree/core/app/items/delegate</a> => faceitemdelegate.cpp/.h </div><div><br></div><div>* <a href="https://cgit.kde.org/digikam.git/tree/core/app/items/overlays">https://cgit.kde.org/digikam.git/tree/core/app/items/overlays</a> => assignnameoverlay.cpp/.h and facerejectionoverlay.cpp/.h</div><div> <br></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"><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><br></div><div>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><br></div><div>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><br></div><div>PR can help visually to review and comment patch, but all can be done also with bugzilla.</div><div><br></div><div>So for me PR is so far not necessary and don't improve the project management workflow.</div><div><br></div><div>Bugzilla has the project story since the beginning (2001). And there i would not change this in the future...</div><div><br></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"><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></div></div></blockquote><div><br></div><div>No. Personalty, i must for 6.1.0</div><div><br></div><div>1/ Finalize the internal plugins API for Genric, Editor, and BQM.</div><div>2/ Document the API</div><div>3/ Export the API for external contribution. Currently all plugins are inside digiKam project.</div><div>4/ Prepare the rooms for the new students.</div><div><br></div><div>Later 6.1.0 :</div><div><br></div><div>1/ Prepare new plugins interface as :</div><div><div><br></div><div> * 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>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><br></div></div><div> * 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><br></div><div> * 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><br></div><div> * 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><br></div><div>Voilà</div><div><br></div><div>Gilles Caulier<br></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"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div class="gmail_quote">
</div>
</div>
</div>
</blockquote>
</div>
</blockquote></div></div></div></div></div></div>