Face recognition - avoid messing up the data

[daj omu]

Hi,

Sorry. Your answer ended up in the spam folder. I guess that is one
solution, but I do not know what is good enough or too bad.
Does not DK have an image quality sorter? I would assume that DK «knows»
the quality of a picture and should be able to automatically know if the
image is too blurry or whatever?

Dajomu

On Mon, 23 Oct 2023 at 06:07, Helen Jelen <inomniapar4tus at gmail.com> wrote:

> Hei,
>
> Didn't you like my suggestion I sent Oct. 8th?
>
>
> BR,
>
>
> h.
>
>
> On Sun, Oct 22, 2023, 22:40 daj omu <dajomu1 at gmail.com> wrote:
>
>> Hi,
>>
>> No takers on my question on how to manage faces of bad quality. I want
>> the name tag, but do not want the database to become unusable.
>>
>> DJ
>>
>> On Sat, 7 Oct 2023 at 18:14, daj omu <dajomu1 at gmail.com> wrote:
>>
>>> Yolo is probably good. Now if I have 20 really good photos for training
>>> the engine on a specific face and after that I add 50 bad and blurry faces,
>>> will that mess it up? If so, how can I avoid having the face recognition
>>> totally messed up after a while?
>>>
>>>
>>> On Sat, 7 Oct 2023 at 17:01, Gilles Caulier <caulier.gilles at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> If you use the Yolo v3 DNN face engine, I see very good results in
>>>> face workflow. Look the samples listed in online documentation:
>>>>
>>>> https://docs.digikam.org/en/main_window/people_view.html#face-detection
>>>>
>>>> Best
>>>>
>>>> Gilles Caulier
>>>>
>>>> Le sam. 7 oct. 2023 à 11:41, Remco Viëtor <remco.vietor at wanadoo.fr> a
>>>> écrit :
>>>> >
>>>> > On samedi 7 octobre 2023 11:27:47 CEST daj omu wrote:
>>>> > > Hi,
>>>> > >
>>>> > > Will blurry and low quality images eventually mess up the face
>>>> recognition
>>>> > > engine?
>>>> > >
>>>> > > Dajomu
>>>> >
>>>> > There's a saying "garbage in, garbage out"...
>>>> >
>>>> >
>>>> >
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20231023/3ba52e51/attachment.htm>