Sort Views to display Unconfirmed Faces together

[Kartik Ramesh]

Hi Maik,

You're right, I didn't think about that. Multiple Database Read operations
will certainly be time consuming. Would it be a good idea then to include
unconfirmedFaceCounts as a field of ItemInfo? This would get updated
whenever the Recognition algorithm marks faces as Unconfirmed.

Also what do you think about the issue of the Album view getting sorted,
when trying to sort the Face View?

On Sun, Jun 14, 2020 at 8:14 PM Maik Qualmann <metzpinguin at gmail.com> wrote:

> Hi Kartik,
>
> We cannot do the sorting using the FaceTagsEditor. You have to assume that
> there are several thousand face items in the model. The model always
> compares
> whether an item has to be sorted in front of or behind. This would be tens
> of
> thousands of database accesses via the FaceTagsEditor. Under MySQL in
> particular, it would probably take a long time and the network traffic
> would
> be very heavily used. Therefore, almost all values are cached in the
> ItemInfo
> class.
>
> Maik
>
> Am Samstag, 13. Juni 2020, 08:33:11 CEST schrieb Kartik Ramesh:
> > Hi Maik,
> >
> > You're right that sorting faces needs info about the number of
> Unconfirmed,
> > Confirmed faces. To get that I was using the
> > FaceTagsEditor::unconfirmedFaceTagsIfaces
> > <
> https://invent.kde.org/graphics/digikam/-/blob/master/core/libs/database/ta
> > gs/facetagseditor.cpp#L67> (with a slight modification that it returns
> > Unconfirmed Faces and not Unconfirmed+Unknown faces). This method takes
> in
> > an ItemInfo and returns the list of Unconfirmed faces in that image.
> >
> > I haven't yet committed to the remote repo. because I wasn't sure about
> > this implementation, however I'll do that now, so that you and other
> > mentors may have a look at this.
> >
> > Kartik
> >
> > On Sat, Jun 13, 2020 at 10:17 AM Maik Qualmann <metzpinguin at gmail.com>
> >
> > wrote:
> > > Hi Kartik,
> > >
> > > To sort faces you need the information about confirmed and unconfirmed
> > > faces
> > > in the ItemInfo class. The ItemInfo class does not currently provide
> this
> > > information. The sorting of faces must not affect the other views. Are
> the
> > > latest sort changes already in the branch? I'll take a closer look at
> your
> > > branch at the weekend.
> > >
> > > Maik
> > >
> > > Am Freitag, 12. Juni 2020, 14:17:57 CEST schrieb Kartik Ramesh:
> > > > Hello all,
> > > >
> > > > I was working on the next issue in my Project which is to modify
> sorting
> > >
> > > of
> > >
> > > > views so that all Unconfirmed Faces for any tag appear collectively
> > >
> > > (either
> > >
> > > > before or after) the set of Confirmed Faces. This enhances visibility
> > > > for
> > > > the user, and allows easy confirm/reject operations.
> > > >
> > > > Sorting implementations for views are present in ItemSortSettings,
> so I
> > >
> > > did
> > >
> > > > a little modifications, and I've been able to sort the view as shown
> > > > here
> > > > <https://imgur.com/a/xODQfgj>.
> > > >
> > > > However there's an issue with this, we're not sorting Faces but
> instead
> > > > ItemInfos. Since every view (be it Albums view or People view) works
> on
> > >
> > > the
> > >
> > > > same model, this new sorting order will enforce changes on the other
> > >
> > > views
> > >
> > > > as well. I don't think it's possible for face A to appear before
> face B
> > >
> > > but
> > >
> > > > image A (which contains face A) appears after image B (please
> correct me
> > >
> > > if
> > >
> > > > wrong).
> > > >
> > > > One way to fix this would be to implement a new Sorting role just for
> > >
> > > this
> > >
> > > > purpose. I also have some more fixes in mind but I would like to hear
> > >
> > > other
> > >
> > > > thoughts on this.
> > > >
> > > > Kartik
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20200615/2ea43791/attachment.htm>