Sort Views to display Unconfirmed Faces together

[kartikx]

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.

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

[Maik Qualmann]

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

[kartikx]

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 (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 <[hidden email]> 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

[Maik Qualmann]

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 <[hidden email]>
>
> 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

[kartikx]

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 <[hidden email]> 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 <[hidden email]>
>
> 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