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