Combining the camera data I collected a while ago with a few hours of screwing around with this old Logitech camera:
I’m convinced it’s the worst camera I’d be willing to use in any practical application.
The camera offers these controls:
fswebcam --list-controls --- Opening /dev/video0... Trying source module v4l2... /dev/video0 opened. No input was specified, using the first. Available Controls Current Value Range ------------------ ------------- ----- Brightness 128 (50%) 0 - 255 Contrast 128 (50%) 0 - 255 Gamma 4 1 - 6 Exposure 2343 (8%) 781 - 18750 Gain, Automatic True True | False Power Line Frequency Disabled Disabled | 50 Hz | 60 Hz Sharpness 2 0 - 3 Adjusting resolution from 384x288 to 320x240.
Putting the non-changing setup data into a fswebcam configuration file:
cat ~/.config/fswebcam.conf # Logitech QuickCam for Notebook Plus -- 046d:08d8 device v4l2:/dev/video0 input gspca_zc3xx resolution 320x240 scale 640x480 set sharpness=1 #jpeg 95 set "power line frequency"="60 hz"
Trying to use 640×480 generally produces a
Corrupt JPEG data: premature end of data segment error, which looks no better than this and generally much worse:
The top of the picture looks pretty good, with great detail on those dust particles, but at some point the data transfer coughs and wrecks the rest of the image. I could crop the top half to the hipster 16:9 format of 640×360, but the transfer doesn’t always fail that far down the image.
-R flag that specifies using direct reads instead of mmap, whatever that means, doesn’t help. In fact, the camera generally crashes hard enough to require a power cycle.
Delaying a second with
-D1 and / or skipping a frame with
-S1 don’t help, either.
The camera works perfectly at 640×480 using
fswebcam under Xubuntu 14.04 on a Dell Latitude E6410 laptop, so I’m pretty sure this is a case of the Raspberry Pi being a bit underpowered for the job / the ARM driver taking too long / something totally obscure. A random comment somewhere observed that switching from Raspbian to Arch Linux (the ARM version) solved a similar video camera problem, so there’s surely room for improvement.
Dragorn of Kismet reports that the Raspberry Pi USB hardware doesn’t actually support USB 2.0 data rates, which also produces problems with Ethernet throughput. The comments in that slashdot thread provide enough details: the boat has many holes and it’s not a software problem.
For lack of anything more adventurous, the config file takes a 320×240 image and scales it up to 640×480, which looks about as crappy as you’d expect:
Even that low resolution will occasionally drop a few bytes along the way, but much less often.
The picture seems a bit blown out, so set the exposure to the absolute minimum:
fswebcam -c ~/.config/fswebcam.conf --set exposure=781 "Logitech 08d8 - expose 781.jpg"
Which looks like this:
Given that’s happening a foot under a desk lamp aimed well away from the scene, the other end of the exposure scale around 18000 produces a uselessly burned out image. I think a husky neutral-density filter would be in order for use with my M2’s under-gantry LED panels. The camera seems to be an early design targeting the poorly illuminated Youtube / video chat market segment (I love it when I can talk like that).
There’s probably a quick-and-dirty Imagemagick color correction technique, although Fred’s full-blown autocorrection scripts seem much too heavy-handed for a Raspberry Pi…