[ ] It should detect if the video stream is too dim, and show a warning message suggesting you improve the lighting conditions, such as with a lamp facing the user.
[ ] It should also detect if it's receiving (essentially) pitch black, and give a different message, because it's more likely a dust/privacy cover occluding the camera.
[x] It should also show a warning in a similar way if no head is detected.
[ ] It should detect back-lighting (e.g. ceiling lights, when camera is below the user's head): a blob of bright light around the user's head, and significant fluctuation the apparent brightness of the user's face. That's my attempt at simplifying the definition for computer vision, but it's probably not good enough. I mean, if the back-lighting is really bad, the user would be just a silhouette, but it also shouldn't detect dark skin as a lighting issue, so I'd hesitate to add any absolute threshold of face luminance. That said, maybe dark skin is harder to light properly, and front-lighting would be more important? I don't know.
It should show the webcam view temporarily, so you can see what it's talking about, and see what's going on.
Either 1. the app window should be brought to front (but not focused), and hidden (after a second) if the issue becomes resolved (unless the window got focused by the user, in which case it should stay visible), or 2. the message and webcam view should be shown on the overlay window, and should avoid the mouse, either hiding mostly and blurring, or moving out of the way, so that you don't think you can click on them. Or you should be able to click on them, but that's more complicated.
(Showing the webcam on the overlay screen would mean... using WebRTC?)
These warnings should not show up immediately, only if the condition persists for a few seconds. Although jumps in lighting can cause problems (#22) (and automatic brightness may bring it within normal levels before a reasonable period of laxity), 1. it would probably be too annoying if these warnings showed fast enough to catch that happening, and 2. it's more the change that causes that issue, not the lack of absolute luminosity; that is, it could cause a bad mouse jump while brightening too.
This should be tested with regression testing, i.e. using recorded footage, not just tested live based on the present lighting conditions.
It should show the webcam view temporarily, so you can see what it's talking about, and see what's going on. Either 1. the app window should be brought to front (but not focused), and hidden (after a second) if the issue becomes resolved (unless the window got focused by the user, in which case it should stay visible), or 2. the message and webcam view should be shown on the overlay window, and should avoid the mouse, either hiding mostly and blurring, or moving out of the way, so that you don't think you can click on them. Or you should be able to click on them, but that's more complicated. (Showing the webcam on the overlay screen would mean... using WebRTC?)
These warnings should not show up immediately, only if the condition persists for a few seconds. Although jumps in lighting can cause problems (#22) (and automatic brightness may bring it within normal levels before a reasonable period of laxity), 1. it would probably be too annoying if these warnings showed fast enough to catch that happening, and 2. it's more the change that causes that issue, not the lack of absolute luminosity; that is, it could cause a bad mouse jump while brightening too.
This should be tested with regression testing, i.e. using recorded footage, not just tested live based on the present lighting conditions.