[Digikam-devel] Re: Face detection

[Marcel Wiesweg]

> If I select a tag within "People", e.g. People > Person 1 it shows me all
> the phtos associated to that person. Having that view I start the
> scanning+merge for another folder. Faces found are now added to the People
> > Person 1 view instead of unknown or the proper tag, i.e. People > Person
> 2. In fact the Person 2 does not show any new pictures found althought
> there are quite a few so it should have found at least one that matches
> Person 2.
> 
> So to me it seems that found faces are always added to the tag that one
> currently views while scanning.

Does this assignment remain after switching the view or closing digikam, so 
it's really the wrong tag assigned?
Is this reproducible also for other tags, so it is not caused by a broken face 
recognition which assigns Person 1 to almost anything?


> 
> Another thing I do not understand is of what purpose it is to have some
> checkboxes in the "pick albums for scanning" in a brighter colour than
> others. 

I can confirm this, it's probably a subtle gradient applied by the oxygen 
style. Going towards the bottom, the color becomes darker.

> Also it seems that the list scrolls automatically if one moves the
> mouse cursor to its bottom but not when moving it to its top.

Yes. If you hover an item, you "select" it. Qt always shows the complete 
currently selected item. In the top, there is never a partially visible item, 
it's always scrolled to an exact item border. At the bottom, there is often a 
partially visible item, which becomes selected on mouse over, is shown fully, 
and so on.
If this is undesirable, we can disable autoscrolling.

> 
> Further, after I have scanned a folder and want to pick another one to scan
> I have to uncheck the former. there is neither a "clear line" button in
> the drop-down field nor does digikam uncheck the folders it finished
> scanning. 

No, the last used folder are stored in config. We'll need a clear button.


> whereby the latter might be due to the bug that it hangs on one
> of the last images when scanning and thus never actually finishes.

I'll commit some debugging statement to SVN to finally fix this annoying bug 
(which I cannot reproduce...)

> Lets say one confirmed Person 1 for a picture where actually Person 2 is
> shown. IMO there is no obvious (easy enough) way to correct that mistake.

I'm unsure atm if training can be undone. Need to ask Alex.

> 
> If one views People > Person 1 and removes the Person 1 tag from an image
> the image is not removed from the view. If one opens the picture one sees
> that it still has the face marked as Person 1. Clicking on the "Person 1"
> tag does not give any possibility to change or remove that tag.

In preview, you'll need to click on the label with the name to open that one 
for editing again. In the icon view, there's still the Reject overlay to 
remove, though you're right, there should be an overlay for editing.

And when removing a tag, all faces for this tag need to be removed as well, I 
will fix that.

> For pictures in the "unknown" tag if one clicks on "Who is this" there is
> no way to select an already existing tag but one has to type the name
> again.

You'd prefer the combo box like in the preview mode?
Note that the last typed text remains, which can be both convenient or 
annoying.

> 
> If one starts typing the already existing tag suddenly appears in a
> drop-down menu. Moving the mouse on the drop-down menu and out of it
> closes the drop- down menu which should not happen.

It happens when you touch a different picture with the mouse. That's the idea 
of a mouse-hover overlay... perhaps we need some sort of locking for the cases 
when the overlay opens a menu.

> If one wants to add/confirm etc. tags while digikam still scans the view is
> refreshed constantly and makes working on the pictures impossible. I think
> this is related to the bug that restarts videos when one plays them from
> within a folder that new pictures are added to.

It's a similar problem, but probably not the same solution. But it has the 
same solution as the mouse-over-drop-down-menu problem above.
When images are inserted before the current picture, its position will change.
We can think of a solution with a "persistent editor" if the line edit 
currently has the focus, but it's not too easy to implement (currently, the 
overlays take the easy way of hiding at any indication of change.)