RuntimeError: Unsupported image type, must be 8bit gray or RGB image on cnn face detector

GuimExc commented 6 years ago

Expected Behavior

Hello! It seems that Dlib 19.9.0 introduced a bug on the cnn_face_detection. Ideally, one would pass to cnn_face_detection a list of images, and then get the rectangle objects in return.

Current Behavior

However, what it actually happens is that it gives the following error: RuntimeError: Unsupported image type, must be 8bit gray or RGB image

This only happens if the input of the detector is a list of numpy arrays. If it's an image alone, it works. Also, if I use an older version than 19.9, this works alright.

Steps to Reproduce

import dlib
import numpy as np

face_detector_path = 'mmod_human_face_detector.dat'
face_detector = dlib.cnn_face_detection_model_v1(face_detector_path)
one_image = np.zeros((128, 128, 3))
two_images = [np.zeros((128, 128, 3)), np.zeros((128, 128, 3))]
face_detector(one_image) # This works well
face_detector(two_images) # This fails, only in Dlib 19.9
RuntimeError: Unsupported image type, must be 8bit gray or RGB image

Version: 19.9
Where did you get dlib: pip install dlib==19.9
Platform: Ubuntu 16.04.3 LTS, 64-bit with CUDA 8.0 and CuDNN v7
Compiler: Python 3.6.4

Suggestions

I've been taking a look at the code and the part where the error is triggered seems unchanged after 19.9. Maybe the function is_rgb_python_image was changed on 19.9.0 release?

Thanks!

davisking commented 6 years ago

Thanks for finding this bug. I just pushed the fix to github.

Also, the code you posted should never have worked at all. You should get an error since the images are doubles rather than uint8 which is required. I fixed the lack of an error message about that as well.

dlib-issue-bot commented 6 years ago

Warning: this issue has been inactive for 201 days and will be automatically closed on 2018-09-07 if there is no further activity.

If you are waiting for a response but haven't received one it's likely your question is somehow inappropriate. E.g. you didn't follow the issue submission instructions, or your question is easily answerable by reading the FAQ, dlib's documentation, or a Google search.

dlib-issue-bot commented 6 years ago

Notice: this issue has been closed because it has been inactive for 205 days. You may reopen this issue if it has been closed in error.

richdear commented 4 months ago

same issue after updating the library to the latest version!

OlliejED commented 4 months ago

The new major version of Numpy (2.0.0) seems to be causing this error. I fixed it by downgrading numpy from 2.0.0 -> 1.26.4.

davisking commented 4 months ago

Yep, should be fixed now with https://github.com/davisking/dlib/pull/2971 merged.

richdear commented 4 months ago

Yep, should be fixed now with #2971 merged.

Sorry but it is not fixed, I upgraded to : /usr/local/lib/python3.10/dist-packages (19.24.4) But I have same error!

davisking commented 4 months ago

Huh, yeah, it still doesn't work with numpy 2.0.0. I.e.

import dlib
import numpy as np

face_detector_path = 'mmod_human_face_detector.dat'
face_detector = dlib.cnn_face_detection_model_v1(face_detector_path)
one_image = np.zeros((128, 128, 3))
two_images = [np.zeros((128, 128, 3)), np.zeros((128, 128, 3))]
face_detector(one_image) # This works well
face_detector(two_images) # This fails, only in Dlib 19.9

that fails.

@yuzawa-san does that work for you? Your PR https://github.com/davisking/dlib/pull/2970 said it was working for you. Doesn't work for me when I try this though. I.e. if you grab dlib from github and install that does the above work for you?

arrufat commented 4 months ago

It fails for me, too. However, the error message tells us why: It only supports 8bit gray or RGB images, I don't know what changed, or why it worked before, but with this change, it works for me:

np.zeros((128, 128, 3), dtype=np.uint8)

davisking commented 4 months ago

lol, did you delete the joke about taxes? That was excellent 😁

And yeah, guess they just changed some defaults. Which is reasonable I suppose. 🤷‍♂️

arrufat commented 4 months ago

Yes, I wasn't sure about how it would be taken, so I deleted it, here it is again:

Python and the types are like the government and the taxes: they know that they are, but they want to know if you know, too.

arrufat commented 4 months ago

It's not mine, though, I read it somewhere, some time ago, sadly I can't remember to credit the author :(

davisking commented 4 months ago

Na that's on point. I'll have to remember that one 😂

yuzawa-san commented 4 months ago

I agree with @arrufat about not knowing why/how this worked prior. I did not change any dlib code in my upgrade PR. All I can find is that maybe a default type changed https://numpy.org/devdocs/numpy_2_0_migration_guide.html

My tests involved loading an image which worked, rather than using zeroes, which I guess can be sloppy about its typing.

davisking / dlib