DK 8.5 won't detect faces: OPENCV/DNN exception
Michael Miller
michael_miller at msn.com
Tue Dec 31 01:42:40 GMT 2024
Hi Steve,
> Incidentally: I noticed that the workflow tab was changed (relative to 8.5) to
> a drop-down of three things. That seems like a nice simplification. One
> suggestion I would offer is: for the model settings maybe put "(recommended)"
> after the two recommended models -- because that is something I have looked up
> in the manual more than once.
Yes, I agree. The rest of the devs and I are discussing removing SSD, YOLO, and OpenFace completely from 8.6.0. This should simplify the UI even more. If we decide to keep the other models, I’ll add your idea of putting “recommended” or “preferred” next to YuNet and SFace.
> You mentioned previously that the face detection was "rewritten" -- can you
> summarize? Did things change at the dnn level or mostly at the UI level?
Are you referring to the 8.5.0 changes, or what’s coming in 8.6.0?
In 8.6.0, everything has changed between the UI and the DNN level, including the way we call the DNN models.
First, the pipelines have a whole new structure that allows us to dynamically scale the number of worker threads based on load and the hardware.
Next, the way the images are loaded and converted to a format that OpenCV understands has changed. I found a bug in 8.5.0 while doing this. 8.5.0 was converting the images to BGR format and YuNet and SFace want RGB. I also think this could be where the OpenCV error is happening. I need to review the code that changes the image from the internal digiKam format to OpenCV (DImg or QImage to cv::Mat).
Another change is the 8.6.0 pipelines take better advantage of GPU processing. Images are moved to the GPU for resizing and color format conversion. We’re also passing the GPU image to the DNN layer now so DNN processing happens on the GPU via OpenCL.
The final big change in 8.6.0 is the face classifier. The classifier is what “matches” one face to another for recognition. In 8.5.0 we used a custom made K Nearest Neighbor (KNN) classifier. In 8.6.0 we’re using an ensemble approach using cross validating KNN and SVM classifiers from OpenCV with a single custom distance check. It’s faster and more accurate.
The only thing we’re really reusing from 8.5.0 are the YuNet and SFace models themselves.
> So then I went to the Recognize step. The results are more mixed. On the
> positive side, the matching mostly worked and WOW it is *waaay* better than
> the previous model was (in my memory). Kudos to all involved!
Thank you. We’re trying to make it even better.
> Digikam::FacialRecognitionWrapper::recognizeFaces: cv::Exception:
> OpenCV(4.10.0) /mnt/data/b/master/ext_opencv/ext_opencv-prefix/src/ext_opencv/
> modules/core/src/arithm.cpp:658: error: (-209:Sizes of input arguments do not
> match) The operation is neither 'array op array' (where arrays have the same
> size and the same number of channels), nor 'array op scalar', nor 'scalar op
> array' in function ‘arithm_op’
I’ll dig into this more. My suspicion is if it’s not a Debian package issue, then it’s caused by the way we’re converting the image to OpenCV format, or I’m not catching an empty image being passed to the face recognizer.
> This is strongly hinting at some issue with the Debian packages. I'm going to
> poke around and maybe try building OpenCV 4.10 to see if that fixes things. Is
> that the only library I should be concerned about in this context?
I use a Mac for development, and I’m unable to reproduce the issue on my dev box. I’m still building a Debian machine to see if I can repro the issue there.
Cheers,
Mike
More information about the Digikam-users
mailing list