Archive for April 6th, 2015

RPi: Logitech QuickCam for Notebook vs. fswebcam

Combining the camera data I collected a while ago with a few hours of screwing around with this old Logitech camera:

Logitech QuickCam for Notebook Plus - front

Logitech QuickCam for Notebook Plus – front

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:

Logtech 08d8 - 640x480

Logtech 08d8 – 640×480

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.

The -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:

Logtech 08d8 - 320x240 scaled

Logtech 08d8 – 320×240 scaled

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:

Logitech 08d8 - expose 781

Logitech 08d8 – expose 781

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…