There is a lot you can do to improve the quality of the image. This camera has a very early CMOS sensor, which suffered from huge pixel-to-pixel variation. By characterizing each pixel (which you can do by taking dark field and flat field images), you can correct for this variation, and get an image that looks much less noisy. There are also various algorithms to undo the Bayer filtering, with tradeoffs between sharpness, color accuracy and performance.
That's a very neat trick. In two decades of messing around with webcams we never clued in to that, and I'm pretty sure that this may well be one of the reasons why we had noise issues when using our very early bluescreen implementation.
The mentioned qc-usb driver seems to do some filtering.
IIRC when I played with that 15-20 years ago qc-usb produced distinctly blurry images with slightly washed out colors, while the original windows driver produced images that are sharp, very noisy and with somewhat unnaturaly vivid colors.
Maybe it's subjective, but the screencap from XP seems to show a much higher quality image. It seems there's still room for improvement. Awesome work regardless!
He did say that the webcam had its gain and white balance controlled by the driver so I'm guessing he didn't go the extra mile to reverse engineer that part of the software for what is a pretty lousy camera.
It is mostly the dark current (which is reflected in the values you would get if no light is hitting the CMOS sensor) which is affected by temperature. However, its effect scales with the exposure time. Since night time astrophotography requires long exposure times, this would require recalibration (see also @bdigiifh's post). However, for typical daytime use the effect is much less significant.
Some CMOS sensors or the surrounding electronics components on the PCB can heat up significantly while the sensor is in use.
If the sensor has a configurable gain (which is the hardware amplification applied before digitizing the voltage measured for each pixel), then you probably want to characterize the pixel-to-pixel variation for each gain level.
In professional astronomy (where sensors are kept in dewars to reduce dark current) this process (flat field, dark field) is carried out at least once a night.
Oh, the 'I took it home already' feeling. I had a really bad case of this last week, bought a 17 KW solar inverter for a relatively small amount of money and lugged it home, all 50 Kg of it. It worked when it was taken off the wall according to the seller, but on plugging it in on my end it didn't work, though the display lit up and it seemed to work it wasn't making any power. Normally you'd return it as defective and that would be that but this thing is heavy and it was far away.
Long story short: the seller was a trustworthy fellow and definitely did not try to pull a fast one on me. What happened is that during assembly in the factory or a later repair someone smashed the lid into the main circuit board, almost but not quite tearing off one of those IDC headers for flat cable. Bits of it were rattling around in the case which already had me suspicious upon unloading it. That must have been quite the impact, those things don't normally break. The vibration of the transport across 200 km in a car with a stiff suspension did the rest and dislodged the cable completely. Plug the cable back in and it still worked, so I guess I got really lucky. It's been on the wall and has been making power for the last 3 days without any errors.
A friend of mine used a cheap (pac207) webcam. He complained to me that the camera image was too dark. I looked in the kernel for its driver... found the line which controlled its brightness... sent a patch to maintainer to increase. The maintainer accepted just a bit lower than what I suggest; he said that if the exposure was too long some protocol (probably USB) could break.
Update the driver on my friends' computer (of course, without waiting a new kernel release) and boom, much better image from the camera! He was happy. He thanked me for how I fixed it, I thanked him for giving me opportunity for such a small and useful hack.
Got back to visit him a few days later. Noticed he wasn't using the webcam anymore. I asked "where's your webcam?", he said: "Damn webcam only works correctly under linux!"
This is pretty cool and impressive work! In a pleasant turn of events, "USB video device class" or UVC would have its initial release just 4 years later in 2003. Webcams implementing UVC, which most do since the early 2000s, communicate using a standard protocol which means almost any OS can access almost any webcam without any special drivers or software.
I have an 2012 Logitech webcam connected to an OpenBSD box. A cron job instructs ffmpeg to read from /dev/video0 every 10 minutes, which in turn writes a .jpg into a folder for creating a timelapse. Not bad for a random old webcam I had laying around.
Even better, this device class also covers things like cheap digital "microscopes" and external USB video capture devices. It really simplifies working with those kind of tools.
Reminds me when I had to read barcodes from a USB-connected barcode scanner on a Mac. The manufacturer supplied a closed-source library which only supported PPC code and they told me that they lost the source code, so I couldn't easily add intel support.
In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.
I was so happy when my Mac application was able to talk to the scanner and, compared to windows, completely without any driver installation thanks to user-space IOKit on macOS.
Writing software to make hardware beep is even more fun than writing software that doesn't involve hardware making noise.
Core memory unlocked. Somewhere deep in the bellows of my electronics pile, I have an ancient HP barcode reader box that plugged inline with an AT keyboard. Into this box plugged a reader pen that you dragged across a barcode.
Once read, it would send the barcode number as keyboard commands. It was a very tactile experience.
> In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.
Is there a better way to implement this? They seem to use it for any non-standard feature. My laptop's keyboard uses the control endpoint to control the LEDs.
That sounds pretty fun (once you're finished with it, I'm sure)! How does sniffing the USB work? Do you do that via some software/kernel extension, via special hardware, or something simpler? Do you find there are some USB devices where the manufacturer would rather you didn't sniff their traffic and make it more painful to piece together?
Wireshark via usbmon under Linux can be used to capture USB traffic. This is especially useful when the device has windows drivers, as usbmon can be used to capture the traffic off a windows VM.
For black box devices, you can build/buy a bus snoop cable and hook that up to usbmon/Wireshark (eg sniff the Xbox Kinect protocol).
Percurnious devices will encrypt/sign their packets to make reverse engineering more difficult, if not impossible, but those are few and far between. You're already buying the hardware and that's the expensive bit, so as long as you've bought the hardware, DRM-style weirdness over USB is rare. Still exists, but most hardware I see these days just uses a generic driver like HID for input, or UVC for video, reducing the amount of snooping needed to make the basics work. Getting extra functionality (like special LEDs) working still requires snooping of the working Windows driver+program though.
Readit News
IIRC when I played with that 15-20 years ago qc-usb produced distinctly blurry images with slightly washed out colors, while the original windows driver produced images that are sharp, very noisy and with somewhat unnaturaly vivid colors.
Of note is that FFC --- and frequent too --- is basically mandatory for thermal imaging sensors, since their pixels drift a lot.
Some CMOS sensors or the surrounding electronics components on the PCB can heat up significantly while the sensor is in use.
If the sensor has a configurable gain (which is the hardware amplification applied before digitizing the voltage measured for each pixel), then you probably want to characterize the pixel-to-pixel variation for each gain level.
Long story short: the seller was a trustworthy fellow and definitely did not try to pull a fast one on me. What happened is that during assembly in the factory or a later repair someone smashed the lid into the main circuit board, almost but not quite tearing off one of those IDC headers for flat cable. Bits of it were rattling around in the case which already had me suspicious upon unloading it. That must have been quite the impact, those things don't normally break. The vibration of the transport across 200 km in a car with a stiff suspension did the rest and dislodged the cable completely. Plug the cable back in and it still worked, so I guess I got really lucky. It's been on the wall and has been making power for the last 3 days without any errors.
https://man.archlinux.org/man/errno.1
or:Update the driver on my friends' computer (of course, without waiting a new kernel release) and boom, much better image from the camera! He was happy. He thanked me for how I fixed it, I thanked him for giving me opportunity for such a small and useful hack.
Got back to visit him a few days later. Noticed he wasn't using the webcam anymore. I asked "where's your webcam?", he said: "Damn webcam only works correctly under linux!"
I have an 2012 Logitech webcam connected to an OpenBSD box. A cron job instructs ffmpeg to read from /dev/video0 every 10 minutes, which in turn writes a .jpg into a folder for creating a timelapse. Not bad for a random old webcam I had laying around.
https://en.wikipedia.org/wiki/USB_video_device_class
In the end I sniffed the USB protocol of the windows driver and was delighted to see how they abused the control endpoint rather than setting up proper data endpoints.
I was so happy when my Mac application was able to talk to the scanner and, compared to windows, completely without any driver installation thanks to user-space IOKit on macOS.
Writing software to make hardware beep is even more fun than writing software that doesn't involve hardware making noise.
Once read, it would send the barcode number as keyboard commands. It was a very tactile experience.
Is there a better way to implement this? They seem to use it for any non-standard feature. My laptop's keyboard uses the control endpoint to control the LEDs.
In the case of this barcode scanner all communication was done over the control endpoint though.
For black box devices, you can build/buy a bus snoop cable and hook that up to usbmon/Wireshark (eg sniff the Xbox Kinect protocol).
Percurnious devices will encrypt/sign their packets to make reverse engineering more difficult, if not impossible, but those are few and far between. You're already buying the hardware and that's the expensive bit, so as long as you've bought the hardware, DRM-style weirdness over USB is rare. Still exists, but most hardware I see these days just uses a generic driver like HID for input, or UVC for video, reducing the amount of snooping needed to make the basics work. Getting extra functionality (like special LEDs) working still requires snooping of the working Windows driver+program though.
This one has a simple answer:
USB is a shared bus and limited in bandwidth. Isochronous endpoints transmit continously and thus require a fixed part of that bandwidth.
The OS has to allocate the available bus bandwidth to all plugged in devices.
If no more bandwidth is available, it will refuse to configure the device that you just plugged in!
Thus the alternate setting with the isochronous packet size set to 0 serves multiple purposes:
1) It lets the OS configure the device and let the driver discover it even when not enough free bandwith is available on the bus
2) The driver can release the unused bandwith while the device is not in use
3) Not sending iso packets while the device is not actively used also means less power draw
There's no going back now- we've come too far. I can relate to this, though. I have it, so now I must solve it- pointlessness be damned.